Wie moet eienaarskap van roetes en DNS hê wanneer openfortivpn verbind?

Vier stadiums bou op mekaar in 'n werkende openfortivpn-sessie. Die kliënt verifieer by die deurgang en begin 'n TLS-verbinding, hardloop dan PPP binne daardie verbinding, ontvang dan 'n adres en DNS-inligting, en pas uiteindelik gasheerroetes en resolver-instellings toe. Elke stadium kan lewendig wees terwyl die volgende een dit nie is nie, en daarom is “connected” so 'n glibberige woord in ondersteuningsdrade.

Die beslissing wat die meeste verwarring verwyder, is wie die laaste stadium besit. Óf die VPN-kliënt pas self die gasheerveranderinge toe, óf 'n ander komponent doen dit, en om die twee halfpad te meng, is hoe roetes en resolver-lêers uiteindelik verskillende sessies beskryf.

Vier stadiums wat soos een verbinding lyk

Die eerste stadium is toegang. 'n benoemde verifikasiedomein of 'n eenmalige kode, en ontvang die parameters wat dit nodig het om voort te gaan. Wanneer die kliënt druk dat dit aan die deurgang gekoppel is, beteken dit die TLS-vervoer is op. Dit beteken nie dat PPP onderhandel het nie, en dit beteken beslis nie dat 'n interne toepassing bereikbaar is nie.

Die tweede stadium is die PPP-skakel. Die kliënt begin 'n PPP-proses teen die tonneltoestel, en die twee kante onderhandel skakelopsies en adresse. Eers daarna weet die gasheer watter plaaslike en afgeleë adresse die sessie gebruik, en eers dan kan 'n roete wat in die tonnel wys, sin maak.

Die derde stadium pas daardie inligting op die gasheer toe, en dit is waar eienaarskap saak maak. Die kliënt kan die roetes byvoeg en die resolver-konfigurasie herskryf, of dit kan opdrag kry om terug te staan en beide oor te laat aan wat ook al netwerk op daardie masjien bestuur. Die projek se README beskryf dit as afsonderlike verantwoordelikhede eerder as een outomatiese gedrag.

Wie redigeer die roetetabel

By verstek is die kliënt die eienaar. Dit voeg 'n roete na die deurgang deur die fisiese koppelvlak by, 'n roete vir die tonnel se eweknie, en roetes vir die netwerke wat die sessie mag gebruik, en verwyder dit dan wanneer die proses eindig. Daardie verstek is gerieflik op 'n skootrekenaar met 'n enkele netwerkbestuurder en geen ander VPN-sagteware nie.

Kies die oorhandiging net wanneer iets anders werklik roetering besit. 'n Netwerkbestuurder-integrasie, 'n houer-netwerknaamruimte of 'n werfwyde roeteringsagent weet dalk reeds hoe om dieselfde voorvoegsels te installeer en op te ruim. Om die no-routes-opsie te gebruik, verhoed dan dat twee skrywers oor dieselfde tabel veg, wat 'n wedloop is wat as wisselvallige verlies van een subnet eerder as as 'n skoon fout opduik.

Oorvleueling is die tweede rede om oor te dra. As die gestuurde roetes 'n voorvoegsel insluit wat die plaaslike netwerk reeds gebruik, kan die kliënt nie die konflik vir jou oplos nie. Iemand moet besluit of daardie voorvoegsel deur die tonnel, deur die fisiese skakel of deur 'n meer spesifieke roete bereikbaar is, en daardie beslissing behoort aan wie ook al die topologie besit.

Opruim is die derde. 'n Kliënt wat val voordat dit sy roetes verwyder, laat 'n swart gat wat die sessie oorleef, en die volgende verbinding kan 'n duplikaat bo-op dit voeg. Wie roetering besit, besit ook die verifiëring dat die ou inskrywings weg is. Maak daardie kontrole deel van die opstartpad, nie 'n opsionele opruimstap nie.

Wie besit DNS en die resolver-lêer

DNS is dieselfde beslissing met skerper rande. Die kliënt kan die DNS-bedieners aanvaar wat die deurgang of PPP-eweknie rapporteer en dit in die gasheer se resolver-konfigurasie skryf. Op 'n eenvoudige masjien is dit presies wat jy wil hê, want interne name los dan net op terwyl die tonnel op is.

Op 'n moderne Linux-gasheer kan die resolver deur 'n plaaslike stub bestuur word, en om die resolver-lêer agter daardie stub se rug te herskryf, lewer 'n konfigurasie wat korrek lyk en inkonsekwent optree. As die gasheer reeds 'n resolver-bestuurder het, laat dit DNS besit en voer die tonnel se bedieners deur sy ondersteunde koppelvlak in. Die kliënt se no-dns-opsie is daar die korrekte keuse, nie 'n noodoplossing nie.

Split-DNS is 'n aparte vraag van wie die lêer skryf. Om elke navraag deur die tonnel te stuur, is eenvoudig en stadig; om slegs interne sones daardeur te stuur, vereis per-domein-konfigurasie wat die meeste eenvoudige kliënte nie bied nie. Besluit watter gedrag die gasheer nodig het voordat jy die kliënt se resolver-veranderinge aktiveer. 'n Verkeerde keuse hier lyk soos 'n naamoplossingsonderbreking selfs wanneer die tonnel self goed is.

Voorreg, gereedheid en die oorhandiging

Om die tonneltoestel te skep en gasheerroetes of resolver-toestand te wysig, vereis verhoogde netwerkgesag. Die algemene fout is om af te lei dat alles daarom as root moet hardloop, insluitend die blaaier of die toepassing wat die tonnel gebruik. Hou die bevoorregte deel klein: die kliënt en sy konfigurasielêer, wat deur 'n administrateur besit word, terwyl gebruikerstoepassings hul normale rekening behou.

Gereedheid moet per verbruiker gedefinieer word. 'n Toesighouer kan die diens as begin beskou wanneer die kliëntproses loop en die tonneltoestel bestaan. 'n Rugsteuntaak moet die VPN eers as bruikbaar beskou wanneer sy bergingseindpunt deur die tonnel antwoord. Dit is verskillende kontroles, en om die swakker een vir die sterker doel te gebruik, lewer take wat te vroeg begin en wisselvallig misluk. Skryf die gekose definisie neer, want 'n toesighouer en 'n taak wat oor gereedheid verskil, is 'n ondersteuningskaartjie wat wag om te gebeur.

Toets die kontrak met vier waarnemings: die deurgangfase voltooi, PPP ken adresse toe, die beoogde roete is teenwoordig, en 'n versoek aan 'n interne gasheer slaag. Stop dan die kliënt en bevestig dat elkeen van daardie dinge verwyder of herstel is. As die gasheer nog steeds interne name oplos of nog steeds 'n roete hou nadat die tonnel gesluit het, is die eienaarskapoorhandiging onvolledig.