Connectat a OpenVPN però no es carrega res: un recorregut des del client

La finestra del client diu Connectat, l'adreça del túnel hi és, i el navegador encara gira. Aquesta combinació és normal, perquè un handshake correcte només demostra que el túnel s'ha construït; no diu res sobre si el servidor reenviarà els vostres paquets, reescriurà la seva origen o respondrà les vostres consultes DNS. L'error que comet més gent és obrir primer la configuració del servidor. En lloc d'això, aneu del client cap enfora, perquè cada pas de sota us diu si el següent val la pena de comprovar.

Comenceu pel client i aneu cap enfora

Feu tres proves en aquest ordre i anoteu on falla la primera. Feu ping a l'adreça del túnel del servidor, cosa que demostra que el túnel mateix transporta trànsit. Feu ping a una adreça pública per número, cosa que demostra el reenviament i la traducció sense implicar la resolució de noms. Després proveu de resoldre un nom d'amfitrió, que és l'única prova que posa en marxa el DNS. Cada resultat elimina una capa sencera de sospita.

No salteu a la tercera prova perquè el navegador sembla més ràpid. Una càrrega de pàgina fallida cobreix les tres capes alhora, i començar per aquí és com la gent acaba reconstruint un túnel que funcionava. Una pàgina que falla no us diu quina de les tres s'ha trencat.

Dues captures mostren on s'aturen els paquets

Amb un ping a una adreça pública en marxa des del client, feu una captura a la interfície del túnel i una altra a l'enllaç ascendent que hauria d'arribar a internet. Executeu-les alhora perquè les marques de temps coincideixin.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Si les peticions apareixen al túnel i mai a l'enllaç ascendent, el servidor les ha descartat entre el túnel i el cable, i la causa és el reenviament o la política de tallafocs de reenviament, no el NAT. Si apareixen en tots dos, el servidor ha fet la seva part i la resposta falta més enllà, cosa que apunta a la traducció, a un filtre anterior o a una restricció del proveïdor.

Obteniu el nom de l'enllaç ascendent de la taula d'encaminament, no d'un tutorial. Les imatges de núvol i els adaptadors reanomenats poques vegades coincideixen amb la interfície d'exemple d'una guia, i una captura feta al dispositiu equivocat sembla exactament un servidor que no reenvia:

ip -4 route get 9.9.9.9

El camp dev d'aquella sortida és el nom que la regla NAT necessitarà més endavant, així que guardeu-lo.

El reenviament és un commutador del nucli i una política de tallafocs

El nucli ha d'acceptar de reenviar, com a mínim. Llegiu el valor actual i després feu el paràmetre permanent en lloc d'escriure'l només al nucli en execució:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

El reenviament només és la meitat. En un amfitrió amb UFW, la política de reenviament s'estableix a /etc/default/ufw i ha de ser ACCEPT abans que una recàrrega tingui efecte. Un descart per defecte al camí de reenviament deixa el handshake perfectament sa mentre descarta en silenci cada paquet que intenta sortir pel túnel, que és exactament el símptoma amb què vau començar.

Els amfitrions que gestionen nftables directament tenen la mateixa pregunta amb una sintaxi diferent. Mireu els comptadors de la cadena de reenviament mentre s'executa una prova des del client, perquè una cadena que es consulta i una cadena que descarta en un fitxer de configuració semblen idèntiques.

Anomeneu la interfície de sortida real a la regla NAT

La traducció d'origen pertoca a la interfície que realment surt de l'amfitrió, amb el pool que reparteix el servidor. Les dues meitats d'aquesta regla han de descriure la realitat, i cap de les dues és opcional.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

La fallada clàssica és una regla copiada d'una guia que diu -o eth0 en una màquina l'adaptador de la qual es diu d'una altra manera. La regla s'instal·la sense cap avís, no coincideix amb res, i el client continua sense internet. El pool és l'altra meitat del mateix error: si el servidor reparteix 10.44.0.0/24 i la regla cobreix 10.8.0.0/24, res no hi coincidirà mai.

Mireu els comptadors en lloc de confiar en el text de la regla. El llistat informa de paquets per regla, i una regla que no coincideix mai es queda a zero per correcta que sembli. Doneu-li un minut de trànsit real del client abans de llegir res en aquest número:

iptables -t nat -L POSTROUTING -v -n

Un recompte de paquets zero després d'una prova real del client vol dir que la coincidència és incorrecta, no que el túnel estigui trencat. Quan coincideixi, deseu el conjunt de regles perquè sobrevisqui a un reinici; una solució que només viu a l'historial de l'intèrpret desapareix al primer reinici.

Si el servidor també és una instància NAT al núvol, la plataforma també hi té veu. Una instància que tradueix adreces normalment necessita la comprovació d'origen i destinació desactivada allà on el proveïdor ofereix aquest paràmetre, i el port VPN mateix ha de ser abastable des de fora.

El DNS és la segona fallada darrere de la primera

Fer ping per adreça quan els noms fallen és un problema del resolutor, i té la seva pròpia causa. Un client que es queda el resolutor local envia aquestes consultes dins un túnel complet i espera una resposta que no arriba mai, perquè el resolutor local ara és al costat equivocat de la ruta.

Envieu un resolutor des del servidor perquè el client sàpiga on preguntar. Dues entrades donen al client una alternativa si la primera no és abastable, i totes dues haurien de ser resolutors que el túnel permeti de debò.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Els clients de Windows poden tornar igualment al resolutor local, que és el que block-outside-dns existeix per evitar, a canvi de perdre noms que només la xarxa local pot resoldre. Els clients de Linux amb systemd-resolved sovint ignoren un resolutor enviat tret que un script l'instal·li, així que comproveu resolvectl status per al dispositiu del túnel abans de concloure que l'enviament s'ha ignorat.

Acabeu el recorregut tal com l'experimenta un usuari. Carregueu una pàgina real des del client, confirmeu l'adreça des de la qual surt, reinicieu el servidor, torneu a connectar i repetiu les tres proves. Aquesta segona passada és l'única que demostra que les regles desades, la política de tallafocs i el resolutor enviat han sobreviscut tots junts.