Arribar a un prefix privat per VPN és un requisit amb durada: es manté mentre aquella connexió és utilitzable i acaba quan acaba la connexió. Un script d'inici de sessió no ho pot expressar, perquè l'inici de sessió i l'aixecament del túnel són moments diferents, i el túnel que existeix en iniciar sessió pot no ser el que porta trànsit un minut després. La primera decisió no és quina ordre executar. És quin component posseeix el prefix.

El prefix necessita un propietari, no un moment

Comenceu escrivint el requisit com una frase amb subjecte: arribeu 10.77.0.0/24 per la VPN d'Oficina mentre aquella connexió estigui aixecada. Aquesta frase anomena el prefix, la connexió i la condició, i descarta immediatament dos substituts populars: un hook d'inici de sessió i un nom d'interfície com ara ppp0 o utun2.

Els noms d'interfície s'assignen en temps d'execució i no són estables entre reconnexions. Un hook que coincideix amb el nom que va veure la setmana passada o bé no s'activarà o s'activarà contra la interfície d'un altre. Tots dos resultats es presenten com un error d'encaminament i no com la suposició obsoleta que són. La mateixa objecció s'aplica a qualsevol script lligat a un nom que només existeix mentre un túnel concret està aixecat.

Utilitzeu una font d'intenció de ruta admesa

La passarel·la, un perfil gestionat o el mecanisme de rutes documentat del client propietari és on això pertoca, sempre que aquest mecanisme pugui expressar el requisit. Quin s'aplica depèn del protocol i del proveïdor, i les claus no viatgen entre ells, així que un valor que configura un perfil OpenVPN no us diu res sobre el client nadiu L2TP o IKEv2.

MechanismCan carry extra prefixesWho owns the lifetime
Gateway-pushed routesOften, if the gateway is configured for itThe connection
Managed profile settingsDepends on the client and profile formatThe profile
Provider tunnel settingsYes, as included and excluded routesThe provider process
Manual commandYes, onceNobody

Per als desenvolupadors de túnels de paquets, la configuració de túnel IPv4 d'Apple exposa explícitament les rutes incloses i excloses, i IPv6 té la seva contrapart. Són API que utilitza el proveïdor, no proves que tots els panells VPN natius ofereixin a l'administrador una llista arbitrària de rutes. Si la combinació actual no pot expressar els prefixos que necessiteu, el següent pas és un camí de configuració admès per l'operador, no una altra aplicació instal·lada amb l'esperança que es comporti millor.

La vida útil inclou la neteja

De vegades un ajudant extern és realment necessari, i aleshores «afegeix la ruta» és la part més petita de la seva feina. Ha de saber a quina connexió serveix i quina interfície utilitza aquesta connexió, esperar que l'estat de xarxa rellevant s'assenti, romandre idempotent quan s'executa dues vegades seguides, i no netejar res que no hagi instal·lat ell mateix.

Aquesta darrera clàusula és la que fa mal. Un ajudant que esborra totes les rutes que coincideixen amb el prefix d'oficina, tard o d'hora esborrarà una ruta que no havia afegit. La caiguda resultant es carrega al client VPN, perquè el client és la part que l'usuari veu. Decidir què posseeix un ajudant abans d'escriure'l surt més barat que explicar després per què una subxarxa local ha deixat de respondre.

La cursa de la reconnexió

Penseu en una reconnexió ràpida. La sessió A cau, la sessió B s'aixeca i instal·la la seva ruta, i llavors finalment s'executa la neteja ajornada d'A. Si aquesta neteja elimina rutes per prefix, s'endú l'estat vàlid de B, i la connexió que funcionava fa un segon ara encamina cap a enlloc.

Això és una cursa de propietat, i afegir una espera a l'script només canvia quin costat la guanya. La solució és fer la neteja condicional a la identitat: compareu la interfície i la sessió que l'ajudant va instal·lar amb les que encara són vigents, i elimineu només quan coincideixin.

Què cal provar i què no pot fer una ruta

L'acceptació ha de cobrir quatre transicions: la primera connexió, una reconnexió a una interfície diferent, un intent de connexió fallit i la desconnexió final. Després de cadascuna, llegiu la ruta que el sistema va triar realment per a una adreça del costat remot, no la que esperàveu que triés.

route -n get 10.77.0.5
netstat -rn -f inet

Incloeu els casos incòmodes en la mateixa passada: IPv6 on calgui, un prefix local que se solapi amb el remot, i la ruta al propi punt final públic de la VPN, que ha de continuar funcionant mentre el túnel estigui aixecat. Després anoteu què no és una ruta. Selecciona paquets; no atorga permís al costat remot i no crea un camí de tornada, i això continuen sent requisits separats amb propietaris separats.

El resultat que voleu és un prefix que segueix el seu propietari de connexió admès per cada transició, i no una ordre que va sortir bé una vegada per casualitat a la màquina on es va escriure.

Articles relacionats