Kes peaks openfortivpn-i ühendumisel marsruute ja DNS-i omama?

Töötavas openfortivpn-i seansis kuhjuvad neli etappi üksteise peale. Klient autendib end lüüsi juures ja alustab TLS-ühenduse, seejärel käivitab selle ühenduse sees PPP, saab seejärel aadressi ja DNS-teabe ning rakendab lõpuks hosti marsruudid ja resolveri seaded. Iga etapp võib olla elus, samal ajal kui järgmine ei ole, ja seepärast on “ühendatud” tugilõimedes nii libe sõna.

Otsus, mis kõrvaldab suurema osa segadusest, on see, kes omab viimast etappi. Kas VPN-klient rakendab hosti muudatused ise või teeb seda mõni teine komponent, ja kahe pooleks segamine ongi see, kuidas marsruudid ja resolveri failid lõpuks erinevaid seansse kirjeldavad.

Neli etappi, mis näevad välja nagu üks ühendus

Esimene etapp on vastuvõtt. nimetatud autentimisdomeen või ühekordse koodi kaudu ja saab jätkamiseks vajalikud parameetrid. Kui klient trükib, et ta on lüüsiga ühendatud, tähendab see, et TLS-transport on püsti. See ei tähenda, et PPP on läbi rääkinud, ja kindlasti ei tähenda see, et sisemine rakendus on kättesaadav.

Teine etapp on PPP-link. Klient käivitab tunneliseadme vastu PPP-protsessi ja kaks poolt peavad läbi rääkima lingi valikud ja aadressid. Alles pärast seda teab host, milliseid kohalikke ja kaugemaid aadresse seanss kasutab, ja alles siis on tunnelisse suunatud marsruudil mõtet.

Kolmas etapp on selle teabe rakendamine hostile, ja siin on omand oluline. Klient saab marsruudid lisada ja resolveri konfiguratsiooni ümber kirjutada, või võib talle öelda, et ta taanduks ja jätaks mõlemad sellele, mis muidu selle masina võrku haldab. Projekti README kirjeldab neid eraldi vastutustena, mitte ühe automaatse käitumisena.

Kes marsruutimistabelit muudab

Vaikimisi on omanik klient. See lisab marsruudi lüüsi poole füüsilise liidese kaudu, marsruudi tunneli partnerile ja marsruudid võrkudele, mida seansil on lubatud kasutada, ning eemaldab need protsessi lõppedes. See vaikeväärtus on mugav sülearvutis, kus on üks võrguhaldur ja muud VPN-tarkvara pole.

Vali üleandmine ainult siis, kui miski muu tõesti omab marsruutimist. Võrguhalduri integratsioon, konteineri võrgumimeruum või kogu saidi marsruutimisagent võib juba teada, kuidas samu prefikseid paigaldada ja koristada. no-routes valiku edastamine takistab siis kahel kirjutajal sama tabeli pärast võidelda, mis on võidujooks, mis ilmneb ühe alamvõrgu katkendliku kadumisena, mitte puhta tõrkena.

Kattuvus on teine põhjus üle anda. Kui lükatud marsruudid sisaldavad prefiksit, mida kohalik võrk juba kasutab, ei saa klient konflikti teie eest lahendada. Keegi peab otsustama, kas see prefiks on kättesaadav tunneli kaudu, füüsilise lingi kaudu või täpsema marsruudi kaudu, ja see otsus kuulub sellele, kes topoloogiat omab.

Koristamine on kolmas. Klient, mis kukub enne oma marsruutide eemaldamist, jätab musta augu, mis elab seansist kauem, ja järgmine ühendus võib selle peale duplikaadi lisada. Kes marsruutimist omab, omab ka kontrolli, et vanad kirjed on kadunud. Tee see kontroll algtee osaks, mitte valikuliseks koristamissammuks.

Kes omab DNS-i ja resolveri faili

DNS on sama otsus teravamate servadega. Klient saab vastu võtta DNS-serverid, mida lüüs või PPP-partner teatab, ja kirjutada need hosti resolveri konfiguratsiooni. Lihtsal masinal on see täpselt see, mida soovite, sest sisemised nimed lahenevad siis ainult seni, kui tunnel on püsti.

Kaasaegsel Linuxi hostil võib resolverit hallata kohalik stub, ja resolveri faili selle stubi selja taga ümber kirjutada annab konfiguratsiooni, mis näeb õige välja ja käitub ebajärjekindlalt. Kui host juba käitab resolverihaldurit, laske sellel DNS-i omada ja andke talle tunneli serverid selle toetatud liidese kaudu. Kliendi no-dns valik on seal õige valik, mitte mööramine.

Jagatud DNS on eraldi küsimus sellest, kes faili kirjutab. Iga päringu tunneli kaudu saatmine on lihtne ja aeglane; ainult sisemiste tsoonide saatmine selle kaudu nõuab domeenipõhist konfiguratsiooni, mida enamik lihtsaid kliente ei paku. Otsustage, millist käitumist host vajab, enne kui lubate kliendi resolverimuudatused. Vale valik siin näeb välja nime lahendamise katkestusena isegi siis, kui tunnel ise on korras.

Õigused, valmidus ja üleandmine

Tunneliseadme loomine ja hosti marsruutide või resolveri oleku muutmine nõuab kõrgendatud võrguvolitusi. Tavaline viga on järeldada, et seetõttu peab kõik jooksma rootina, sealhulgas brauser või rakendus, mis tunnelit kasutab. Hoidke privilegeeritud osa väikesena: klient ja selle konfiguratsioonifail administraatori omandis, samal ajal kui kasutajarakendused säilitavad oma tavalise konto.

Valmidus tuleks määratleda iga tarbija jaoks. Supervisor võib lugeda teenuse käivitunuks, kui kliendiprotsess töötab ja tunneliseade on olemas. Varundustöö peaks lugema VPN-i kasutatavaks alles siis, kui selle salvestuslõpppunkt vastab tunneli kaudu. Need on erinevad kontrollid, ja nõrgema kasutamine tugevama eesmärgi jaoks tekitab töid, mis algavad liiga vara ja ebaõnnestuvad katkendlikult. Kirjutage valitud määratlus üles, sest supervisor ja töö, mis valmiduses ei nõustu, on tugipilet, mis ootab juhtumist.

Testige lepingut nelja tähelepanekuga: lüüsi etapp lõpeb, PPP määrab aadressid, kavandatud marsruut on olemas ja päring sisemisele hostile õnnestub. Seejärel peatage klient ja kinnitage, et igaüks neist on eemaldatud või taastatud. Kui host lahendab pärast tunneli sulgemist endiselt sisemisi nimesid või hoiab endiselt marsruuti, on omandi üleandmine puudulik.