Per què una ruta de túnel complet talla el servidor que la transporta

Activa un túnel complet i cada destinació passa a pertànyer a la interfície VPN, inclosa la màquina que el termina. Els paquets exteriors que porten el túnel s’adrecen a aquesta màquina, així que la ruta acaba consumint el transport del qual depèn. Una ruta específica addicional ho resol, i val la pena entendre el perquè. Sense aquest motiu, la propera reconstrucció reintrodueix la fallada.

Una ruta que es menja el seu propi transport

L’encapsulament embolcalla cada paquet en una segona capçalera. La exterior s’adreça des de l’adreça física local fins a l’adreça pública del servidor, i ha de creuar l’enllaç físic abans que pugui existir cap túnel.

Ara deixa que la consulta d’aquella adreça pública triï el túnel. Per enviar el paquet, la màquina l’ha d’encapsular, cosa que requereix una ruta cap a la mateixa adreça, que retorna el túnel. Els clients ho gestionen d’una de dues maneres. Un de curós es nega a instal·lar la ruta per defecte i informa d’un error, mentre que un de menys curós informa d’èxit i després no mou res. La fallada silenciosa és la que costa una tarda.

La coincidència de prefix més llarg decideix la consulta abans que es consulti cap mètrica, així que una ruta d’una sola adreça supera qualsevol ruta per defecte de la màquina. Aquest és tot el mecanisme darrere de la reparació.

Instal·la l’excepció abans de la ruta per defecte

Crea una ruta d’una sola adreça per al servidor, amb la passarel·la física com a següent salt, abans que es mogui la ruta per defecte. L’ordre importa: instal·lar-la després significa conviure amb un túnel trencat mentre escrius.

La majoria de clients ho fan sense que calgui demanar-ho. OpenVPN cerca l’adreça remota i la fixa abans de reescriure la passarel·la per defecte, i la seva opció route-delay existeix per a plataformes on aquesta seqüència es disputa. wg-quick pren un camí completament diferent, marcant paquets i consultant una regla de política en lloc d’afegir una excepció. Mecanismes diferents, mateix requisit: el paquet exterior ha d’escapar del túnel que crea.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

La sortida de la consulta és la prova d’acceptació. Ha de nomenar el dispositiu físic i el següent salt físic. Un dispositiu de túnel en aquesta resposta significa que falta l’excepció, o que es va col·locar després d’alguna cosa que la supera.

La imatge especular al servidor

La mateixa trampa espera a l’altre costat, invertida. Dona al servidor una ruta per defecte per un altre túnel, o envia-li una ruta que cobreixi les adreces públiques dels clients, i les seves respostes agafaran l’hàbit d’anar en direcció equivocada.

Imagina un client que es connecta i envia una petició. La resposta s’adreça a l’adreça pública d’aquest client, que ara coincideix amb una ruta de túnel, així que surt per una interfície diferent portant una font que el client mai no va marcar. El client pot rebre aquest paquet i tot i així descartar-lo, perquè res no el lliga a la petició que va enviar. Parteix de la decisió d’encaminament del servidor i no del temps d’espera del client, ja que només una de les dues mostra l’elecció real.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Hi ha tres reparacions i no són iguals. Fixar el servei a l’adreça física, o traduir la font, totes dues amaguen la decisió d’encaminament en lloc de corregir-la. Enviar el trànsit de resposta del pool de túnel per una taula dedicada corregeix la causa, i les altres dues són acceptables només mentre el disseny d’encaminament estigui congelat.

Excepcions que el túnel no para de robar

Un grapat de feines necessiten la internet oberta fins i tot mentre el túnel posseeix la ruta per defecte, i cadascuna necessita la seva pròpia excepció. L’actualitzador de DNS dinàmic sol ser el primer a trencar-se.

Resol el proveïdor, obre una connexió i troba els seus propis paquets viatjant per un túnel l’adreça del qual va canviar fa segons, així que l’actualització falla o publica l’adreça equivocada. Tres sortides: fixa el proveïdor amb una ruta d’amfitrió per la passarel·la física, executa l’actualització abans que pugi el túnel, o dona a l’actualitzador una taula de política que el túnel no toca mai. La sincronització de temps té la mateixa exposició en un dispositiu que arrenca sense resolutor, i els punts de validació de certificats pertanyen a la llista pel mateix motiu.

Una excepció que ningú no va escriure és una excepció que la propera reconstrucció deixarà caure en silenci.

Comprova-ho després d’una reconnexió, no abans

Prova tres destinacions, no una: el punt final, una adreça privada darrere del túnel i una adreça pública més enllà. Una sola consulta correcta no diu gairebé res sobre les altres dues.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Després reinicia la connexió, perquè un client que reconstrueix la seva taula en reconnectar-se descartarà una ruta que hagis escrit a mà. Amb un kill switch en joc, comprova que el punt final estigui permès, o el túnel no podrà tornar després d’un canvi de xarxa i el símptoma semblarà una caiguda. Guarda l’excepció al perfil o al fitxer d’unitat en lloc de l’historial del shell, perquè la reconnexió la torni a crear en lloc d’esborrar-la.