Obrir el port VPN no fa que els clients arribin a la LAN
Una regla d’entrada admet paquets adreçats a la mateixa passarel·la. El trànsit d’un client cap a un altre equip necessita encaminament i un camí de tornada, provats per separat.
El túnel s’aixeca, el client s’autentica i la LAN darrere la passarel·la continua invisible. La regla que havia de corregir-ho permet el port VPN i funciona exactament tal com està escrita, perquè aquesta regla governa els paquets adreçats a la mateixa passarel·la. El trànsit del client cap a un equip darrere la passarel·la té una altra destinació i una altra cadena. Un inici de sessió correcte no canvia quina de les dues consulta el nucli.
Dues cadenes, dues destinacions diferents
El destí d’un paquet el decideix on va, no com hi ha arribat. El trànsit adreçat a una adreça de la passarel·la es lliura localment i s’avalua amb les regles d’entrada. El trànsit que la passarel·la encamina més enllà s’avalua amb les regles d’encaminament. La mateixa interfície de túnel pot produir tots dos tipus de paquet, i per això una sola regla no pot cobrir les dues feines.
Tot el mite en una frase: permetre l’oient no diu res sobre permetre la xarxa que hi ha darrere. Són dues decisions separades amb proves separades, i un nom d’interfície a totes dues no les fusiona.
Què admet realment la regla de l’oient
Els paquets de l’oient acaben al procés VPN, i això és el que permet establir el túnel. La pàgina d’administració de la passarel·la i una resposta de diagnòstic local també fan servir el camí d’entrada propi de l’equip, i per això una prova cap a la passarel·la funciona mentre tot el que hi ha darrere falla. Tots dos resultats són correctes i cap no tracta de la LAN.
Quan el procés desencapsula el trànsit del client per a una altra destinació, el paquet entra al camí d’encaminament i allà necessita permís. L’autenticació correcta decideix qui és el client; no decideix on pot anar. Les dues preguntes tenen propietaris diferents, registres diferents i missatges d’error diferents.
Proveu des d’un client, mai des de la passarel·la
Una prova generada a la passarel·la segueix el camí de sortida propi de l’equip i pot passar mentre el camí encaminat és tancat. Comenceu la prova des del client i observeu els dos extrems del flux.
nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25Si la petició apareix a tun0 i no arriba res a la destinació, el paquet es descarta després d’arribar, cosa que apunta a les regles d’encaminament o al filtratge propi de la destinació. Si no apareix res a tun0, el client ni tan sols l’envia al túnel, i el problema és l’enrutament al client i no la política a la passarel·la. Compareu-ho amb una petició que surt correctament i no retorna res, que és el cas del camí de tornada.
L’encaminament necessita tres coses, no una
Cal activar l’encaminament del nucli, una regla de filtre ha d’acceptar el flux i la destinació ha de ser abastable amb un camí perquè torni la resposta. Si en falta una de les tres, el silenci és el mateix des del punt de vista del client.
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUTLlegiu les tres sortides juntes. Un zero a la primera fa irrellevants les altres dues, i una política de descart per defecte a la segona descarta els paquets del client mentre el trànsit propi de la passarel·la continua funcionant. La tercera sortida mostra per què la regla de l’oient no havia estat mai el problema.
Manteniu els dos conjunts de regles separats a la documentació
Escriviu la regla de l’oient i la regla del servei encaminat en línies separades, amb propietaris i motius separats. Quan canvia el port VPN o es publica un servei nou, aquesta separació evita que un canvi ampliï silenciosament l’altre.
En lloc de tractar cada parell autenticat com un membre de confiança de la LAN, feu servir regles estretes per als rangs de clients i els serveis que les necessiten. Les notes d’encaminament de StrongSwan descriuen la banda de ruta de tornada i de traducció de la mateixa frontera, que és una tercera decisió.
Finalment, manteniu les capes rectes quan es rebutja un usuari. Si la petició arriba a l’equip i l’aplicació rebutja el compte, repareu el permís de l’aplicació en aquesta capa; ampliar l’encaminament no pot proporcionar una credencial de compartició de fitxers i ampliarà l’accés per a tots els altres que es connectin correctament.