Qui hauria de posseir les rutes i el DNS quan es connecta openfortivpn?

Quatre etapes s'apilen les unes sobre les altres en una sessió d'openfortivpn que funciona. El client s'autentica a la passarel·la i inicia una connexió TLS, després executa PPP dins d'aquesta connexió, després rep una adreça i informació DNS, i finalment aplica rutes d'amfitrió i paràmetres del resolutor. Cada etapa pot estar viva mentre la següent no ho està, i per això “connectat” és una paraula tan relliscosa als fils de suport.

La decisió que elimina la major part de la confusió és qui posseeix l'última etapa. O bé el client VPN aplica ell mateix els canvis a l'amfitrió, o bé els fa un altre component, i barrejar els dos a mitges és com les rutes i els fitxers del resolutor acaben descrivint sessions diferents.

Quatre etapes que semblen una sola connexió

La primera etapa és l'admissió. un domini d'autenticació amb nom o un codi d'un sol ús, i rep els paràmetres que necessita per continuar. Quan el client imprimeix que està connectat a la passarel·la, això vol dir que el transport TLS està aixecat. No vol dir que PPP hagi negociat, i sens dubte no vol dir que una aplicació interna sigui accessible.

La segona etapa és l'enllaç PPP. El client inicia un procés PPP contra el dispositiu de túnel, i les dues bandes negocien opcions d'enllaç i adreces. Només després d'això l'amfitrió sap quines adreces locals i remotes fa servir la sessió, i només llavors una ruta cap al túnel pot tenir sentit.

La tercera etapa és aplicar aquesta informació a l'amfitrió, i aquí és on la propietat importa. El client pot afegir les rutes i reescriure la configuració del resolutor, o se li pot ordenar que es faci enrere i deixi les dues coses a qualsevol altre element que gestioni la xarxa en aquella màquina. El README del projecte les descriu com a responsabilitats separades en lloc d'un sol comportament automàtic.

Qui edita la taula d'encaminament

Per defecte, el client és el propietari. Afegeix una ruta cap a la passarel·la per la interfície física, una ruta per al parell del túnel i rutes per a les xarxes que la sessió té permès d'usar, i després les elimina quan el procés surt. Aquest defecte és còmode en un portàtil amb un sol gestor de xarxa i cap altre programari VPN.

Trieu el traspàs només quan una altra cosa posseeixi realment l'encaminament. Una integració de gestor de xarxa, un espai de noms de xarxa de contenidor o un agent d'encaminament de tot el lloc poden saber ja com instal·lar i netejar els mateixos prefixos. Passar l'opció no-routes aleshores evita que dos escriptors es barallin per la mateixa taula, que és una cursa que es manifesta com a pèrdua intermitent d'una subxarxa en lloc d'una fallada neta.

El solapament és la segona raó per fer el traspàs. Si les rutes empenyades inclouen un prefix que la xarxa local ja fa servir, el client no pot resoldre el conflicte per vosaltres. Algú ha de decidir si aquest prefix és abastable pel túnel, pel enllaç físic o per una ruta més específica, i aquesta decisió pertany a qui posseeix la topologia.

La neteja és la tercera. Un client que falla abans de treure les seves rutes deixa un forat negre que sobreviu a la sessió, i la connexió següent pot afegir-hi un duplicat a sobre. Qui posseeix l'encaminament també posseeix verificar que les entrades antigues han desaparegut. Feu d'aquesta comprovació part del camí d'inici, no un pas de neteja opcional.

Qui posseeix el DNS i el fitxer del resolutor

El DNS és la mateixa decisió amb arestes més esmolades. El client pot acceptar els servidors DNS que reporta la passarel·la o el parell PPP i escriure'ls a la configuració del resolutor de l'amfitrió. En una màquina simple això és exactament el que voleu, perquè els noms interns llavors es resolen només mentre el túnel està aixecat.

En un amfitrió Linux modern el resolutor pot ser gestionat per un stub local, i reescriure el fitxer del resolutor a l'esquena d'aquest stub produeix una configuració que sembla correcta i es comporta de manera inconsistent. Si l'amfitrió ja executa un gestor de resolutor, deixeu que posseeixi el DNS i alimenteu-lo amb els servidors del túnel a través de la seva interfície suportada. L'opció no-dns del client és la tria correcta allà, no una solució alternativa.

El DNS dividit és una qüestió separada de qui escriu el fitxer. Enviar cada consulta pel túnel és simple i lent; enviar-hi només zones internes requereix configuració per domini que la majoria de clients simples no ofereixen. Decidiu quin comportament necessita l'amfitrió abans d'habilitar els canvis del resolutor del client. Una tria equivocada aquí sembla una caiguda de resolució de noms fins i tot quan el túnel mateix està bé.

Privilegis, disponibilitat i el traspàs

Crear el dispositiu de túnel i editar rutes d'amfitrió o l'estat del resolutor necessita autoritat de xarxa elevada. L'error comú és concloure que, per tant, tot ha de córrer com a root, inclòs el navegador o l'aplicació que usa el túnel. Manteniu petita la part privilegiada: el client i el seu fitxer de configuració, propietat d'un administrador, mentre les aplicacions d'usuari conserven el seu compte normal.

La disponibilitat s'ha de definir per consumidor. Un supervisor pot considerar el servei iniciat quan el procés del client s'executa i el dispositiu de túnel existeix. Una feina de còpia de seguretat hauria de considerar la VPN usable només quan el seu punt de magatzematge respon pel túnel. Són comprovacions diferents, i usar la més feble per al propòsit més fort produeix feines que comencen massa aviat i fallen de manera intermitent. Escriviu la definició triada, perquè un supervisor i una feina que no estan d'acord sobre la disponibilitat són un tiquet de suport esperant a passar.

Proveu el contracte amb quatre observacions: la fase de passarel·la es completa, PPP assigna adreces, la ruta prevista hi és, i una petició a un amfitrió intern té èxit. Després atureu el client i confirmeu que cada una d'aquestes coses s'ha eliminat o restaurat. Si l'amfitrió encara resol noms interns o encara manté una ruta després de tancar el túnel, el traspàs de propietat és incomplet.