Wêrom't in VPN-tsjinner efter CGNAT nea ferbiningen akseptearret

In 100.64-adres, in dynamyske DNS-namme dy't earne oars oplost en gjin ynkommende hânskodding binne ien probleem: carrier-NAT. Befêstigje it, en stjoer dan útgeande ferkear troch in trochstjoering.

De router meldt in WAN-adres dat begjint mei 100.72, de dynamyske DNS-namme lost op nei in oar iepenbier adres, en de VPN-tsjinner op dy router foltôget nea in hânskodding fan bûten. Porttrochstjoering is ynsteld, de tsjinst draait, en in test fan 'e LAN wurket noch. Yn it routerlogboek liket neat op in flater. Dy kombinaasje is carrier-grade NAT, en gjin brânmuoreregel kin in poarte iepenje op in adres dat de ISP hat.

It befêstigjen fan it dielde adres duorret twa minuten en foarkomt in wike fol konfiguraasjewizigings.

De tekens dy't op carrier-NAT wize

Fergelykje it WAN-adres op 'e statuspagina fan 'e router mei it adres dat in eksterne opfrege rapporteart. In WAN-adres binnen 100.64.0.0/10 is it gewoane teken, en de privee-beriken 10/8, 172.16/12 en 192.168/16 betsjutte itselde. As traceroute deselde iepenbiere hop werhellet, of in iere hop antwurdet mei in privee-adres, sit der noch in oersetter tusken de router en it ynternet. Guon ISP's listje it tawiisde adres allinne yn it klantportaal, dus eksportearje dy wearde tegearre mei de traceroute.

Protokollen of poarten feroarje helpt net, want it probleem is ynkommende berikberens, net in sletten poarte.

Wêrom't trochstjoering en dynamyske DNS it net oplosse kinne

In porttrochstjoeringsregel mapt in poarte op 'e WAN-ynterface fan 'e router, mar ynkommend ferkear berikt dy ynterface nea: de ISP oerset it earst en stjoert allinne troch wat syn eigen tabel tastiet. It dielde adres yn dynamyske DNS publisearje rjochtet kliïnten op in ISP-gateway dy't troch in protte abonnees brûkt wurdt, dêrom lost de namme op en mislearret de hânskodding noch altyd. Hairpin-tests slaagje om't de router syn eigen regel fan binnen beantwurdet, en UPnP hat krekt deselde bline flek.

It opnij konfigurearjen fan 'e klant sil ek net helpe, om't de flater bart foardat hokker klantynstelling dan ek lêzen wurdt.

Trochstjoere fia in VPS mei eksplisite rûtes

Set in iepenbier adres foarôf troch de lytste VPS te hieren dy't it ferkear drage kin, en lit dan de hûsrouter dêrhinne útbelje. Utgeande UDP fan it hûsnetwurk giet troch carrier-NAT, dus de tunnel wurdt fan binnen út oprjochte en de VPS wurdt it berikbere einpunt. De hûskant wurdt in klant mei in fêst tunneladres, net in tsjinner.

Op de VPS, foegje in kliïntspesifike mapynfier ta sadat de tsjinner wit hokker peer it hûssubnet hat, en foegje in oerienkommende kernelrûte ta.

# /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"

De rigel iroute fertelt OpenVPN hokker klant ferkear foar it hûssubnet ûntfangt; de rigel route set dat subnet yn 'e kerneltabel fan 'e VPS sadat pakketten hielendal de tunnel yn komme. Foegje foar in publisearre tsjinst in bestimming-NAT-regel ta dy't de iepenbiere poarte nei 10.8.0.10 trochstjoert en aktivearje net.ipv4.ip_forward.

Test it paad fan bûten

Ferifiearje elke hop oan 'e iepenbiere kant, want in slagge tunnel bewiist net dat de tsjinst berikber is. Harkstatus en pakketopname op 'e VPS skiede 'der kaam neat' fan 'der kaam wat en it waard weilitten'.

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 de opname pakketten fan 'e tillefoan sjen lit mar gjin antwurd, dan is de tsjinnerkonfiguraasje of de brânmuorre de folgjende stop. As de opname neat sjen lit, lost de klant noch op of stjoert nei it ferkearde adres.

Alternativen dy't earst priizge wurde moatte

In tawiisd IPv4-adres fan 'e ISP is de koartste oplossing en is meastentiids in lyts moanliks bedrach. Natyf IPv6 hellet de oersetting oan beide kanten fuort as de VPN, it klantnetwurk en de DNS-records it allegear drage. In mesh-oerlizzing mei in subnetrouter yn it hûsnetwurk berikt deselde trochstjoering sûnder VPS, tsjin de priis fan ôfhinklikens fan in koördinaasjetsjinst.

Kies de trochstjoering as de eask stabile ynkommende tagong is en elke regel ûnder dyn kontrôle bliuwe moat. Kies it ISP-adres as it budzjet it tastiet en it doel gewoan is om der net mear oan te tinken.

Relatearre artikelen