Dos salts VPN en un sol Pi: quina ruta transporta quin parell

Dues adreces de túnel en una sola placa petita semblen un error, i el reflex és esborrar-ne una. Aquest reflex trenca allò que havia de posar en ordre. Un amfitrió que porta dos salts té una adreça per cada connexió, i cada adreça la selecciona una ruta diferent. La pregunta que val la pena fer és quina ruta tria quin transportista per a quina destinació, no quantes adreces hi ha.

Tres destinacions que necessiten transportistes diferents

Una cadena de dos salts és tres classes de destinació apilades, i cada una la porta una connexió diferent. Cal arribar al parell exterior per l'enllaç físic. Cal arribar al parell interior a través del túnel exterior. Cal arribar a la destinació de l'aplicació coberta a través del túnel interior, el transport del qual el porta el túnel exterior.

Ompliu les files amb les adreces reals del lector abans de tocar cap ruta, perquè la taula només és útil quan és concreta. Una cadena que funciona satisfà les quatre files alhora, i una cadena mig funcional normalment en satisfà una amb el transportista equivocat. Llegir la fila equivocada com a fallada és el que converteix un problema d'encaminament en una tarda sencera d'edicions.

Les adreces tenen papers, no un recompte

Linux permet diverses adreces en una interfície i diversos túnels en un amfitrió, així que un recompte no diu res sobre la correcció. L'important és quina adreça pertany a quina connexió i si la ruta per a un parell determinat selecciona la connexió que volíeu. Tres vistes responen això des de tres direccions, i val la pena llegir-les en el mateix ordre cada vegada.

L'inventari d'adreces mostra què existeix i quina connexió en és propietària. La taula de rutes respon la pregunta del transportista per al trànsit ordinari cap a destinacions. La vista de polítiques la respon de nou per al trànsit seleccionat per origen o marca, que és la disposició normal quan dos clients comparteixen un amfitrió.

ip -4 addr show
ip -4 route show table all
ip rule show

Esborrar una adreça perquè la llista sembla llarga pot eliminar part del camí, i esborrar una ruta perquè sembla redundant fa el mateix més silenciosament. Cap de les dues no produeix cap error; el parell simplement deixa de respondre pel camí que volíeu mentre continua sent abastable per un altre. Una aplicació que informa de l'adreça de sortida del parell interior no demostra que el trànsit hagi travessat el túnel exterior, perquè l'accés directe produeix la mateixa observació. Aquesta escletxa entre una observació i una prova és per què el transportista es comprova a la capa d'encaminament.

L'ordre d'activació supera una espera fixa

Si el client interior depèn d'una adreça o una ruta que proporciona el client exterior, l'activació ha d'esperar aquest recurs en lloc d'una demora. Una espera funciona fins al dia que el túnel exterior va lent, i llavors falla de manera intermitent d'una manera que ningú no pot reproduir. L'ordenació basada en dependències elimina l'endevinació i no costa res més enllà de descriure la dependència una vegada. Els noms d'interfície tampoc no són un mecanisme d'ordenació.

El nucli assigna noms com tun0 i tun1 per ordre de creació, i aquest ordre pot canviar entre reinicis o reconnexions. Vincula la configuració a una identitat que proporcioni l'eina, o a un nom que assignis deliberadament. Un nom que tries és un contracte; un nom que tria el nucli és un accident.

Mantén el transport de cada client fora de la ruta d'aplicació de l'altre, i sigues precís sobre què prometen realment les opcions d'encaminament de OpenVPN 2.6. El mecanisme documentat de redirecció per defecte manté un client capaç d'arribar al seu propi parell remot a través de la passarel·la que ja existia, cosa que talla un bucle de recursió concret. No converteix un client en el transportista d'un altre, així que la resta de la cadena continua sent el teu disseny. On la cadena necessita una política en lloc d'una ruta, escriu una regla explícita d'origen o marca i prova-la amb el trànsit amb què ha de coincidir.

Què passa quan mor el salt exterior

Abans que la cadena compti com a completa, decideix què passa quan desapareix el salt exterior. El transport del client interior mor amb ell, i el següent moviment és una qüestió de política més que tècnica: fallar, reintentar o reconnectar directament per l'enllaç físic. Aquest tercer resultat és el que cal pensar. Converteix silenciosament un disseny de dos salts en un disseny d'un salt en el moment que l'usuari creu que la cobertura encara és intacta.

Si dos salts són obligatoris, el client interior no ha de poder establir un camí directe quan l'exterior ha desaparegut, i la manera de saber-ho és trencar el salt exterior i observar què fa l'interior. Un pla de reserva aprovat és una resposta legítima, però s'ha d'escriure, provar i comunicar. Un pla de reserva que ningú no ha documentat és indistingible d'una fuita durant la revisió d'un incident.

El DNS i l'altra família d'adreces pertanyen a la mateixa decisió. Una consulta generada localment segueix la política pròpia de l'amfitrió i no la d'un client reenviada, així que el resolutor que funciona per al trànsit reenviat pot no ser el que l'amfitrió mateix fa servir.

Accepta cada capa en l'ordre en què la vas construir

Prova en l'ordre en què es va construir la cadena: el túnel exterior sol, després el transport del client interior a través del túnel exterior, després l'aplicació a través del túnel interior. Cada acceptació ha de ser una connexió nova i no una pàgina que ja era oberta. Després trenca i restaura cada capa per separat i observa què fa la següent.

El resultat del pla de reserva és l'observació més valuosa aquí, i la que una pàgina d'IP pública mai no mostra. Desa els camins dels parells, les adreces que fan servir i aquest resultat al costat de la configuració, perquè el camí feliç no és la part que es qüestiona després.