VPN na routeru, nebo přesměrování portu: co vyhraje?

Přesměrování portu může ukrást port posluchači VPN na routeru. Zkontrolujte vlastníka cíle, odstraňte jen konfliktní mapování a otestujte každou rodinu.

Router VPN ukončuje sám a staré pravidlo přesměrování přesto posílá stejný port UDP na stroj v místní síti. Skutečným koncovým bodem může být jen jedno z nich a jádro mezi nimi nerozhoduje. Překlad cíle přepíše paket dřív, než se použije místní služba, takže proces VPN čeká na provoz, který už byl odeslán jinam. Úkolem je rozhodnout, kdo port vlastní, a pak uvést pravidla do souladu.

Jeden port, dva nárokovaní vlastníci

Server VPN běžící uvnitř routeru potřebuje příchozí povolení, které vede k jeho vlastnímu socketu. Záznam NAT cíle pro stejný port vede úplně jinam: na adresu v místní síti a k rozhodnutí o přesměrování. To jsou různé koncové body s různými logy a různými režimy selhání. Obvyklým vodítkem je, že jedna rodina adres funguje a druhá ne, protože zbylý záznam byl napsán pro jedinou rodinu a už se nikdy nepřezkoumal.

Před úpravou si zapište nárok: rodina, vnější adresa, transport, port a přeložený cíl.

Překlad běží před místní kontrolou

NAT cíle mění cíl paketu ve fázi před směrováním, dřív než jádro volí mezi místním doručením a přesměrováním. Jakmile se cílem stane hostitel v místní síti, paket jde cestou přesměrování. Vstupní pravidla pro vlastní socket routeru se nikdy nezkoumají, a proto log VPN zůstává prázdný, zatímco klient čeká.

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

Toto pořadí je celý mechanismus a rozhraní zařízení ho skrývají za zaškrtávacími políčky, aniž by ho měnila. O tom, kterou cestu paket zvolí, stále rozhoduje vlastník cíle.

Pokud je hostitel v místní síti zamýšleným koncovým bodem, přesměrování je správné a router by na tomto portu neměl také naslouchat.

Ponechte jedno mapování a druhé odstraňte

Vypište záznamy NAT pro tento port a rodinu a vyberte toho, kdo přežije:

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

Záznam TCP se stejným číslem je pro selhání UDP irelevantní a jejich společné pojetí vede ke smazání špatného pravidla. Má-li zvítězit místní socket, vlastník konfliktního mapování tento jediný záznam odstraní nebo přepíše a příchozí povolení pro vlastní port routeru zůstane na místě. Nesouvisející přesměrování, cesta správy a kopie sady pravidel by měly změnu přežít.

Pokud VPN žije na samostatném hostiteli, přesměrování je správný objekt. Služba v kontejneru nebo virtuálním stroji může potřebovat publikovaný port, i když se bedně říká router, takže sledujte socket a jeho jmenný prostor, ne štítek na skříni.

Potvrďte vlastníka zvenčí

Testujte každou rodinu zvlášť, protože spojení IPv6, které končí na routeru, nic neříká o spojení IPv4, které přesměrovává zastaralé pravidlo. Přečtěte si log přijímající služby, abyste viděli, který koncový bod odpověděl, a zprávu klienta o úspěchu berte jako slabý důkaz. Pro smysluplný test je potřeba nový tok. Pošlete sondu z vnějšího hostitele pomocí nc -zvu 203.0.113.7 1194 a přečtěte log vítěze pomocí journalctl -u openvpn@server -n 20. Posluchač routeru zaznamenává spojení sám, zatímco hostitel v místní síti je zaznamenává ve své službě.

Sledování spojení drží existující toky na jejich původním mapování, takže navázaná relace může přežít pravidlo, které jste právě opravili.

Když zamýšlený koncový bod odpoví svými obvyklými kontrolami identity, otestujte soukromý zdroj za tunelem. Dosáhnout vnějšího posluchače je jen první krok; vnitřní směrování a autorizace aplikace jsou samostatné výsledky.

Související články