VPN op de router of portfoarútstjoering: wa wint?

De router beëiniget de VPN sels, en in âlde foarútstjoerregel stjoert noch altyd deselde UDP-poarte nei in masine op ’e LAN. Allinnich ien fan dy twa kin it wiere einpunt wêze, en de kernel beslút net tusken har. Bestimmingsfertaling skriuwt it pakket oer foardat de pleatslike tsjinst frege wurdt, sadat it VPN-proses wachtet op ferkear dat al earne oars hinne stjoerd is. De opjefte is om te besluten wa’t de poarte besit, en dan de regels oerienkomme te litten.

Ien poarte, twa bewearde eigners

In VPN-tsjinner dy’t yn ’e router draait, hat in ynkommende tastimming nedich dy’t nei syn eigen socket liedt. In bestimmings-NAT-ynfier foar deselde poarte liedt earne hiel oars hinne: in LAN-adres en in foarútstjoerbeslút. Dat binne ferskillende einpunten mei ferskillende logboeken en ferskillende flatermodi. It gewoane teken is dat de iene adresfamylje wurket en de oare net, om’t de oerbliuwende ynfier foar ien famylje skreaun waard en nea wer besjoen is.

Skriuw de oanspraak op foardat je bewurkje: famylje, ekstern adres, ferfier, poarte en it oersetten doel.

De fertaling giet foar de pleatslike kontrôle

Bestimmings-NAT feroaret it doel fan it pakket yn ’e foar-routingfaze, foardat de kernel kiest tusken pleatslike levering en foarútstjoering. Sadree’t it doel in LAN-host is, nimt it pakket it foarútstjoerpaad. Ynfierregels foar de eigen socket fan ’e router wurde nea besjoen, dêrom bliuwt it VPN-logboek leech wylst de kliïnt wachtet.

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

Dy folchoarder is it hiele meganisme, en apparaatynterfaces ferbergje it efter karfakjes sûnder it te feroarjen. De eigner fan ’e bestimming beslút noch altyd hokker paad in pakket nimt.

As de LAN-host it bedoelde einpunt is, is de foarútstjoering korrekt en soe de router net ek op dy poarte harkje moatte.

Hâld ien mapping en smyt de oare fuort

Lis de NAT-ynfieren foar dy poarte en famylje op en kies de oerlibbene:

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

In TCP-ynfier mei itselde nûmer is net relevant foar in UDP-flater, en se as ien objekt behannelje liedt ta it wiskjen fan ’e ferkearde regel. As de pleatslike socket winne moat, smyt de eigner fan ’e tsjinstridige mapping dy iene ynfier fuort of skriuwt dy oer, en de ynkommende tastimming foar de eigen poarte fan ’e router bliuwt op syn plak. Net ferbûne foarútstjoeringen, it behearpaad en in kopy fan ’e regelset moatte allegear de feroaring oerlibje.

As de VPN op in aparte host wennet, is de foarútstjoering it juste objekt. In tsjinst yn in kontener of firtuele masine hat miskien in publisearre poarte nedich sels as de doaze de router neamd wurdt, folgje dus de socket en syn namespaces, net it label op ’e kast.

Befêstigje de eigner fan bûten

Test elke famylje apart, om’t in IPv6-ferbining dy’t op ’e router einiget neat seit oer in IPv4-ferbining dy’t in âlde regel omleit. Lês it logboek fan ’e ûntfangende tsjinst om te sjen hokker einpunt antwurde, en beskôgje it suksesberjocht fan ’e kliïnt as swak bewiis. In nije stream is nedich foar in sinfolle test. Stjoer in probe fan in eksterne host mei nc -zvu 203.0.113.7 1194 en lês it logboek fan ’e winner mei journalctl -u openvpn@server -n 20. De harker fan ’e router logt de ferbining sels, wylst in LAN-host dy yn syn eigen tsjinst logt.

Ferbiningsferfolging hâldt besteande streams op har oarspronklike mapping, sadat in fêstige sesje de regel dy’t je krekt reparearre hawwe oerlibje kin.

As it bedoelde einpunt antwurdet mei syn normale identiteitskontrôles, test dan in priveebron efter de tunnel. It berikken fan ’e bûtenste harker is mar de earste hop; ynterne routing en applikaasje-autorisaasje binne aparte útkomsten.