El VPN es connecta però no arriba als dispositius de la LAN: què cal comprovar

El trànsit entra al túnel, la passarel·la respon a la seva pròpia adreça i res del darrere no respon. Aquest patró és habitual i no és cap contradicció: una resposta de la passarel·la demostra que el túnel s’ha acabat, i no demostra res sobre què passa amb un paquet adreçat més enllà. Les dues proves exerceixen camins de codi diferents a la mateixa màquina.

A partir d’ara, prova alguna cosa a l’altra banda de la passarel·la. L’adreça pròpia de la passarel·la continuarà responent per molt trencat que estigui el reenviament.

La passarel·la respon des de la seva pròpia pila

Un paquet adreçat a la passarel·la es lliura al seu camí d’entrada local, on el nucli decideix si un sòcol que escolta l’accepta. Un paquet adreçat a un amfitrió darrere la passarel·la es lliura, en canvi, al camí de reenviament, on s’aplica un conjunt diferent de comprovacions. El reenviament es pot desactivar del tot, o el nucli pot activar-lo i després una regla de filtre que no esmenta mai el túnel el pot rebutjar. Res d’això no afecta la resposta pròpia de la passarel·la, i per això el símptoma enganya amb tanta fiabilitat.

Les pàgines d’administració a què s’arriba pel túnel també pertanyen a la primera categoria. Són evidència sobre el túnel, no sobre la xarxa del darrere.

Segueix el flux fins a la primera frontera que el deixa caure

Comença al client i confirma la ruta i l’adreça d’origen que farà servir el flux. Després observa la passarel·la per veure-hi arribar aquest flux exacte, i de nou el mateix flux sortint cap a la LAN. Si no hi arriba mai, el problema és al costat del client o als prefixos permesos del túnel. Si hi arriba i no en surt mai, el problema és el reenviament o un filtre de camí d’anada, i la captura ja ha dit quin dels dos.

Fer la mateixa prova des de la passarel·la amaga la meitat interessant, perquè un paquet originat a la passarel·la té una altra font i un altre requisit de retorn. Fes servir el flux del client, amb la seva pròpia adreça d’origen, a cada pas. Una captura feta a la interfície equivocada produeix bajanades amb molta seguretat.

Les rutes de retorn i els tallafocs dels amfitrions fallen per separat

Quan el paquet arriba a l’amfitrió, encara hi ha tres coses que s’han de complir. El servei ha d’estar escoltant a l’adreça a què es va enviar el paquet, el tallafoc de l’amfitrió l’ha d’acceptar, i la resposta ha de tenir una ruta de tornada cap al conjunt de clients. Aquesta darrera falla sovint, perquè la ruta per defecte de l’amfitrió apunta a un encaminador que mai no ha sentit a parlar del rang del túnel. El resultat és una connexió que s’estableix des del punt de vista de l’amfitrió i mor en silenci en l’altra direcció.

Prova el camí de tornada expressament enviant des del client i vigilant el retorn. Una captura unidireccional resol en segons el que una hora d’especulació no resoldrà.

Confirma cada salt amb l’adreça d’origen del client

Executa les comprovacions en ordre i conserva cada sortida, perquè el valor és a la comparació i no en cap línia concreta. Les ordres de sota fixen l’adreça d’origen, mostren la ruta triada i capturen els dos costats del reenviament. Substitueix l’amfitrió de la LAN i la interfície del túnel pels teus.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

La consulta de ruta mostra si el client enviaria fins i tot aquest paquet al túnel, i el ping mostra si ha tornat res de l’amfitrió. Comparar les dues captures separa l’arribada de la sortida, ja que una trama a la interfície del túnel sense contrapartida a la interfície de la LAN és una decisió de reenviament i no un error del servei. Quan totes dues captures mostren la petició i només una mostra la resposta, la ruta de retorn és el sospitós que queda.

Anota quina adreça ha respost i quina destinació reenviada ha fallat. Aquesta frase fa l’informe accionable en lloc d’una afirmació que el servidor no és abastable.