VPN op de router of poortdoorschakeling: wat wint?

De router beëindigt de VPN zelf, en een oude forwarding-regel stuurt nog steeds dezelfde UDP-poort naar een machine op de LAN. Slechts één van beide kan het echte eindpunt zijn, en de kernel beslist niet tussen hen. Doelvertaling herschrijft het pakket voordat de lokale dienst wordt geraadpleegd, dus het VPN-proces wacht op verkeer dat al elders is bezorgd. De taak is bepalen wie de poort bezit, en daarna de regels met elkaar in overeenstemming brengen.

Eén poort, twee geclaimde eigenaren

Een VPN-server die in de router draait, heeft een inkomende toestemming nodig die naar zijn eigen socket leidt. Een destination-NAT-item voor dezelfde poort leidt ergens heel anders heen: een LAN-adres en een forwarding-beslissing. Dat zijn verschillende eindpunten met verschillende logboeken en verschillende faalwijzen. De gebruikelijke aanwijzing is dat de ene adresfamilie werkt en de andere niet, omdat het overgebleven item voor één familie is geschreven en nooit opnieuw is bekeken.

Schrijf de claim op voordat je bewerkt: familie, extern adres, transport, poort en het vertaalde doel.

De vertaling gaat voor de lokale controle

Destination-NAT verandert het doel van het pakket in de prerouting-fase, voordat de kernel kiest tussen lokale aflevering en forwarding. Zodra het doel een LAN-host is, neemt het pakket het forwarding-pad. Invoerregels voor de eigen socket van de router worden nooit geraadpleegd, daarom blijft het VPN-logboek leeg terwijl de client in een time-out loopt.

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

Die volgorde is het hele mechanisme, en apparaatinterfaces verbergen het achter selectievakjes zonder het te veranderen. De eigenaar van de bestemming bepaalt nog steeds welk pad een pakket neemt.

Als de LAN-host het beoogde eindpunt is, is de forwarding correct en zou de router niet ook op die poort moeten luisteren.

Houd één mapping en verwijder de andere

Lijst de NAT-items voor die poort en familie op en kies de overlevende:

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

Een TCP-item met hetzelfde nummer is irrelevant voor een UDP-storing, en ze als één object behandelen leidt tot het verwijderen van de verkeerde regel. Wanneer de lokale socket moet winnen, verwijdert of herschrijft de eigenaar van de conflicterende mapping precies dat ene item, en de inkomende toestemming voor de eigen poort van de router blijft staan. Onverwante forwardings, het beheerpad en een kopie van de regelset moeten allemaal de wijziging overleven.

Als de VPN op een aparte host woont, is de forwarding het juiste object. Een dienst in een container of virtuele machine heeft mogelijk een gepubliceerde poort nodig, zelfs als de doos de router wordt genoemd, dus volg de socket en zijn namespace, niet het label op de behuizing.

Bevestig de eigenaar van buitenaf

Test elke familie apart, want een IPv6-verbinding die op de router eindigt, zegt niets over een IPv4-verbinding die een oude regel omleidt. Lees het logboek van de ontvangende dienst om te zien welk eindpunt antwoordde, en beschouw het succesbericht van de client als zwak bewijs. Een nieuwe flow is nodig voor een zinvolle test. Stuur een probe vanaf een externe host met nc -zvu 203.0.113.7 1194 en lees het logboek van de winnaar met journalctl -u openvpn@server -n 20. De listener van de router logt de verbinding zelf, terwijl een LAN-host die in zijn eigen dienst logt.

Verbindingsregistratie houdt bestaande flows op hun oorspronkelijke mapping, zodat een gevestigde sessie de regel die je net hebt gerepareerd kan overleven.

Zodra het beoogde eindpunt antwoordt met zijn normale identiteitscontroles, test je een privébron achter de tunnel. De buitenste listener bereiken is slechts de eerste sprong; interne routing en applicatieautorisatie zijn afzonderlijke uitkomsten.