Sino ang dapat magmay-ari ng mga ruta at DNS kapag kumokonekta ang openfortivpn?

Apat na yugto ang nagsasalansan sa isa't isa sa isang gumaganang session ng openfortivpn. Nagpapatunay ang kliyente sa gateway at nagsisimula ng koneksiyong TLS, pagkatapos ay nagpapatakbo ng PPP sa loob ng koneksiyong iyon, pagkatapos ay tumatanggap ng address at impormasyon ng DNS, at sa wakas ay inilalapat ang mga ruta ng host at mga setting ng resolver. Maaaring buhay ang bawat yugto habang hindi buhay ang susunod, at iyon ang dahilan kung bakit ang “konektado” ay napakadulas na salita sa mga thread ng suporta.

Ang desisyong nag-aalis ng karamihan ng kalituhan ay kung sino ang may-ari ng huling yugto. Either inilalapat mismo ng kliyente ng VPN ang mga pagbabago sa host, o ginagawa ito ng ibang bahagi, at ang paghahalo ng dalawa sa kalahati ng landas ang dahilan kung bakit ang mga ruta at file ng resolver ay nagtatapos sa paglalarawan ng magkaibang session.

Apat na yugto na mukhang isang koneksiyon

Ang unang yugto ay pagpasok. isang pinangalanang domain ng pagpapatunay o isang beses gamitin na code, at natatanggap ang mga parameter na kailangan nito upang magpatuloy. Kapag nag-print ang kliyente na konektado ito sa gateway, ibig sabihin ay buhay ang transportasyong TLS. Hindi ito nangangahulugan na nakipag-usap na ang PPP, at tiyak na hindi nangangahulugan na maaabot ang isang panloob na aplikasyon.

Ang ikalawang yugto ay ang PPP link. Nagsisimula ang kliyente ng prosesong PPP laban sa aparato ng tunnel, at nakikipag-usap ang dalawang panig sa mga opsiyon ng link at mga address. Pagkatapos lamang nito malalaman ng host kung aling lokal at malayong address ang ginagamit ng session, at doon lamang magkakaroon ng saysay ang rutang patungo sa tunnel.

Ang ikatlong yugto ay ang paglalapat ng impormasyong iyon sa host, at dito mahalaga ang pagmamay-ari. Maaaring idagdag ng kliyente ang mga ruta at muling isulat ang konfigurasyon ng resolver, o maaaring sabihan itong umatras at ipaubaya ang dalawa sa anumang ibang namamahala ng network sa makinang iyon. Ang README ng proyekto ay naglalarawan sa mga ito bilang hiwalay na responsibilidad sa halip na isang awtomatikong pag-uugali.

Sino ang nag-e-edit ng routing table

Bilang default ang kliyente ang may-ari. Nagdaragdag ito ng rutang patungo sa gateway sa pamamagitan ng pisikal na interface, isang ruta para sa peer ng tunnel, at mga ruta para sa mga network na pinapayagang gamitin ng session, pagkatapos ay inaalis ang mga ito kapag lumabas ang proseso. Ang default na iyon ay maginhawa sa isang laptop na may isang network manager at walang ibang VPN software.

Piliin ang paglipat lamang kapag may ibang tunay na nagmamay-ari ng routing. Ang integrasyon ng network manager, isang network namespace ng container, o isang routing agent sa buong site ay maaaring alam na kung paano i-install at linisin ang parehong mga prefix. Ang pagpasa ng opsiyong no-routes ay pumipigil sa dalawang manunulat na mag-away sa parehong table, na isang karerang lumilitaw bilang paminsan-minsang pagkawala ng isang subnet sa halip na malinis na pagkabigo.

Ang overlap ang ikalawang dahilan upang ilipat. Kung ang mga itinulak na ruta ay may kasamang prefix na ginagamit na ng lokal na network, hindi malulutas ng kliyente ang salungatan para sa iyo. Kailangang magpasya ng isang tao kung naaabot ang prefix na iyon sa pamamagitan ng tunnel, ng pisikal na link, o ng mas espesipikong ruta, at ang desisyong iyon ay pag-aari ng sinumang may-ari ng topolohiya.

Ang paglilinis ang ikatlo. Ang kliyenteng nag-crash bago alisin ang mga ruta nito ay nag-iiwan ng itim na butas na nabubuhay nang mas matagal kaysa sa session, at ang susunod na koneksiyon ay maaaring magdagdag ng kopya sa ibabaw nito. Sinumang may-ari ng routing ay may-ari rin ng pagpapatunay na wala na ang lumang mga entry. Gawing bahagi ng startup path ang pagsusuring iyon, hindi opsyonal na hakbang ng paglilinis.

Sino ang may-ari ng DNS at ng file ng resolver

Ang DNS ay ang parehong desisyon na may mas matatalim na gilid. Maaaring tanggapin ng kliyente ang mga server ng DNS na iniuulat ng gateway o ng PPP peer at isulat ang mga ito sa konfigurasyon ng resolver ng host. Sa simpleng makina iyon ang eksaktong gusto mo, dahil ang mga panloob na pangalan ay nalulutas lamang habang buhay ang tunnel.

Sa modernong host ng Linux ang resolver ay maaaring pamahalaan ng lokal na stub, at ang muling pagsulat ng file ng resolver sa likod ng stub na iyon ay gumagawa ng konfigurasyong mukhang tama at kumikilos nang hindi pare-pareho. Kung nagpapatakbo na ang host ng manager ng resolver, hayaang ito ang may-ari ng DNS at pakainin ito ng mga server ng tunnel sa pamamagitan ng sinusuportahang interface nito. Ang opsiyong no-dns ng kliyente ang tamang pagpili doon, hindi isang paraan ng pag-iwas.

Ang split DNS ay hiwalay na tanong sa kung sino ang nagsusulat ng file. Ang pagpapadala ng bawat query sa tunnel ay simple at mabagal; ang pagpapadala lamang ng mga panloob na zone dito ay nangangailangan ng konfigurasyon kada domain na hindi iniaalok ng karamihan ng simpleng kliyente. Magpasya kung anong pag-uugali ang kailangan ng host bago paganahin ang mga pagbabago sa resolver ng kliyente. Ang maling pagpili dito ay mukhang pagkawala ng paglutas ng pangalan kahit maayos ang tunnel mismo.

Pribilehiyo, kahandaan, at ang paglipat

Ang paglikha ng aparato ng tunnel at pag-edit ng mga ruta ng host o estado ng resolver ay nangangailangan ng mataas na awtoridad sa network. Ang karaniwang pagkakamali ay ang tapusin na kaya lahat ay dapat tumakbo bilang root, kasama ang browser o ang aplikasyong gumagamit ng tunnel. Panatilihing maliit ang may pribilehiyong bahagi: ang kliyente at ang file ng konfigurasyon nito, pag-aari ng isang administrador, habang ang mga aplikasyon ng gumagamit ay pinapanatili ang kanilang normal na account.

Ang kahandaan ay dapat tukuyin kada mamimili. Maaaring ituring ng superbisor na nasimulan ang serbisyo kapag tumatakbo ang proseso ng kliyente at umiiral ang aparato ng tunnel. Dapat ituring ng trabahong backup na magagamit ang VPN lamang kapag tumugon ang endpoint ng imbakan nito sa pamamagitan ng tunnel. Magkaibang pagsusuri ang mga ito, at ang paggamit ng mas mahina para sa mas malakas na layunin ay gumagawa ng mga trabahong nagsisimula nang masyadong maaga at pumapalya nang paminsan-minsan. Isulat ang piniling kahulugan, dahil ang superbisor at trabahong hindi nagkakasundo sa kahandaan ay isang tiket ng suporta na naghihintay mangyari.

Subukan ang kontrata sa apat na obserbasyon: nakumpleto ang yugto ng gateway, naglalaan ang PPP ng mga address, naroroon ang nilalayong ruta, at nagtatagumpay ang kahilingan sa isang panloob na host. Pagkatapos ay ihinto ang kliyente at tiyakin na ang bawat isa sa mga iyon ay inalis o naibalik. Kung nalulutas pa rin ng host ang mga panloob na pangalan o hawak pa rin ang isang ruta pagkatapos magsara ang tunnel, hindi kumpleto ang paglipat ng pagmamay-ari.