Во-первых: я знаю, что с SSH это можно сделать простым способом, но я хочу научиться маршрутизировать.
Я хочу направлять пакеты обратно через тот же интерфейс tun0, из которого они поступали в мою систему.
Я могу сделать это для одиночных маршрутов.
Это работает:
sudo ip route add 74.52.23.120 metric 2 via 10.8.0.1
Но мне пришлось бы добавлять их вручную для каждого поступившего запроса.
Я принял синюю таблетку и следил за http://lartc.org/howto/lartc.netfilter.html:
Netfilter & iproute - руководство по маркировке пакетов
Но он ориентирован на перенаправление исходящих пакетов на основе маркеров.
Я хочу, чтобы пакет, поступающий через tun0, не отбрасывался, что происходит прямо сейчас, при запуске scappy или тому подобном для приема пакетов он, похоже, ничего не получает.
Наблюдая в wirehark, я вижу, что начальные SYN-пакеты поступают через интерфейс tun0, но это все, что касается статического маршрута, как показано выше.
Я чокнутый?
По-видимому, у вас есть какая-то конфигурация пересылки через вашу VPN и вы хотите предотвратить разделение путей маршрутизации для трафика, достигающего вашего хоста через VPN. В этом случае ваш пакет запроса, вероятно, не отбрасывается (по крайней мере, не вашим хостом), ответ просто маршрутизируется через другой интерфейс (предположительно тот, на который указывает ваш маршрут по умолчанию).
Что ты определенно делаешь не Потребность в этом сценарии - динамическое создание / разрыв маршрутов. Вы выбрали правильный путь, применив netfilter для маркировки пакетов. Основное отличие от примеров, приведенных в руководстве LARTC, будет заключаться в том, что вам нужно будет использовать CONNMARK вместо цели MARK - это будет отмечать входящие и исходящие пакеты принадлежащий соединению с определенной маркой. Что-то вроде iptables -t mangle -A INPUT -i tun0 -j CONNMARK --set-mark 555 После этого вы можете использовать ip rule add fwmark 555 lookup <your_secondary_routing_table> чтобы ответы перенаправлялись так же, как и исходные запросы. Ваша настройка немного похожа на настройки маршрутизации для более чем одного интернет-провайдера, поэтому примеры конфигурации должен направить вас на правильный путь, если вы еще не там.
Кстати: вы могли бы добиться аналогичного эффекта намного проще, если бы позволили вашей удаленной конечной точке VPN на 10.8.0.1 просто маскировать запросы TCP / UDP-соединения на свой собственный IP-адрес (iptables -t nat -A POSTROUTING -o tun0 -d <your_servers_address> -j MASQUERADE). Таким образом, вам понадобится только один статический маршрут - к удаленной конечной точке VPN, который вы автоматически настроите с помощью OpenVPN.