Проброс порта в VPN

Покажи как ты пробрасываешь порт.

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

iptables -A FORWARD -i wlan0 -j ACCEPT

iptables -t nat -A PREROUTING -i wlan0 -p tcp -m tcp –dport 2022 -j DNAT –to-destination 192.168.1.1:22

Проброс - последняя строчка. Долблюсь в wlan0, а попасть хочу на ВПН сервак 192.168.1.1

Удивительно, но после добавления строчки

iptables -t nat -A POSTROUTING -o tap3 -j SNAT –to-source 192.168.1.98

Это что то про адрес на vpn интерфейсе, все заработало.

Вообще не понимаю почему, все методом тыка. Может кто объяснит?)

Машины, куда ты пробрасываешь порт шлют ответы через другой шлюз - а тот скорее всего их не пропускает, или NAT-и в другой IP-адрес, который источник трафика не ожидает увидеть.

Например возьмем такую схему

 
              Интернет                        Интернет
                 |                               |
                GW1                             GW2
(192.168.0.1)    |                               | (172.16.0.1)
                 |                               |
(192.168.0.10)   |  (10.0.0.2)      (10.0.0.1)   | (172.16.0.10)
                PC1 --------------------------- PC2

За шлюзами GW1 и GW2 - интернет. Для простоты также предположим, что у GW1 и GW2 на линках в сторону Интернета - публичные IP-адреса.

В локалку соответственно у GW1 - 192.168.0.1, у GW2 - 172.16.0.1. PC1 и PC2 - это устройства, между которыми организован туннель. Их адреса можно увидеть на схеме по аналогии. Адреса 10.0.0.1 и 10.0.0.2 - это адреса на туннельном линке.

Трафик(допустим с адреса 1.1.1.1) приходит на GW2, NAT-ится(DNAT) в 10.0.0.2, доходит до него. PC1 смотрит в таблицу маршрутизации, видит что 1.1.1.1 в ней нет, смотрит маршрут по умолчанию - он ведет через GW1 в Интернет, шлет туда ответ.

В результате в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса GW1(а должен - с публичного адреса GW2). Итог: трафик отбрасывается файрволом на 1.1.1.1.

Также, в некоторых случаях, он может быть отброшен еще раньше - если какой-то маршрутизатор по пути дропает INVALID-соединения в conntrack-е или его аналогах. Это может быть даже GW1, ибо с его стороны это выглядит как попытка отправить ответный пакет без запроса(так как запрос через него не проходил)

Сделав SNAT, ты подменил адрес 1.1.1.1 на локальный адрес, в результате чего у тебя и запросы и ответы пошли по туннельному линку. Но ты на сервере куда делаешь DNAT лишился сведений с какого адреса из Интернета пришли запросы. Если тебя это устраивает - можешь так и оставить. Если нет - нужно крутить policy based routing.

УУ, СПАСИБО!!! за такой популярный доходчивый ответ!! Блин, реально для таких как я) чтоб дошло

Да, меня все устраивает. Это было моделирование ситуации для друга - у него не шел траф при аналогичном пробросе, я решил поставить эксперимент на домашнем ноуте и рабочем ВПН сервере. Теперь понятно в чем дело. У него роутер на дистрибутиве pfsence (на FREEBSD). Подумаем как добавить такое правило SNAT в его файрвол.

И другу запилили правило для его дистра. Все работает!!!

Прочитайте книгу такую: LARTC Поизучайте принципы маршрутизации вцелом(основы), а также ее непосредственную реализацию в linux. А также обязательно изчите документацию iptables(ВСЮ).

Да вроде iptables заменили на что то другое в новых дистрах.

Во-первых, не то чтобы заменили, а просто сделали альтернативу, называется это nftables(просто более усовершенствованную), а iptables же, в качестве альтернативной оболочки netfilter как был, так и продолжает существовать в актуальном состоянии, да и не меняет это в плане того понимания работы файерволов и методов обработки сетевых пакетов в системе, если вы изучите любой из них, но так как iptables на данный момент более документирован в сети вцелом, то лучше начать с него.