VPN niada: quin túnel transporta la connexió exterior?

Dos clients VPN en marxa alhora no produeixen un túnel niuat; produeixen dos túnels i una discussió sobre l’encaminament. Un túnel niuat existeix quan la connexió del client interior amb el seu propi servidor és ella mateixa portada pel túnel exterior, i això és un muntatge que es construeix a propòsit. Si surt bé, el servidor interior veu l’adreça del servidor exterior; si surt malament, un client es reconnecta en silenci al voltant de l’altre. Tres condicions decideixen si l’anidament és real o accidental.

Tres condicions decideixen l’anidament

La primera és quin extrem necessita quin camí. Anomena l’adreça del servidor interior, anomena la del servidor exterior i afirma explícitament que al servidor interior només s’hi arriba pel túnel exterior. Tota la resta se segueix d’aquesta frase, incloent-hi quines rutes van en quina taula.

La segona és si pots veure el camí a cada capa. Si no pots preguntar al nucli quina ruta faria servir una destinació concreta, estàs deduint la cadena a partir d’una IP de sortida final, i aquesta és justament la prova que no pot distingir un anidament d’una casualitat.

La tercera és què passa quan cau el túnel exterior. El túnel interior es pot aturar amb ell, reconnectar-se per la xarxa ordinària o quedar bloquejat fins que torni el camí exterior, i les tres són polítiques defensables. No són la mateixa política, i el comportament per defecte de la majoria de clients és el segon. Un client que reconnecta el seu extrem per la xarxa física mentre mostra una connexió sana és la manera més comuna que una cadena volguda esdevingui en silenci dos túnels sense relació.

Condició u: quin extrem necessita quin camí

ip route get 203.0.113.10 respon aquesta pregunta directament: imprimeix la ruta, l’adreça d’origen i la interfície que el nucli faria servir per a aquesta destinació ara mateix.

Executa-ho per al servidor interior abans que arrenqui el client interior i una altra vegada després, i compara. Si la resposta canvia de la interfície física a la interfície del túnel exterior, l’anidament és real en aquell moment. Si no canvia, el client interior es connecta directament, digui el que digui el tauler. Repeteix-ho per a l’adreça del servidor exterior, que encara s’ha de resoldre per la interfície física, perquè una ruta que captura els dos extrems de manera recursiva és la fallada que deixa la màquina fora de la xarxa del tot.

Condició dos: inspecciona el camí a cada capa

La selecció de ruta és més que la taula principal en un client modern. Les regles de política poden enviar paquets marcats a una altra taula, un client pot lligar la seva socket a una interfície, i un contenidor o un espai de noms té taules pròpies. ip rule i ip route show table all són la manera d’esbrinar quin d’aquests mecanismes està en joc.

Un client que posa SO_MARK a la seva pròpia socket, o que està configurat per lligar-se a un dispositiu concret, evita la ruta per defecte que et pensaves que havies disposat. Això és una funció i no un error, i vol dir que l’única comprovació fiable és la que s’executa al mateix espai de noms que el client. Si els clients corren en contenidors, executa les comprovacions dins d’aquests contenidors en lloc de a l’amfitrió.

Condició tres: què passa quan cau el túnel exterior

El comportament davant de fallades demana una decisió, no un valor per defecte. Escriu què ha de passar al túnel interior quan desaparegui l’exterior, i després fes que els clients ho compleixin.

Les opcions són concretes. Aturar el client interior quan desapareix el camí exterior dona una cadena neta i una interrupció òbvia. Deixar-lo reconnectar directament dona disponibilitat i treu en silenci la propietat per a la qual es va construir la cadena. Blocar fins que torni el camí exterior és la més estricta i la més feixuga d’operar, perquè cada oscil·lació del túnel exterior es converteix en un incident visible.

Prova les tres amb trànsit innociu i una fallada provocada del túnel exterior, perquè llegir la configuració no et dirà quina tens. Talla el túnel exterior, observa què fa el client interior i torna a comprovar la ruta mentre està caigut. Després torna a aixecar el túnel exterior i confirma que la cadena es torna a formar en lloc de deixar el client interior al camí directe que va triar mentrestant.

Què no et dona la cadena

Les capes extra afegeixen extrems, claus i maneres de fallar; no afegeixen cap garantia d’anonimat i no fan que l’operador exterior no pugui veure que hi ha un túnel. Qualsevol afirmació sobre què protegeix l’anidament ha de nomenar l’observador contra el qual protegeix.

El lliurable és un document breu i no una connexió que funcioni: quin extrem fa servir quin camí, què passa en una fallada exterior i les tres ordres que mostren l’estat actual. La documentació de strongSwan sobre reenviament és una referència útil per a com es reenvia el trànsit de túnel entre interfícies en un amfitrió Linux. Torna a executar les comprovacions després de cada actualització de client, perquè els valors per defecte que van produir la teva cadena no són un contracte. Un túnel niuat que no pots inspeccionar és un rumor amb un llum d’estat.