Žiniatinklio serveris dingsta, kai prisijungia VPN klientas

Paslauga, kuri dingsta tuo metu, kai prisijungia VPN klientas, paprastai nėra blokuojama, ji atsako per netinkamą sąsają. Užklausa atvyksta į fizinę tinklo plokštę, demonas parašo atsakymą, o maršrutizavimo lentelė perduoda tą atsakymą tuneliui, nes tunelis perėmė numatytąjį maršrutą. Nuotolinis klientas niekada nemato atsakymo į jo atidarytą ryšį, todėl laukia ir tada praneša apie laiko limito viršijimą. Jokia ugniasienės taisyklė niekur tame plane nedalyvauja.

Simptomas: užklausos į vidų, atsakymai pro netinkamas duris

Požymis yra įeinantis ryšys, kuris nepavyksta, nors viskas kita priegloboje veikia. Kitas požymis yra priegloba, pasiekiama iš LAN, bet ne iš interneto, arba tokia, kuri veikia tol, kol tunelis vėl prisijungia, ir tada sustoja. Kiekvienu atveju tiesioginė kryptis veikė, o grįžtamoji ne, kas rodo maršrutizavimo asimetriją, o ne politiką.

Patvirtinkite tai stebėdami, kur eina atsakymas, o ne stebėdami, kaip atvyksta užklausa.

Fiksuokite vienu metu fizinėje sąsajoje ir tunelio įrenginyje. Jei užklausa pasirodo fizinėje sąsajoje, o atsakymas tunelyje, diagnozė baigta. Atsakymas, kuris niekur nepasirodo, reiškia, kad paslauga niekada nepriėmė ryšio, o tai yra atskiras tyrimas su atskira priežastimi.

Du numatytieji maršrutai ir vienas maršrutizavimo sprendimas

Klientas, įdiegiantis numatytąjį maršrutą, prideda antrą įrašą su geresne metrika nei LAN tinklų sietuvas. Kai kurie klientai vietoj to įdiegia du pusės intervalo maršrutus, kurie tą pačią erdvę dengia tiksliau ir laimi paiešką taip pat. Abi technikos palieka įprastus išeinančius paketus rinktis tunelio sąsają.

Tas pasirinkimas daromas tik pagal paskirties vietą. Branduolys nesiteirauja, iš kur atėjo paketas, nebent politikos taisyklė jam tai įsako. Taigi atsakymas į viešą kliento adresą perduodamas tuneliui, kurio tolimas galas gauna paketą su šaltinio adresu, kurio jam nepriklauso, ir jį išmeta arba persiunčia kur nors nenaudingai. Linux atveju griežtas atvirkštinio kelio filtravimas taip pat gali išmesti pradinę užklausą dar prieš tai, kai jūsų paslauga ją pamato, o tai iš išorės atrodo identiškai. Abu simptomai kyla iš to paties trūkstamo ryšio tarp įeinančio srauto ir jo atsakymo.

Tunelis elgiasi teisingai visą laiką. Jam buvo liepta nešti numatytąjį maršrutą, ir jis daro būtent tai.

Pataisykite grįžtamąjį kelią nesulaužydami tunelio

Yra trys ilgalaikės taisymo formos, o pasirinkimas priklauso nuo to, kiek paties prieglobos srauto turėtų likti tunelio viduje. Paslaugos paskirties vietos ar prievado pašalinimas yra mažiausias pakeitimas. Politikos maršrutizavimas pagal šaltinį ar žymą yra tiksliausias. Šaltinio vertimas yra grubiausias ir lengviausiai paaiškinamas po dvejų metų.

Rinkitės pagal tai, ką turi daryti priegloba, o ne pagal tai, kurią ištrauką radote pirmą.

Paskirties vietos pašalinimas tinka paslaugai su stabiliu viešu adresu, o demono susiejimas su fiziniu adresu, o ne su visais adresais, daro tą pašalinimą saugesnį. Politikos taisyklė, kuri parenka lentelę pagal šaltinį, išlaiko prieglobos ryšius tunelio viduje ir tuo pačiu grąžina paslaugos atsakymus per WAN tinklų sietuvą. Atsakymų maskavimas WAN sąsajoje pasiekia tą patį kelią už tai, kad kliento adresas paslepiamas nuo paslaugos žurnalų. Numatomojo maršruto ad hoc pakeitimas yra diagnostika, o ne konfigūracija, nes klientas perrašo maršrutus kiekvieną kartą prisijungdamas iš naujo.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Kai priegloba maršrutizuoja ir už jo esančiam LAN

Vienu šuoliu toliau ta pati asimetrija grįžta su daugiau judančių dalių. Srautas pasiekia maršrutizatorių iš interneto, persiunčiamas vidiniam įrenginiui, o vienintelis to įrenginio grįžimo kelias yra tunelis, todėl atsakymas pasiekia pirminį klientą iš paties tiekėjo adreso. Tada ryšių sekimas susiduria su atsakymu srautui, kurio pradžios nematė, ir jį išmeta. Klientas tuo tarpu nemato visiškai nieko.

Du pakeitimai tai taiso: paskirties vertimas, kad įeinantis ryšys pasiektų vidinį įrenginį, ir šaltinio vertimas, kad to įrenginio atsakymas atrodytų ateinantis iš paties maršrutizatoriaus.

Maršrutizatoriaus programinėje įrangoje įprasta išraiška yra politikos taisyklė, kuri prievado persiuntimą pritvirtina prie WAN pusės, o paties maršrutizatoriaus srautas keliauja tuneliu. Be šaltinio vertimo tas atsakymas adresuotas išoriniam klientui, o vidinis įrenginys tiesiog neturi maršruto į jį. Išbandykite tris dalykus atskirai, nes jie nepavyksta dėl skirtingų priežasčių: ryšį, ateinantį iš išorės, tą, kurį pati priegloba pradeda, ir vardo paiešką.