Kvifor ein VPN-server bak CGNAT aldri godtek tilkoplingar

Ei 100.64-adresse, eit dynamisk DNS-namn som løyser seg opp ein annan stad og ingen inngåande handtrykk er eitt problem: NAT hjå operatøren. Stadfest det, og send deretter utgåande trafikk vidare.

Rutaren rapporterer ei WAN-adresse som byrjar på 100.72, det dynamiske DNS-namnet løyser seg opp til ei anna offentleg adresse, og VPN-serveren på den rutaren fullfører aldri eit handtrykk utanfrå. Portvideresending er sett opp, tenesta køyrer, og ein test frå LAN-et verkar framleis. Ingenting i ruterloggen ser ut som ein feil. Den kombinasjonen er operatørgradert NAT, og ingen brannmurregel kan opne ein port på ei adresse som ISP-en held.

Å stadfeste den delte adressa tek to minutt og hindrar ei veke med konfigurasjonsendringar.

Teikna som peikar mot NAT hjå operatøren

Samanlikn WAN-adressa på statussida til rutaren med adressa eit eksternt oppslag rapporterer. Ei WAN-adresse innanfor 100.64.0.0/10 er det vanlege teiknet, og dei private områda 10/8, 172.16/12 og 192.168/16 tyder det same. Viss traceroute viser same offentlege hoppet gjenteke, eller eit tidleg hopp svarar med ei privat adresse, sit det ein annan omsetjar mellom rutaren og internettet. Nokre ISPar viser berre den tildelte adressa i kundeportalen, så eksporter den verdien saman med traceroute.

Å byte protokoll eller port hjelper ikkje, fordi problemet er inngåande tilgjenge og ikkje ein lukka port.

Kvifor vidareformidling og dynamisk DNS ikkje kan rette det

Ein portvideresendingsregel kartlegg ein port på WAN-grensesnittet til rutaren, men inngåande trafikk når aldri det grensesnittet: ISP-en omset han først og sender berre vidare det tabellen hans tillèt. Å publisere den delte adressa i dynamisk DNS peikar klientane mot ein ISP-gateway som mange abonnentar brukar, og difor løyser namnet seg opp medan handtrykket framleis mislukkast. Hairpin-testar lukkast fordi rutaren svarar sin eigen regel innanfrå, og UPnP har nøyaktig same blindsona.

Det hjelper heller ikkje å konfigurere klienten på nytt, sidan feilen oppstår før noka klientinnstilling blir lesen.

Vidareformidle gjennom ein VPS med eksplisitte ruter

Set ei offentleg adresse framme ved å leige den minste VPS-en som kan bere trafikken, og la deretter heimerutaren ringje ut til henne. Utgåande UDP frå heimenettet passerer NAT hjå operatøren, så tunnelen blir etablert innanfrå og VPS-en blir det tilgjengelege endepunktet. Heimesida blir ein klient med fast tunneadresse, ikkje ein server.

På VPS-en legg du til ein klientspesifikk katalogoppføring slik at serveren veit kva peer som eig heimesubnettet, og legg til ei samsvarande kjernerute.

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

Lina iroute fortel OpenVPN kva klient som mottek trafikk for heimesubnettet; lina route legg det subnettet i kjerneltabellen til VPS-en slik at pakkar i det heile kjem inn i tunnelen. For ei publisert teneste legg du til ein destinasjons-NAT-regel som sender den offentlege porten vidare til 10.8.0.10, og aktiverer net.ipv4.ip_forward.

Test stien utanfrå

Stadfest kvart hopp på den offentlege sida, fordi ein vellukka tunnel ikkje provar at tenesta er tilgjengeleg. Lyttetilstand og pakkefangst på VPS-en skil «ingenting kom» frå «kom og vart forkasta».

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

Viss fangsten viser pakkar frå telefonen men ingen svar, er serverkonfigurasjonen eller brannmuren neste stopp. Viss fangsten ikkje viser noko, løyser klienten framleis opp eller sender til feil adresse.

Alternativ det er verdt å prise først

Ei dedikert IPv4-adresse frå ISP-en er den kortaste løysinga og er vanlegvis eit lite månadleg gebyr. Innebygd IPv6 fjernar omsetjinga i begge endar når VPN-en, klientnettet og DNS-oppføringane alle ber det. Eit mesh-overlegg med ein subnett-rutar inne i heimenettet oppnår same vidareformidling utan ein VPS, men mot at ein er avhengig av ei koordineringsteneste.

Vel vidareformidlinga når kravet er stabil inngåande tilgang og kvar regel skal halde fram under din kontroll. Vel ISP-adressa når budsjettet tillèt det og målet rett og slett er å slutte å tenkje på det.

Relaterte artiklar