Kas turėtų valdyti maršrutus ir DNS, kai prisijungia openfortivpn?

Veikiančioje openfortivpn sesijoje keturi etapai sluoksniuojasi vienas ant kito. Klientas autentifikuojasi prie šliuzo ir pradeda TLS ryšį, tada tame ryšyje paleidžia PPP, tada gauna adresą ir DNS informaciją, ir galiausiai pritaiko pagrindinio kompiuterio maršrutus bei resolverio nustatymus. Kiekvienas etapas gali būti gyvas, kol kitas nėra, ir todėl „prisijungta“ yra toks slidus žodis palaikymo temose.

Sprendimas, kuris pašalina didžiąją dalį painiavos, yra tai, kas valdo paskutinį etapą. Arba VPN klientas pats pritaiko pagrindinio kompiuterio pakeitimus, arba tai daro kitas komponentas, o dviejų sumaišymas per pusę yra priežastis, kodėl maršrutai ir resolverio failai galiausiai aprašo skirtingas sesijas.

Keturi etapai, kurie atrodo kaip vienas ryšys

Pirmas etapas yra priėmimas. pavadinta autentifikacijos sritis arba vienkartiniu kodu, ir gauna parametrus, kurių reikia norint tęsti. Kai klientas išspausdina, kad prisijungė prie šliuzo, tai reiškia, kad TLS transportas veikia. Tai nereiškia, kad PPP suderėjo, ir tikrai nereiškia, kad vidinė programa pasiekiama.

Antras etapas yra PPP ryšys. Klientas paleidžia PPP procesą prie tunelio įrenginio, ir abi pusės derasi dėl ryšio parinkčių ir adresų. Tik po to pagrindinis kompiuteris žino, kokius vietinius ir nuotolinius adresus naudoja sesija, ir tik tada maršrutas į tunelį gali turėti prasmę.

Trečias etapas yra tos informacijos pritaikymas pagrindiniam kompiuteriui, ir čia svarbi nuosavybė. Klientas gali pridėti maršrutus ir perrašyti resolverio konfigūraciją, arba jam galima liepti atsitraukti ir palikti abu tam, kas kitaip valdo tinklą tame kompiuteryje. Projekto README failas tai aprašo kaip atskiras atsakomybes, o ne vieną automatinį elgesį.

Kas redaguoja maršrutizavimo lentelę

Pagal nutylėjimą savininkas yra klientas. Jis prideda maršrutą link šliuzo per fizinį sąsają, maršrutą tunelio partneriui ir maršrutus tinklams, kuriuos sesijai leidžiama naudoti, o tada pašalina juos, kai procesas baigiasi. Šis nutylėjimas patogus nešiojamajame kompiuteryje su vienu tinklo tvarkykle ir jokia kita VPN programine įranga.

Pasirinkite perdavimą tik tada, kai kažkas kitas tikrai valdo maršrutizavimą. Tinklo tvarkyklės integracija, konteinerio tinklo vardų sritis ar visos svetainės maršrutizavimo agentas jau gali žinoti, kaip įdiegti ir išvalyti tuos pačius priešdėlius. Tada no-routes parinkties perdavimas neleidžia dviem rašytojams kovoti dėl tos pačios lentelės, o tai lenktynės, kurios pasireiškia kaip protarpinis vieno potinklio praradimas, o ne kaip švarus gedimas.

Persidengimas yra antroji perdavimo priežastis. Jei stumiami maršrutai apima priešdėlį, kurį vietinis tinklas jau naudoja, klientas negali išspręsti konflikto už jus. Kažkas turi nuspręsti, ar tas priešdėlis pasiekiamas per tunelį, per fizinį ryšį, ar per konkretesnį maršrutą, ir tas sprendimas priklauso tam, kas valdo topologiją.

Valymas yra trečiasis. Klientas, kuris sugenda prieš pašalindamas savo maršrutus, palieka juodą duobę, kuri pergyvena sesiją, ir kitas ryšys gali pridėti dublikatą ant jos. Kas valdo maršrutizavimą, tas valdo ir patikrinimą, kad seni įrašai dingo. Padarykite tą patikrinimą paleidimo kelio dalimi, o ne neprivalomu valymo žingsniu.

Kas valdo DNS ir resolverio failą

DNS yra tas pats sprendimas su aštresniais kraštais. Klientas gali priimti DNS serverius, kuriuos praneša šliuzas ar PPP partneris, ir įrašyti juos į pagrindinio kompiuterio resolverio konfigūraciją. Paprastame kompiuteryje tai yra būtent tai, ko norite, nes vidiniai vardai tada sprendžiami tik tol, kol tunelis veikia.

Šiuolaikiniame Linux pagrindiniame kompiuteryje resolverį gali valdyti vietinis stub, o resolverio failo perrašymas už to stub nugaros sukuria konfigūraciją, kuri atrodo teisinga ir elgiasi nenuosekliai. Jei pagrindinis kompiuteris jau paleidžia resolverio tvarkyklę, leiskite jai valdyti DNS ir per jos palaikomą sąsają perduokite jai tunelio serverius. Kliento no-dns parinktis ten yra teisingas pasirinkimas, o ne apeiga.

Padalintas DNS yra atskiras klausimas nuo to, kas rašo failą. Siųsti kiekvieną užklausą per tunelį yra paprasta ir lėta; siųsti tik vidines zonas per jį reikalauja kiekvieno domeno konfigūracijos, kurios dauguma paprastų klientų nesiūlo. Nuspręskite, kokio elgesio reikia pagrindiniam kompiuteriui, prieš įjungdami kliento resolverio pakeitimus. Neteisingas pasirinkimas čia atrodo kaip vardų sprendimo sutrikimas, net kai pats tunelis yra geras.

Privilegijos, pasirengimas ir perdavimas

Tunelio įrenginio kūrimas ir pagrindinio kompiuterio maršrutų ar resolverio būsenos redagavimas reikalauja padidintų tinklo teisių. Dažna klaida yra manyti, kad todėl viskas turi veikti kaip root, įskaitant naršyklę ar programą, kuri naudoja tunelį. Laikykite privilegijuotą dalį mažą: klientas ir jo konfigūracijos failas, priklausantys administratoriui, o naudotojo programos išlaiko įprastą paskyrą.

Pasirengimas turėtų būti apibrėžtas kiekvienam vartotojui. Prižiūrėtojas gali laikyti paslaugą paleista, kai kliento procesas veikia ir tunelio įrenginys egzistuoja. Atsarginių kopijų užduotis turėtų laikyti VPN naudojamą tik tada, kai jos saugojimo galutinis taškas atsako per tunelį. Tai skirtingi patikrinimai, o silpnesnio naudojimas stipresniam tikslui sukuria užduotis, kurios pradedamos per anksti ir protarpiais nepavyksta. Užrašykite pasirinktą apibrėžimą, nes prižiūrėtojas ir užduotis, nesutariantys dėl pasirengimo, yra pagalbos bilietas, laukiantis įvykio.

Išbandykite sutartį keturiais stebėjimais: šliuzo etapas baigiamas, PPP priskiria adresus, numatytas maršrutas yra, ir užklausa vidiniam kompiuteriui pavyksta. Tada sustabdykite klientą ir patvirtinkite, kad kiekvienas iš jų pašalintas arba atkurtas. Jei po tunelio uždarymo pagrindinis kompiuteris vis dar sprendžia vidinius vardus arba vis dar laiko maršrutą, nuosavybės perdavimas yra nepilnas.