Kodėl VPN serveris už CGNAT niekada nepriima ryšių

100.64 adresas, kitur sprendžiamas dinaminis DNS vardas ir nėra įeinančio rankos paspaudimo – viena problema: operatoriaus NAT. Patvirtinkite tai ir perduokite išeinantį srautą per rele.

Maršrutizatorius praneša WAN adresą, prasidedantį 100.72, dinaminis DNS vardas sprendžiamas į kitą viešą adresą, o tame maršrutizatoriuje veikiantis VPN serveris niekada nebaigia rankos paspaudimo iš išorės. Prievadų peradresavimas sukonfigūruotas, paslauga veikia, o bandymas iš LAN vis dar pavyksta. Maršrutizatoriaus žurnale niekas neatrodo kaip klaida. Šis derinys yra operatoriaus lygio NAT, ir jokia ugniasienės taisyklė negali atidaryti prievado adresu, kurį laiko ISP.

Bendro adreso patvirtinimas trunka dvi minutes ir apsaugo nuo savaitės konfigūracijos pakeitimų.

Požymiai, rodantys operatoriaus NAT

Palyginkite WAN adresą maršrutizatoriaus būsenos puslapyje su adresu, kurį praneša išorinė užklausa. WAN adresas 100.64.0.0/10 intervale yra įprastas požymis, o privatūs diapazonai 10/8, 172.16/12 ir 192.168/16 reiškia tą patį. Jei traceroute rodo tą patį viešą šuolį kartojamą arba ankstyvas šuolis atsako privačiu adresu, tarp maršrutizatoriaus ir interneto yra dar vienas vertėjas. Kai kurie ISP nurodo priskirtą adresą tik klientų portale, todėl eksportuokite tą reikšmę kartu su traceroute.

Keisti protokolus ar prievadus nepadės, nes problema yra įeinantis pasiekiamumas, o ne uždarytas prievadas.

Kodėl peradresavimas ir dinaminis DNS to neištaisys

Prievado peradresavimo taisyklė susieja prievadą maršrutizatoriaus WAN sąsajoje, bet įeinantis srautas niekada nepasiekia šios sąsajos: ISP pirmiausia jį išverčia ir persiunčia tik tai, ką leidžia jo paties lentelė. Paskelbus bendrą adresą dinaminiame DNS, klientai nukreipiami į ISP šliuzą, kurį naudoja daug abonentų, todėl vardas išsprendžiamas, o rankos paspaudimas vis tiek nepavyksta. Hairpin testai pavyksta, nes maršrutizatorius atsako į savo taisyklę iš vidaus, o UPnP turi lygiai tą pačią akląją zoną.

Kliento perkonfigūravimas taip pat nepadės, nes gedimas įvyksta prieš perskaitant bet kokį kliento nustatymą.

Perduoti per VPS su aiškiais maršrutais

Padėkite viešą adresą priekyje: išsinuomokite mažiausią VPS, galintį pernešti srautą, tada priverskite namų maršrutizatorių išvykstamai prisijungti prie jo. Išeinantis UDP iš namų tinklo praeina operatoriaus NAT, todėl tunelis sukuriamas iš vidaus ir VPS tampa pasiekiamu galiniu tašku. Namų pusė tampa klientu su fiksuotu tunelio adresu, o ne serveriu.

VPS serveryje pridėkite klientui būdingą katalogo įrašą, kad serveris žinotų, kuris partneris valdo namų potinklį, ir pridėkite atitinkamą branduolio maršrutą.

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

iroute eilutė nurodo OpenVPN, kuris klientas gauna namų potinklio srautą; route eilutė įrašo tą potinklį į VPS branduolio lentelę, kad paketai apskritai patektų į tunelį. Jei paslauga publikuojama, pridėkite paskirties NAT taisyklę, peradresuojančią viešą prievadą į 10.8.0.10, ir įjunkite net.ipv4.ip_forward.

Išbandykite kelią iš išorės

Patikrinkite kiekvieną šuolį viešojoje pusėje, nes sėkmingas tunelis neįrodo, kad paslauga pasiekiama. Klausymosi būsena ir paketų fiksavimas VPS atskiria „nieko neatėjo“ nuo „atėjo ir buvo atmesta“.

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

Jei fiksavimas rodo paketus iš telefono, bet atsakymo nėra, toliau reikia tikrinti serverio konfigūraciją arba ugniasienę. Jei fiksavimas nieko nerodo, klientas vis dar sprendžia arba siunčia neteisingu adresu.

Alternatyvos, kurias verta įkainoti pirmiau

Dedikuotas IPv4 adresas iš ISP yra trumpiausias sprendimas ir paprastai nedidelis mėnesinis mokestis. Savasis IPv6 pašalina vertimą abiejuose galuose, kai VPN, kliento tinklas ir DNS įrašai jį visi palaiko. Mesh perdanga su potinklio maršrutizatoriumi namų tinkle pasiekia tą patį peradresavimą be VPS, bet už priklausomybę nuo koordinavimo paslaugos.

Rinkitės peradresavimą, kai reikia stabilaus įeinančio prisijungimo ir kiekviena taisyklė turi likti jūsų kontrolėje. Rinkitės ISP adresą, kai biudžetas leidžia ir tikslas tiesiog nustoti apie tai galvoti.

Susiję straipsniai