VPN на рутерот или пренасочување на порта: кој победува?

Рутерот сам го завршува VPN-то, а старото правило за пренасочување сѐ уште го праќа истиот UDP порт до машина во LAN. Само едно од двете може да биде вистинската крајна точка, а јадрото не одлучува меѓу нив. Преводот на одредиштето го препишува пакетот пред да се консултира локалната служба, така што VPN процесот чека сообраќај што веќе е пратен на друго место. Задачата е да се одлучи чија е портата, а потоа правилата да се усогласат.

Една порта, двајца наводни сопственици

VPN серверот што работи во рутерот бара влезна дозвола што води до неговиот сопствен сокет. Записот за NAT на одредиштето за истата порта води сосема на друго место: до LAN адреса и одлука за пренасочување. Тоа се различни крајни точки со различни дневници и различни режими на откажување. Вообичаената поука е дека едно семејство адреси работи, а другото не, бидејќи преостанатиот запис е напишан за едно семејство и никогаш не е прегледан повторно.

Запишете го барањето пред уредување: семејство, надворешна адреса, транспорт, порта и преведената цел.

Преводот оди пред локалната проверка

NAT на одредиштето ја менува целта на пакетот во фазата пред насочување, пред јадрото да избере меѓу локална достава и пренасочување. Штом целта стане хост во LAN, пакетот тргнува по патот на пренасочување. Влезните правила за сопствениот сокет на рутерот никогаш не се разгледуваат, затоа VPN дневникот останува празен додека клиентот чека.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Тој редослед е целиот механизам, а интерфејсите на уредите го кријат зад полиња за избор без да го менуваат. Патот на пакетот сѐ уште го одлучува сопственикот на одредиштето.

Ако хостот во LAN е саканата крајна точка, пренасочувањето е точно и рутерот не треба да слуша и на таа порта.

Задржете едно мапирање и отстранете го другото

Излистајте ги NAT записите за таа порта и семејство и изберете го преживеаниот:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Записот TCP со истиот број е неважен за отказ на UDP, а нивното третирање како еден објект води до бришење на погрешното правило. Кога локалниот сокет треба да победи, сопственикот на конфликтното мапирање го отстранува или препишува токму тој запис, а влезната дозвола за сопствената порта на рутерот останува на место. Неповрзаните пренасочувања, патот за управување и копијата од множеството правила треба да ја преживеат промената.

Ако VPN-то живее на посебен хост, пренасочувањето е вистинскиот објект. Службата во контејнер или виртуелна машина може да бара објавена порта дури и кога кутијата се нарекува рутер, затоа следете го сокетот и неговиот простор од имиња, а не етикетата на куќиштето.

Потврдете го сопственикот однадвор

Тестирајте го секое семејство одделно, бидејќи IPv6 врската што завршува на рутерот ништо не кажува за IPv4 врската што старата правила ја пренасочува. Прочитајте го дневникот на службата што прима за да видите која крајна точка одговорила, и сметајте ја пораката за успех на клиентот за слаб доказ. За смислен тест е потребен нов тек. Испратете сонда од надворешен хост со nc -zvu 203.0.113.7 1194 и прочитајте го дневникот на победникот со journalctl -u openvpn@server -n 20. Слушачот на рутерот сам ја запишува врската, додека хостот во LAN ја запишува во сопствената служба.

Следењето на врските ги држи постојните текови на нивното првобитно мапирање, така што воспоставената сесија може да го надживее правилото што штотуку го поправивте.

Откако саканата крајна точка ќе одговори со своите вообичаени проверки на идентитетот, тестирајте приватен ресурс зад тунелот. Да се стигне до надворешниот слушач е само првиот скок; внатрешното насочување и авторизацијата на апликацијата се одделни исходи.