El handshake de PiVPN funciona, les pàgines s’encallen: reviseu la MASQUERADE

El telèfon mostra el túnel com a connectat, el client informa d’una adreça privada i la primera pàgina encara es queda a mig carregar. Aquesta combinació envia la majoria de la gent cap als paràmetres de xifratge i la temperatura del processador, on en realitat no hi ha res trencat. El túnel s’ha aixecat, o sigui que la negociació ha acabat; el que ha fallat és el pas següent, quan el servidor intenta lliurar els paquets del client a internet. Seguiu el mateix camí que fan aquests paquets i la desavinença sol ser visible en una línia de la taula NAT.

Comenceu per allò que el client pot i no pot assolir

Des del client connectat, carregueu una pàgina que visqui a internet públic i fixeu-vos si falla a l’instant o s’encalla a mig camí. Després obriu un recurs a l’adreça privada del mateix servidor VPN i compareu els dos resultats.

Una adreça de túnel que respon a ping mentre els llocs públics esgoten el temps és el senyal d’un problema de reenviament o de traducció, no d’una encaixada de mans trencada. El panell d’estat del propi client no els pot distingir, perquè només sap que el canal de control està aixecat. Comproveu al servidor la interfície del túnel amb ip -br addr show tun0 i confirmeu que l’adreça assignada al client cau dins del pool que heu configurat. Si el pool i l’adreça del client no coincideixen, arregleu-ho primer, perquè cada regla de més avall coincideix amb el pool.

A continuació, pregunteu al servidor quina interfície faria servir per arribar a una adreça pública. ip route get 203.0.113.9 imprimeix el dispositiu i la font triats a la primera línia. Apunteu el nom d’aquest dispositiu, perquè és el valor que ha de contenir la regla NAT.

Llegiu la regla que decideix si els paquets surten

MASQUERADE reescriu un paquet només quan el paquet surt per la interfície indicada a la regla. Una regla limitada a un dispositiu amb cable no fa res per al trànsit que surt per Wi-Fi, i el paquet manté la seva adreça d’origen privada fins al router superior. Aquest router no té cap ruta de tornada cap al vostre pool del túnel, així que descarta la resposta, i el client veu una connexió que s’obre i després mor. El símptoma creix amb la quantitat de pàgina que arriba abans que calgui la primera resposta.

Llisteu la taula viva i llegiu la columna d’interfície de sortida en lloc de buscar només la paraula MASQUERADE. La sortida en forma d’afegir és més fàcil de comparar que un llistat formatat:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

En una Raspberry Pi que abans feia servir Ethernet i ara fa servir Wi-Fi, el nom obsolet és gairebé sempre la història sencera. L’instal·lador va registrar quin dispositiu hi havia en el moment de la configuració, i el conjunt de regles desat el reprodueix a cada arrencada. Compareu el dispositiu de la consulta de ruta amb el de la regla abans de canviar res més. Si coincideixen, la interfície no és el vostre problema i hauríeu de passar als comptadors de l’última secció. Si difereixen, la solució és una edició d’una paraula al fitxer de persistència.

Corregiu el conjunt de regles desat, no només el que està en marxa

Editar només la taula viva aguanta fins al proper reinici, que és exactament el temps suficient per convèncer-vos que el problema està resolt. Les regles que tornen a l’arrencada viuen en un fitxer que recarrega un paquet de persistència del tallafoc. A les imatges de Pi basades en Debian aquest fitxer sol ser /etc/iptables/rules.v4.

Feu una còpia abans de tocar-lo, després substituïu la interfície de sortida de la línia MASQUERADE pel dispositiu que heu anotat, per exemple -o wlan0 en lloc de -o eth0. Deixeu el rang d’origen tal com és, tret que el vostre pool de clients hagi canviat. Recarregueu i confirmeu que la regla ja nomena el dispositiu correcte:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Dos paràmetres adjacents són fàcils d’oblidar. sysctl net.ipv4.ip_forward ha d’informar d’1, i el router superior no ha de filtrar pel seu compte les adreces d’origen privades.

Demostreu que la regla s’activa i després aïlleu què encara va lent

Els comptadors són l’única prova honesta que una regla ha coincidit. Executeu el llistat detallat, inicieu una baixada al client i torneu-lo a executar. Les columnes de paquets i bytes al costat de la vostra regla haurien de pujar, i una regla que es queda a zero encara no coincideix. Si els comptadors es mouen però les pàgines encara fallen, compareu el rang d’origen amb el pool real amb grep -n "^server " /etc/openvpn/server.conf. Si es mouen i les pàgines carreguen però el rendiment és pobre, la traducció està feta i el problema restant és en un altre lloc.

Compareu dues transferències del mateix client, una cap a un amfitrió de la xarxa local i una a través del túnel cap a aquest mateix amfitrió. Lent en tots dos casos apunta a l’enllaç ascendent de la Pi o a la connexió Wi-Fi, no al VPN. Lent només a través del túnel apunta a l’MTU i a les retransmissions, que podeu inspeccionar amb ip -s link show tun0 abans de canviar cap paràmetre de criptografia.

Per desfer l’experiment, restaureu la còpia i torneu-la a carregar, després confirmeu que la regla original i els seus comptadors han tornat. Escriviu el dispositiu de sortida i l’ordre de recàrrega a les notes del servidor, perquè el proper canvi d’enllaç ascendent retrobarà la mateixa desavinença. Una regla que nomena el dispositiu equivocat queda invisible fins que el trànsit la necessita.