VPN на рутера или пренасочване на порт: кой печели?

Рутерът сам прекратява VPN, а старо правило за пренасочване все още изпраща същия UDP порт към машина в локалната мрежа. Само едно от двете може да е истинската крайна точка и ядрото не решава между тях. Транслацията на дестинацията пренаписва пакета, преди да бъде потърсена локалната услуга, така че процесът VPN чака трафик, който вече е изпратен другаде. Задачата е да се реши кой притежава порта, а след това правилата да се съгласуват.

Един порт, двама претенденти за собственик

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

Запишете претенцията преди редактиране: семейство, външен адрес, транспорт, порт и транслационната цел.

Транслацията върви преди локалната проверка

NAT на дестинацията променя целта на пакета в етапа преди маршрутизиране, преди ядрото да избере между локална доставка и пренасочване. Щом целта стане хост в локалната мрежа, пакетът поема пътя на пренасочване. Правилата за входящ трафик към собствения сокет на рутера никога не се разглеждат, поради което журналът на 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

Тази подредба е целият механизъм и интерфейсите на устройствата я крият зад отметки, без да я променят. Собственикът на дестинацията все още решава кой път поема пакетът.

Ако хостът в локалната мрежа е желаната крайна точка, пренасочването е правилно и рутерът не трябва да слуша също на този порт.

Запазете едно съответствие и премахнете другото

Избройте записите 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. Слушателят на рутера записва връзката сам, докато хост в локалната мрежа я записва в собствената си услуга.

Проследяването на връзки запазва съществуващите потоци на първоначалното им съответствие, така че установена сесия може да надживее правилото, което току-що поправихте.

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