Waarom 'n VPN-bediener agter CGNAT nooit verbindings aanvaar nie

'n 100.64-adres, 'n dinamiese DNS-naam wat elders oplos en geen inkomende handskud nie is een probleem: draer-NAT. Bevestig dit en stuur dan uitgaande verkeer deur 'n aflos.

Die roeteerder wys 'n WAN-adres wat met 100.72 begin, die dinamiese DNS-naam los op na 'n ander openbare adres, en die VPN-bediener op daardie roeteerder voltooi nooit 'n handskud van buite nie. Poortaanstuur is opgestel, die diens loop, en 'n toets vanaf die LAN werk steeds. Niks in die roeteerderlog lyk soos 'n fout nie. Daardie kombinasie is draer-graad NAT, en geen firewallreël kan 'n poort oopmaak op 'n adres wat die ISP hou nie.

Om die gedeelde adres te bevestig neem twee minute en voorkom 'n week se konfigurasiewysigings.

Die tekens wat op draer-NAT dui

Vergelyk die WAN-adres op die roeteerder se statusbladsy met die adres wat 'n eksterne opsoeking rapporteer. 'n WAN-adres binne 100.64.0.0/10 is die gewone teken, en die private reekse 10/8, 172.16/12 en 192.168/16 beteken dieselfde. As traceroute dieselfde openbare sprong herhaal wys, of 'n vroeë sprong met 'n private adres antwoord, sit daar nog 'n vertaler tussen die roeteerder en die internet. Sommige ISP's lys die toegewysde adres net in die klantportaal, so voer daardie waarde saam met die traceroute uit.

Om protokolle of poorte te verander help nie, want die probleem is inkomende bereikbaarheid, nie 'n geslote poort nie.

Waarom poortaanstuur en dinamiese DNS dit nie kan regmaak nie

'n Poortaanstuur-reël beeld 'n poort op die roeteerder se WAN-koppelvlak af, maar inkomende verkeer bereik nooit daardie koppelvlak nie: die ISP vertaal dit eers en stuur net deur wat sy eie tabel toelaat. Om die gedeelde adres in dinamiese DNS te publiseer, wys kliënte na 'n ISP-gateway wat baie intekenare gebruik, en daarom los die naam op terwyl die handskud steeds misluk. Hairpin-toetse slaag omdat die roeteerder sy eie reël van binne antwoord, en UPnP het presies dieselfde blinde kol.

Om die kliënt te herkonfigureer sal ook nie help nie, want die fout gebeur voordat enige kliëntinstelling gelees word.

Aflos deur 'n VPS met eksplisiete roetes

Plaas 'n openbare adres voor deur die kleinste VPS te huur wat die verkeer kan dra, en laat dan die huisroeteerder daarnatoe uitbel. Uitgaande UDP vanaf die huisnetwerk passeer draer-NAT, so die tonnel vestig van binne en die VPS word die bereikbare eindpunt. Die huiskant word 'n kliënt met 'n vaste tonneladres, nie 'n bediener nie.

Op die VPS, voeg 'n kliëntspesifieke gidsinskrywing by sodat die bediener weet watter eweknie die huis-subnet besit, en voeg 'n ooreenstemmende kernroete by.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Die iroute-reël sê vir OpenVPN watter kliënt verkeer vir die huis-subnet ontvang; die route-reël plaas daardie subnet in die VPS se kerntabel sodat pakkette hoegenaamd die tonnel binnegaan. Vir 'n gepubliseerde diens, voeg 'n bestemming-NAT-reël by wat die openbare poort na 10.8.0.10 deurverwys en aktiveer net.ipv4.ip_forward.

Toets die pad van buite

Verifieer elke sprong aan die openbare kant, want 'n suksesvolle tonnel bewys nie dat die diens bereikbaar is nie. Luistertoestand en pakketopname op die VPS skei 'niks het aangekom nie' van 'aangekom en laat val'.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

As die opname pakkette van die selfoon wys maar geen antwoord nie, is die bedienerkonfigurasie of firewall die volgende stop. As die opname niks wys nie, los die kliënt steeds op of stuur na die verkeerde adres.

Alternatiewe om eerste te oorweeg

'n Toegewyde IPv4-adres van die ISP is die kortste oplossing en is gewoonlik 'n klein maandelikse fooi. Inheemse IPv6 verwyder vertaling aan beide kante wanneer die VPN, die kliëntnetwerk en die DNS-rekords dit almal dra. 'n Mesh-laag met 'n subnetroeteerder binne die huisnetwerk bereik dieselfde aflos sonder 'n VPS, ten koste daarvan dat dit van 'n koördinasiediens afhanklik is.

Kies die aflos wanneer die vereiste stabiele inkomende toegang is en elke reël onder jou beheer moet bly. Kies die ISP-adres wanneer die begroting dit toelaat en die doel bloot is om op te hou daaraan dink.

Verwante artikels