Cine ar trebui să dețină rutele și DNS-ul când se conectează openfortivpn?

Patru etape se suprapun într-o sesiune openfortivpn funcțională. Clientul se autentifică la gateway și începe o conexiune TLS, apoi rulează PPP în interiorul acelei conexiuni, apoi primește o adresă și informații DNS și, în final, aplică rutele de gazdă și setările resolverului. Fiecare etapă poate fi activă în timp ce următoarea nu este, și de aceea „conectat” este un cuvânt atât de alunecos în firele de asistență.

Decizia care elimină cea mai mare parte a confuziei este cine deține ultima etapă. Fie clientul VPN aplică singur modificările la gazdă, fie o face o altă componentă, iar amestecarea celor două pe jumătate este modul în care rutele și fișierele resolverului ajung să descrie sesiuni diferite.

Patru etape care par o singură conexiune

Prima etapă este admiterea. un domeniu de autentificare cu nume sau un cod de unică folosință și primește parametrii de care are nevoie pentru a continua. Când clientul afișează că este conectat la gateway, asta înseamnă că transportul TLS este activ. Nu înseamnă că PPP a negociat și cu siguranță nu înseamnă că o aplicație internă este accesibilă.

A doua etapă este legătura PPP. Clientul pornește un proces PPP împotriva dispozitivului de tunel, iar cele două părți negociază opțiunile legăturii și adresele. Abia după aceea gazda știe ce adrese locale și îndepărtate folosește sesiunea și abia atunci o rută către tunel poate avea sens.

A treia etapă este aplicarea acestor informații la gazdă, și aici contează proprietatea. Clientul poate adăuga rutele și rescrie configurația resolverului, sau i se poate spune să se retragă și să le lase pe amândouă în seama oricui altceva gestionează rețeaua pe acea mașină. README proiectului le descrie ca responsabilități separate, nu ca un singur comportament automat.

Cine editează tabela de rutare

Implicit, clientul este proprietarul. Adaugă o rută către gateway prin interfața fizică, o rută pentru partenerul tunelului și rute pentru rețelele pe care sesiunea are voie să le folosească, apoi le elimină când procesul se încheie. Acel implicit este comod pe un laptop cu un singur manager de rețea și fără alt software VPN.

Alegeți predarea doar când altceva deține cu adevărat rutarea. O integrare cu managerul de rețea, un spațiu de nume de rețea al unui container sau un agent de rutare la nivel de site pot ști deja cum să instaleze și să curețe aceleași prefixe. Trecerea opțiunii no-routes împiedică atunci doi scriitori să se lupte pentru aceeași tabelă, ceea ce este o cursă care se manifestă ca pierdere intermitentă a unei subrețele, nu ca o defecțiune curată.

Suprapunerea este al doilea motiv pentru predare. Dacă rutele împinse includ un prefix pe care rețeaua locală îl folosește deja, clientul nu poate rezolva conflictul pentru dumneavoastră. Cineva trebuie să decidă dacă acel prefix este accesibil prin tunel, prin legătura fizică sau printr-o rută mai specifică, iar acea decizie aparține celui care deține topologia.

Curățarea este al treilea. Un client care se prăbușește înainte de a-și elimina rutele lasă o gaură neagră care supraviețuiește sesiunii, iar următoarea conexiune poate adăuga un duplicat peste ea. Cine deține rutarea deține și verificarea că vechile intrări au dispărut. Faceți din acea verificare parte a căii de pornire, nu un pas opțional de curățare.

Cine deține DNS-ul și fișierul resolverului

DNS este aceeași decizie cu margini mai ascuțite. Clientul poate accepta serverele DNS pe care le raportează gateway-ul sau partenerul PPP și le poate scrie în configurația resolverului gazdei. Pe o mașină simplă, exact asta doriți, deoarece numele interne se rezolvă atunci doar cât timp tunelul este activ.

Pe un host Linux modern, resolverul poate fi gestionat de un stub local, iar rescrierea fișierului resolverului în spatele acelui stub produce o configurație care pare corectă și se comportă inconsecvent. Dacă gazda rulează deja un manager de resolver, lăsați-l să dețină DNS-ul și alimentați-l cu serverele tunelului prin interfața sa acceptată. Opțiunea no-dns a clientului este alegerea corectă acolo, nu o ocolire.

DNS-ul divizat este o întrebare separată de cine scrie fișierul. Trimiterea fiecărei interogări prin tunel este simplă și lentă; trimiterea doar a zonelor interne prin el necesită configurare pe domeniu pe care majoritatea clienților simpli nu o oferă. Decideți ce comportament are nevoie gazda înainte de a activa modificările resolverului clientului. O alegere greșită aici arată ca o cădere a rezolvării numelor chiar și când tunelul este în regulă.

Privilegii, disponibilitate și predarea

Crearea dispozitivului de tunel și editarea rutelor gazdei sau a stării resolverului necesită autoritate de rețea ridicată. Greșeala obișnuită este să se concluzioneze că, prin urmare, totul trebuie să ruleze ca root, inclusiv browserul sau aplicația care folosește tunelul. Păstrați partea privilegiată mică: clientul și fișierul său de configurare, deținute de un administrator, în timp ce aplicațiile utilizatorului își păstrează contul normal.

Disponibilitatea ar trebui definită per consumator. Un supraveghetor poate considera serviciul pornit când procesul clientului rulează și dispozitivul de tunel există. Un job de backup ar trebui să considere VPN-ul utilizabil doar când punctul său final de stocare răspunde prin tunel. Acestea sunt verificări diferite, iar folosirea celei mai slabe pentru scopul cel mai puternic produce joburi care pornesc prea devreme și eșuează intermitent. Scrieți definiția aleasă, deoarece un supraveghetor și un job care nu sunt de acord asupra disponibilității sunt un tichet de asistență care așteaptă să se întâmple.

Testați contractul cu patru observații: faza gateway-ului se încheie, PPP atribuie adrese, ruta dorită este prezentă și o cerere către o gazdă internă reușește. Apoi opriți clientul și confirmați că fiecare dintre acestea a fost eliminat sau restaurat. Dacă gazda încă rezolvă nume interne sau încă păstrează o rută după închiderea tunelului, predarea proprietății este incompletă.