Miks CGNAT-i taga olev VPN-server ei võta kunagi ühendust vastu

Ruuter teatab WAN-aadressi, mis algab 100.72-ga, dünaamiline DNS-nimi lahendub teiseks avalikuks aadressiks ja selle ruuteri VPN-server ei lõpeta kunagi väljastpoolt tulevat käepigistust. Pordiedastus on seadistatud, teenus töötab ja LAN-ist tehtud test toimib endiselt. Ruuteri logis ei paista miski veana. See kombinatsioon on operaatoritaseme NAT ja ükski tulemüürireegel ei saa avada porti aadressil, mida ISP hoiab.

Jagatud aadressi kinnitamine võtab kaks minutit ja hoiab ära nädala konfiguratsioonimuudatusi.

Märgid, mis viitavad operaatori NAT-ile

Võrrelge ruuteri olekulehel olevat WAN-aadressi aadressiga, mille teatab väline päring. WAN-aadress vahemikus 100.64.0.0/10 on tavaline märk ning privaatsed vahemikud 10/8, 172.16/12 ja 192.168/16 tähendavad sama. Kui traceroute näitab sama avalikku hüpet korduvalt või varajane hüpe vastab privaatse aadressiga, seisab ruuteri ja interneti vahel veel üks tõlkija. Mõned ISP-d loetlevad määratud aadressi ainult kliendiportaalis, seega eksportige see väärtus koos traceroute'i tulemusega.

Protokollide või portide muutmine ei aita, sest probleem on sissetulev kättesaadavus, mitte suletud port.

Miks edastamine ja dünaamiline DNS seda parandada ei suuda

Pordiedastusreegel vastendab ruuteri WAN-liidese pordi, kuid sissetulev liiklus ei jõua kunagi selle liideseni: ISP tõlgib selle esmalt ja edastab ainult seda, mida tema enda tabel lubab. Jagatud aadressi avaldamine dünaamilises DNS-is suunab kliendid ISP lüüsile, mida kasutab palju abonente, mistõttu nimi lahendub, kuid käepigistus siiski ebaõnnestub. Hairpin-testid õnnestuvad, sest ruuter vastab omaenda reeglile seestpoolt, ja UPnP-l on täpselt sama pime nurk.

Ka kliendi ümberseadistamine ei aita, sest tõrge tekib enne, kui ükskõik millist kliendi seadet loetakse.

Relee läbi VPS-i selgete marsruutidega

Asetage ette avalik aadress, rentides väikseima VPS-i, mis suudab liiklust kanda, ja laske seejärel koduruuteril selle poole välja helistada. Koduvõrgust väljuv UDP läbib operaatori NAT-i, seega tunnel luuakse seestpoolt ja VPS-ist saab kättesaadav lõpp-punkt. Kodupoolest saab fikseeritud tunnelaadressiga klient, mitte server.

Lisage VPS-ile kliendipõhine kataloogikirje, et server teaks, millisele partnerile kodualavõrk kuulub, ja lisage vastav kerneli marsruut.

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

Rida iroute ütleb OpenVPN-le, milline klient saab kodualavõrgu liiklust; rida route paneb selle alavõrgu VPS-i kerneli tabelisse, et paketid üldse tunnelisse satuksid. Avaldatud teenuse jaoks lisage sihtkoha NAT-reegel, mis edastab avaliku pordi aadressile 10.8.0.10, ja lubage net.ipv4.ip_forward.

Testige teekonda väljastpoolt

Kontrollige iga hüpet avalikul poolel, sest edukas tunnel ei tõesta, et teenus on kättesaadav. VPS-i kuulamisolek ja paketipüük eristavad olukorda 'midagi ei saabunud' olukorrast 'saabus ja visati kõrvale'.

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

Kui püük näitab telefonist tulevaid pakette, kuid vastust pole, on järgmine peatus serveri konfiguratsioon või tulemüür. Kui püük ei näita midagi, lahendab klient veel aadressi või saadab vale aadressi.

Alternatiivid, mida tasub esimesena hinnata

ISP-lt saadav pühendatud IPv4-aadress on lühim lahendus ja tavaliselt väike kuutasu. Native IPv6 eemaldab tõlkimise mõlemas otsas, kui VPN, kliendivõrk ja DNS-kirjed seda kõik kannavad. Koduvõrgu sees alavõrgu ruuteriga mesh-kate saavutab sama relee ilma VPS-ita, kuid koordineerimisteenusest sõltumise hinnaga.

Valige relee, kui nõue on stabiilne sissetulev juurdepääs ja iga reegel peaks jääma teie kontrolli alla. Valige ISP aadress, kui eelarve lubab ja eesmärk on lihtsalt sellele mitte enam mõelda.