VPN um Router oder Portweiterleitung: wat gewënnt?

Den Router beendet de VPN selwer, an eng al Weiterleitungsregel schéckt nach ëmmer dee selwechten UDP-Port op eng Maschinn am LAN. Nëmmen eng vun deenen zwee kann de richtegen Endpunkt sinn, an de Kernel entscheet net tëschent hinnen. D’Ziliwwersetzung schreift de Paket ëm, ier den lokalen Déngscht gefrot gëtt, sou datt de VPN-Prozess op Traffic waart, dee schonn anzwousch anescht geschéckt gouf. D’Aufgab ass ze entscheeden, wiem de Port gehéiert, an duerno d’Reegelen an Einklang ze bréngen.

Ee Port, zwee behaapten Eegentümer

E VPN-Server, deen am Router leeft, brauch eng erakommend Erlaabnis, déi op säin eegene Socket féiert. En Zil-NAT-Andrag fir dee selwechte Port féiert ganz anzwousch anescht: op eng LAN-Adress an op eng Weiterleitungsentscheedung. Dat sinn ënnerschiddlech Endpunkter mat ënnerschiddlechen Loggen an ënnerschiddlechen Ausfallarten. Den üblechen Hiwäis ass, datt eng Adressfamill funktionéiert an déi aner net, well den iwwreg Andrag fir eng eenzeg Famill geschriwwe gouf an ni nach eng Kéier iwwerpréift gouf.

Schreift d’Behaaptung op, ier dir editéiert: Famill, extern Adress, Transport, Port an dat iwwersat Zil.

D’Iwwersetzung leeft virun der lokaler Kontroll

Zil-NAT ännert d’Zil vum Paket an der Prerouting-Phase, ier de Kernel tëschent lokaler Liwwerung a Weiterleitung wielt. Soubal d’Zil en LAN-Host ass, hëlt de Paket de Weiterleitungswee. Inputregelen fir de Router säin eegene Socket ginn ni consultéiert, dofir bleift de VPN-Log eidel, während de Client an en Timeout leeft.

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

Déi Reiefolleg ass de ganze Mechanismus, an d’Apparatschnëttstellen verstoppen en hannert Këschten, ouni en ze änneren. Den Eegentümer vum Zil entscheet weiderhin, wéi ee Wee e Paket hëlt.

Wann den LAN-Host de gewënschten Endpunkt ass, ass d’Weiterleitung richteg an de Router sollt net och op deem Port lauschteren.

Behält eng Mapping a läscht déi aner

Lëscht d’NAT-Andräg fir dee Port an déi Famill op a wielt deen, deen iwwerlieft:

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

En TCP-Andrag mat der selwechter Nummer ass fir en UDP-Feeler irrelewant, an se als een Objet ze behandelen féiert dozou, datt déi falsch Regel geläscht gëtt. Wann de lokalen Socket gewanne soll, entfernt oder schreift den Eegentümer vun der widersprüchlecher Mapping deen een Andrag ëm, an d’erakommend Erlaabnis fir de Router säin eegene Port bleift op senger Plaz. Onbetraffe Weiterleitungen, de Verwaltungswee an eng Kopie vum Reegelsaz sollten all d’Ännerung iwwerliewen.

Wann de VPN op engem separaten Host lieft, ass d’Weiterleitung den richtegen Objet. En Déngscht an engem Container oder enger virtueller Maschinn brauch vläicht en publizéierte Port, och wann d’Këscht Router genannt gëtt, also verfollegt de Socket an säin Nummraum, net d’Etikett op der Këscht.

Bestätegt den Eegentümer vu baussen

Test all Famill getrennt, well eng IPv6-Verbindung, déi um Router ophält, näischt iwwer eng IPv4-Verbindung seet, déi eng al Regel ëmleet. Liest de Log vum empfangenden Déngscht, fir ze gesinn, wéi en Endpunkt geäntwert huet, a behandelt d’Erfolgsmeldung vum Client als schwaache Beweis. Et brauch en neie Flow fir en aussagekräftegen Test. Schéckt eng Sonde vun engem externen Host mat nc -zvu 203.0.113.7 1194 a liest de Log vum Gewënner mat journalctl -u openvpn@server -n 20. De Lauschter vum Router loggt d’Verbindung selwer, während en LAN-Host se an sengem eegene Déngscht loggt.

D’Verbindungsverfolgung hält bestoend Flows op hirer ursprénglecher Mapping, sou datt eng etabléiert Sitzung d’Regel, déi dir grad reparéiert hutt, iwwerliewen kann.

Soubal den intendéierten Endpunkt mat sengen normale Identitéitskontrollen äntwert, test eng privat Ressource hannert dem Tunnel. Den äusseren Lauschter z’erreechen ass just den éischte Sprong; intern Routing an Applikatiounsautorisatioun sinn getrennt Resultater.