Рутер сам завршава 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. Слушалац рутера сам бележи везу, док је хост у локалној мрежи бележи у својој услузи.

Праћење веза задржава постојеће токове на њиховом првобитном мапирању, па успостављена сесија може надживети правило које сте управо исправили.

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

Повезани чланци