Els clients OpenVPN amb pont no tenen internet? Comproveu la regla NAT
Els clients OpenVPN amb pont surten pel dispositiu tap, de manera que una regla masquerade que anomena la targeta física mai no coincideix i el comptador es queda a zero.
El servidor amb pont està actiu, la regla masquerade hi és, i el navegador del client continua girant. Tot sembla que hauria de funcionar, i per això la primera hora se’n va a comprovar el túnel i les credencials. Aleshores llegiu el comptador de la regla NAT i trobeu un zero que no s’ha mogut. Una regla que mai no ha comptat cap paquet mai no ha coincidit amb cap, i en un servidor amb pont la raó és estructural: el trànsit del client surt pel dispositiu virtual tap, mentre que la regla anomena la targeta física que vau copiar d’una guia més antiga.
El comptador és la prova, no la línia de la taula
Les regles que existeixen i les regles que coincideixen són coses diferents, i el comptador és el que les separa. Llisteu la taula NAT amb comptadors detallats i llegiu els números al costat de cada regla abans de canviar res. Un comptador aturat a zero mentre el trànsit flueix vol dir que la regla s’ha saltat, per raonables que semblin les seves adreces. Un comptador que puja mentre la connexió encara falla us envia a un altre lloc: l’encaminament, el camí de tornada o l’extrem remot.
iptables -t nat -L POSTROUTING -v -nPrimer llegiu el comptador al costat de la coincidència d’interfície. Si el rang d’origen és correcte i el costat de sortida és incorrecte, la correcció és una paraula dins de la regla, no una regla completament nova.
Trobeu el nom que el nucli realment registra
Identifiqueu el dispositiu del túnel pel nom abans d’escriure la regla, fent servir la llista d’interfícies i no la memòria. En una instal·lació OpenVPN amb pont, el dispositiu sol ser una interfície tap creada pel servidor, i el seu nom forma part de la vostra configuració local, no és una constant universal. Confirmeu que existeix mentre el túnel és actiu, perquè un dispositiu que només apareix després que un client es connecti farà que una prova anterior sembli un problema de regla.
ip -brief linkAnoteu el nom. Totes les ordres posteriors d’aquest diagnòstic hi fan referència, i una errata aquí produeix exactament el mateix comptador a zero que l’error original.
Reescriviu la regla contra el dispositiu del túnel
Apunteu la regla al dispositiu del túnel i manteniu el rang de clients com a condició de coincidència, de manera que cobreixi el trànsit del túnel i deixi les connexions pròpies de l’amfitrió tranquil·les. Substituïu el vostre rang i el nom del dispositiu, perquè tots dos exemples de sota són exemples i cap no és portable entre instal·lacions.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADEDesprés comproveu les dues altres condicions que el mateix símptoma amaga. Comproveu si l’encaminament està habilitat i, si no ho està, habiliteu-lo a la configuració pròpia de la distribució en lloc de fer-ho amb un echo que desapareix en reiniciar. Llegiu també els comptadors de la cadena forward i, si descarta el trànsit del túnel, permeteu específicament aquella interfície i deixeu la política de la cadena tal com està.
Llegir la cadena forward amb comptadors només costa una ordre i descarta la meitat de les possibilitats restants abans de tocar una altra regla.
Per què la targeta física no coincideix mai
Un pont és un commutador de programari format pel dispositiu tap i una interfície física. La trama del client entra en aquest commutador i surt cap a la xarxa física com a membre del pont, no com a paquet a la targeta. Per això el nucli atribueix el paquet al pont i al seu port, i per això la targeta que teníeu al cap no apareix mai a la coincidència. La interfície física no té res espatllat; simplement no és el dispositiu que el nucli atribueix a aquest paquet.
El problema següent que la gent troba ve de la mateixa estructura: el filtratge de trames en un pont és un mecanisme separat del filtratge IP. Si el requisit és una restricció a nivell de trama, pertany al filtratge del pont, no a una regla de la taula IP.
Demostreu-ho d’un extrem a l’altre i després feu-ho permanent
Aixequem un sol client i feu ping a alguna cosa de la LAN del servidor; aquest camí exercita l’encaminament sense cap traducció. Després demaneu alguna cosa pública perquè la regla masquerade s’hagi d’utilitzar i llegiu el comptador una altra vegada: hauria de moure’s per a aquesta prova i no per a l’anterior. Una captura feta al dispositiu del túnel mostra alhora on apareix la trama i quina adreça porta.
Últim pas: poseu les regles que funcionen a la configuració que llegeix un reinici i anoteu el nom del dispositiu que el pont d’aquest amfitrió fa servir realment. Qualsevol cosa escrita a mà desapareix després d’un reinici, i la mateixa fallada torna sense res que l’expliqui.
Si el comptador encara no es mou després de reescriure la regla, compareu el rang d’origen de la regla amb l’adreça que el client ha rebut realment, perquè un servidor amb pont pot repartir adreces d’un rang que no preteníeu.