Трябва ли да приложите SNAT при пренасочване на порт към VPN подмрежа?

Пренасочването на порт към хост, който стои зад собствения VPN клиент на рутера, се проваля по начин, който изглежда като проблем с защитната стена, защото заявката очевидно пристига. Услугата регистрира връзка, клиентът чака и нищо не се връща. Транслацията на дестинацията си свърши работата; пакетът за връщане е частта, която липсва. Едно селективно правило за изходен NAT на рутера го поправя, а интересното е да решите колко тясно може да бъде това правило.

Защо отговорът поема по друг път

Пренасочването на порт пренаписва накъде отива пакетът, но никога откъде е тръгнал. Адресът на интернет клиента остава в полето за източник по целия път през тунела, така че отдалечената услуга вижда непознат и отговаря по единствения начин, който знае: през собствения си шлюз по подразбиране. Този шлюз е VPN концентраторът от отсрещната страна, който няма маршрут обратно към произволен публичен адрес.

Наблюдавайте запис на интерфейса на тунела и асиметрията е очевидна: пакетите на заявката излизат, нищо не влиза. Веригата за пренасочване е разрешила потока и тунелът го е пренесъл, значи отпадането става, след като отдалеченият хост вече е избрал път за връщане.

Правило за източник, достатъчно тясно, за да му се доверите

Направете рутера източникът, на който отдалеченият хост отговаря. В тази схема WAN адресът е 203.0.113.24, LAN е 192.168.88.0/24, адресът на тунела на рутера е 172.20.5.1, а услугата отговаря на 172.20.5.40:8443. Правилото по-долу съвпада с пакета след транслацията на дестинацията, затова посочва транслатирания адрес, а не публичния. Нищо в него не зависи от адреса на клиента и точно това е смисълът.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Всяко съвпадение в този ред съществува, за да държи пренаписването локално за една услуга на един тунел. Махнете интерфейса или порта и пренаписвате повече трафик, отколкото проблемът изисква, а точно така целенасочената поправка се превръща в загадка за следващия човек.

Кога всеобщото маскиране е честният избор

Ако рутерът пренасочва много услуги към една и съща VPN подмрежа, правилото за всяка услуга се превръща в списък, който никой не поддържа. Маскирането на всичко, което напуска интерфейса на тунела, е по-просто и предвидимо, на цената на скриване на оригиналния клиент от всеки хост от другата страна. Изберете го, когато логовете там не се използват за атрибуция; запазете тясното правило, когато се използват.

Двете опции се провалят и по различен начин. Липсващото тясно правило чупи една услуга; широко маскиране, което съвпада с твърде много, може тихо да пренапише трафик, който вече е работел, включително собствените изходящи връзки на рутера.

Проверете броячите, преди да публикувате

Правила, които никога не съвпадат, изглеждат идентични с правила, които работят, докато не преброите пакетите. Прочетете таблицата отново с байтови броячи, преди който и да е клиент да се свърже, след това се свържете от мрежа, която не е LAN, и прочетете отново. Двете четения са това, което превръща предположението в факт. Публикувайте пренасочването само след като второто се премести.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Нулев брояч на правилото за източник след реална връзка означава, че съвпадението е грешно, обикновено защото дестинацията или портът не съответстват на пакета след транслация. Ако броячът расте, но клиентът все още получава таймаут, пътят за връщане е поправен и нещо друго изпуска отговора, затова погледнете след това политиката за пренасочване от другата страна. Достъпът през примка от вътрешността на LAN е отделен проблем и се нуждае от собствено правило, а не от по-широка версия на това.