VPN op die router of poortaanstuur: wie wen?

Die router beëindig die VPN self, en ’n ou aanstuur-reël stuur steeds dieselfde UDP-poort na ’n masjien op die LAN. Net een van dié kan die ware eindpunt wees, en die kern beslis nie tussen hulle nie. Bestemmingsvertaling herskryf die pakket voordat die plaaslike diens geraadpleeg word, so die VPN-proses wag op verkeer wat reeds elders heen gestuur is. Die taak is om te besluit wie die poort besit, en dan die reëls te laat ooreenstem.

Een poort, twee beweerde eienaars

’n VPN-bediener wat in die router draai, het ’n inkomende toestemming nodig wat na sy eie sok lei. ’n Bestemmings-NAT-inskrywing vir dieselfde poort lei heeltemal elders heen: ’n LAN-adres en ’n aanstuur-besluit. Dit is verskillende eindpunte met verskillende logboeke en verskillende foutmodusse. Die gewone leidraad is dat een adresfamilie werk en die ander nie, omdat die oorblywende inskrywing vir ’n enkele familie geskryf is en nooit weer besoek is nie.

Skryf die eis neer voordat jy redigeer: familie, eksterne adres, transport, poort en die vertaalde teiken.

Vertaling loop voor die plaaslike kontrole

Bestemmings-NAT verander die pakket se teiken in die voorroetering-stadium, voordat die kern tussen plaaslike aflewering en aanstuur kies. Sodra die teiken ’n LAN-gasheer is, neem die pakket die aanstuurpad. Invoerreëls vir die router se eie sok word nooit geraadpleeg nie, en daarom bly die VPN-logboek leeg terwyl die kliënt se tyd verstryk.

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

Daardie ordening is die hele meganisme, en toestel-koppelvlakke versteek dit agter merkkassies sonder om dit te verander. Die bestemming se eienaar besluit steeds watter pad ’n pakket neem.

As die LAN-gasheer die bedoelde eindpunt is, is die aanstuur korrek en moet die router nie ook op daardie poort luister nie.

Hou een kartering en verwyder die ander

Lys die NAT-inskrywings vir daardie poort en familie en kies die oorlewende:

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

’n TCP-inskrywing met dieselfde nommer is onbelangrik vir ’n UDP-fout, en om hulle as een voorwerp te behandel, lei daartoe dat die verkeerde reël uitgevee word. Wanneer die plaaslike sok moet wen, verwyder of herskryf die eienaar van die botsende kartering daardie een inskrywing, en die inkomende toestemming vir die router se eie poort bly in plek. Onverwante aansture, die bestuurspad en ’n kopie van die reëlversameling moet almal die verandering oorleef.

As die VPN op ’n aparte gasheer woon, is die aanstuur die regte voorwerp. ’n Diens in ’n houer of virtuele masjien het miskien ’n gepubliseerde poort nodig selfs wanneer die boks die router genoem word, so volg die sok en sy naamruimte eerder as die etiket op die kas.

Bevestig die eienaar van buite

Toets elke familie afsonderlik, want ’n IPv6-verbinding wat op die router eindig, sê niks oor ’n IPv4-verbinding wat ’n verouderde reël herlei nie. Lees die ontvangende diens se logboek om te sien watter eindpunt geantwoord het, en beskou die kliënt se suksesboodskap as swak bewyse. ’n Nuwe stroom is nodig vir ’n sinvolle toets. Stuur ’n ondersoek van ’n buite-gasheer met nc -zvu 203.0.113.7 1194 en lees die wenners se logboek met journalctl -u openvpn@server -n 20. Die router se luisteraar teken die verbinding self aan, terwyl ’n LAN-gasheer dit in sy eie diens aanteken.

Verbindingnasporing hou bestaande strome op hul oorspronklike kartering, so ’n gevestigde sessie kan die reël wat jy pas reggemaak het, oorleef.

Sodra die bedoelde eindpunt met sy normale identiteitskontroles antwoord, toets ’n private hulpbron agter die tonnel. Om die buitenste luisteraar te bereik is net die eerste hop; binnerouting en toepassingsmagtiging is aparte uitkomste.