Namų VPN serveris nepasiekiamas: pereikite NAT grandinę

Serveris atsako LAN tinkle, prievado peradresavimo taisyklė atrodo teisinga, o išorinis klientas vis tiek negali prisijungti. Eiti po vieną ribą į išorę greičiau nei ketvirtą kartą redaguoti taisyklę, nes kiekviena riba palieka savo įrodymą: maršrutizatoriaus WAN puslapis, tiekėjo vertimas ir klausytojas pagrindiniame kompiuteryje. Pradėkite nuo administravimo puslapio, kurį jau turite atidarytą, ir pabaikite testu iš tinklo, kurio nekontroliuojate. Užsirašykite kiekvieną rezultatą eidami, nes seka yra diagnozė, o atsimintas skaičius nėra įrodymas. Jei jums reikia tik išeinančio tunelio, vertimas nėra jūsų problema: blokuojamas tik neprašytas įeinantis srautas.

Pradėkite nuo maršrutizatoriaus WAN puslapio

Prisijunkite prie maršrutizatoriaus ir skaitykite būsenos puslapį, o ne prievadų peradresavimo sąrašą. Užsirašykite WAN adresą, sąsają, kuriai jis priklauso, ir ar ryšio tipas yra DHCP, PPPoE ar kažkas, ką teikia tiekėjas. Tada palyginkite tą adresą su tuo, ką praneša išorinė paslauga, naudodami telefoną su mobiliaisiais duomenimis, kad stebėjimas negrįžtų per tą patį maršrutizatorių. Du skaičiai atsako į skirtingus klausimus, ir jų palyginimas yra visas šio žingsnio tikslas.

WAN adresas, besiskiriantis nuo stebimo viešo adreso, reiškia, kad virš maršrutizatoriaus yra bent vienas vertėjas. Tai dar ne gedimas, nes daugelis tiekėjų verčia pagal projektą ir paslauga vis tiek veikia. Jei abu sutampa, adresas greičiausiai priklauso maršrutizatoriui, o problema persikėlė į jūsų tinklą. Bet kuriuo atveju užrašykite porą su data, nes tiekėjai perskirsto adresus, o palyginimas su praėjusio mėnesio užrašais yra bevertis.

Pakilkite vienu šuoliu aukščiau

Paleiskite traceroute iš paties maršrutizatoriaus ir perskaitykite pirmuosius šuolius. Pasikartojantys vieši adresai, pirmasis šuolis, atsakantis privačiu adresu, arba adresas bendrame 100.64.0.0/10 diapazone visi rodo į vertėją aukščiau. RFC 6598 apibrėžia tą diapazoną būtent tokiam diegimui, todėl matyti jį WAN lauke yra stiprus signalas, o ne smalsumas. Du vertėjai kelyje daro pėdsaką mažiau akivaizdų, todėl skaitykite modelį, o ne vieną eilutę.

Kai kurie tiekėjai priskirtą adresą rodo tik kliento portale, todėl pažiūrėkite ten, prieš darydami išvadą, kad maršrutizatorius meluoja. Portalo adresas, sutampantis su jūsų išoriniu stebėjimu, kai maršrutizatorius praneša ką kita, yra aiškiausias vertėjo aukščiau įrodymas. Išsaugokite abu puslapius pakeitimų žurnale, nes ginčas dėl to, kam priklauso kuri riba, vyksta daug greičiau su dviem datuotomis nuotraukomis.

Patvirtinkite klausytoją ir peradresavimą

Testas LAN tinkle įrodo, kad paslauga veikia lokaliai, ir neįrodo nieko apie pasiekiamumą iš išorės. Daugelis maršrutizatorių atsako į savo peradresavimo taisyklę iš vidaus, todėl plaukų segtuko testas pavyksta, nors išorinis kelias dar uždarytas. Patvirtinkite, kad demonas pririštas prie adreso ir prievado, kuriuos manote, ir tada testuokite iš išorės. Viskas žemiau yra tik skaitymui.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Jei išorinis testas rodo, kad į maršrutizatorių neateina nė vienas paketas, praradimas įvyko aukščiau ir jokia vietinė taisyklė to nepataisys. Jei paketai ateina ir niekas neatsako, kita riba yra klausytojas arba pagrindinio kompiuterio užkarda. Paketų gaudymas pagrindiniame kompiuteryje nustato, kurį iš dviejų matote, ir tai užima mažiau laiko nei dar vienas taisyklių spėjimo ratas. Lygindami palikite klausytoją ir jo transportą nepakeistus, kitaip kitas testas atsakys į kitą klausimą.

Keiskite topologiją, o ne tą pačią taisyklę

Kai vertėjas priklauso tiekėjui, sprendimas yra kitas kelias, o ne dar vienas peradresavimas. Mažas VPS su viešu adresu, sujungtas išeinančiu tuneliu iš namų pusės, padeda pasiekiamą galinį tašką prieš paslaugą. Tiekėjo suteiktas viešas adresas yra paprastesnis ten, kur jo yra, ir paprastai pigesnis nei išlaikyti mašiną. IPv6 visiškai pašalina vertimą, jei kliento tinklas, DNS įrašai ir užkardos politika visi tai palaiko.

Dinaminis DNS atnaujina tik vardą; jis nesukuria pasiekiamumo, o nukreipimas į bendrą adresą siunčia klientus į tiekėjo vartus, kuriuos naudoja ir kiti abonentai. Ta nesėkmė atrodo lygiai kaip miręs serveris, todėl ankstesnių žingsnių įrašas yra svarbus. Užsirašykite, į kokį adresą vardas išsisprendė, kai testas nepavyko, ir laikykite atsakymą kartu su testo rezultatu.

Perrašykite planą aplink ribą, kurią kontroliuojate: klausytoją, tunelį ir maršrutus. Laikykite seną peradresavimą tik tol, kol jis dar aprašo ką nors teisingo, nes taisyklė, kuri nebeatitinka topologijos, yra blogiau nei jokios taisyklės. Užrašykite, kuris sluoksnis iš tikrųjų blokavo ir koks įrodymas tai parodė. Priešingu atveju kitas žmogus, atidaręs administravimo puslapį, pakartos kiekvieną šio kelio žingsnį nuo pradžių.