VPN connectat però un servei falla: aïlla l’etapa

«Connectat» és el fet menys informatiu d’un tiquet de VPN. Registra que dos parells han acabat un handshake i res sobre el nom que es va consultar, la interfície per la qual va sortir el paquet, la seva mida o si l’extrem llunyà l’ha acceptat. Per això un servei pot fallar mentre la resta d’aplicacions del mateix portàtil funcionen. Recorre les etapes en ordre i la primera que falli anomenarà la falla.

Comença pel nom, no pel túnel

Resol abans d’encaminar, perquè una resposta dolenta fa que tota prova posterior no tingui sentit. Consulta el nom amb el resolutor del sistema i compara aquesta resposta amb l’adreça que l’aplicació ha fet servir realment. Un nom privat que torna com a adreça pública vol dir que la consulta ha anat a un resolutor que no hi té res a veure. Un nom que no resol és la mateixa categoria, només més sorollosa.

resolvectl query host.internal
getent hosts host.internal

Els navegadors amb la seva pròpia configuració de DNS segur fallen aquí mentre la resta del sistema funciona. Per això una queixa només del navegador pertany primer a aquesta etapa, abans que ningú toqui una ruta. Compara les dues ordres i no una, perquè getent segueix el camí NSS i la consulta al resolutor no.

Pregunta al nucli quin camí ha triat

La taula d’encaminament és un ordre de preferència, i el camí que tria el nucli no sempre és el que mostra el diagrama. Pregunta-li directament per la destinació en qüestió. La resposta anomena la interfície, el salt següent i l’adreça d’origen que s’utilitzarà. Un paquet pot sortir pel túnel amb una adreça d’origen que l’extrem llunyà rebutja, i una entrada més específica a la taula física pot fer-lo sortir per la interfície Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Llegeix els camps dev, via i src en aquest ordre, perquè cadascun elimina un sospita diferent. Aquesta etapa també és responsable de l’estat que ha instal·lat el client, ja que les regles de firewall i les rutes poden persistir després d’una sortida anormal. Per això «sense internet sense el túnel» i «sense internet si el client no s’executa» són una mateixa família de falles, no dues.

Prova la mida del paquet

Una resposta petita que torna mentre una transferència gran s’encalla assenyala primer l’MTU del camí. Una sonda amb el bit do-not-fragment activat, enviada des de dins del túnel, separa aquesta etapa de la resta. Apuja la càrrega fins que la sonda falli i tindràs el número que importa.

ping -M do -s 1400 10.20.30.40

Sondes petites que passen mentre un llistat de directori o una pujada es penja és la signatura d’aquesta etapa. La queixa sona a credencials o a regla de firewall, i no és ni una cosa ni l’altra.

El número és una propietat del camí, no del client, així que un valor que funciona en una connexió d’oficina pot fallar en un enllaç mòbil. Guarda l’ordre de la sonda amb el tiquet, perquè la propera persona necessita la mateixa mesura. Si una càrrega més petita passa, la solució és un clamp o un MTU de túnel més baix, no un xifratge nou.

Prova l’extrem llunyà

Prova la destinació per la seva adreça i mira després què hi escolta. Una connexió rebutjada i una connexió que mai respon són troballes diferents. La primera diu que alguna cosa està engegada i no serveix aquell port, i la segona diu que no ha tornat res. Cap de les dues és un problema del client per defecte.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Res accessible per un túnel no pot ser un servei que només escolta a 127.0.0.1, perquè l’oient mai veu el paquet. Quan el firewall de l’amfitrió llunyà permet la subxarxa d’oficina i rebutja el pool del túnel, el resultat sembla una falla del client i no ho és. L’escriptori remot o el compartir fitxers es trenquen mentre el trànsit web sobreviu, normalment acaba aquí, digui com digui l’usuari.

Mapeja la queixa a una etapa

La majoria d’informes es redueixen a una de cinc formes, i cada forma anomena una etapa. Un lloc que només funciona pel túnel és una resposta de nom o una política lligada a l’adreça d’origen. Les actualitzacions fallen sense el túnel mentre la navegació funciona: és un problema de nom o de ruta per a aquell client.

Tot s’atura quan arrenca un client de proveïdor és estat instal·lat, és a dir, una qüestió de ruta i firewall. Un servei inabastable mentre la resta va bé és l’extrem llunyà. Les transferències que s’encallen al cap de pocs segons són la mida del paquet. Emparella la forma abans d’executar ordres, perquè decideix quines proves recollir primer.

Anota l’etapa que ha produït la primera fallada juntament amb la sortida de l’ordre. Un tiquet que diu que l’adreça d’origen era incorrecta, amb la línia de ruta adjunta, val la pena d’atendre, mentre que un que informa que la VPN està trencada no.