El túnel VPN no es connecta mai: on s'aturen realment els paquets
Un túnel que no es forma mai deixa un registre buit als dos extrems. Comproveu si es descarten GRE, ESP o UDP 4500 i detecteu el NAT de l'operador abans d'editar el servidor.
El client no para de reintentar, el registre s'atura abans que es completi l'apretada de mans i el servidor no enregistra absolutament res. Aquest patró allunya de les credencials i apunta al camí: alguna cosa entre els dos extrems es nega a transportar el protocol que el túnel necessita. Decidiu on s'aturen els paquets abans de tocar qualsevol de les dues configuracions, perquè un protocol filtrat i una contrasenya errònia produeixen el mateix error amable en la majoria de clients. Les proves estan ordenades per cost, la més barata primer.
Demostreu on s'atura el trànsit
Captureu a la interfície de sortida del client i al servidor al mateix moment. Compareu què ha sortit amb què ha arribat i anoteu en quina direcció apareix la diferència.
Res al servidor vol dir que el camí o el primer NAT descarten el trànsit, mentre que les arribades sense respostes apunten a un tallafocs al servidor o a una ruta de tornada que no existeix. Un encaminador que acaba túnels sovint no guarda cap registre útil, així que la captura es converteix en el registre. Anoteu el port de destinació i el número de protocol, ja que les dues fallades es veuen igual en un diàleg del client.
PPTP mor sense el protocol 47
PPTP porta el control per TCP 1723 i les dades dins de GRE, que és el protocol IP 47 i no un número de port. Reenviar només el 1723 produeix el resultat clàssic: la connexió s'autentica i després queda en silenci, perquè no hi ha cap regla per al protocol que porta la càrrega útil. El client no pot distingir això d'una contrasenya rebutjada, i per això la captura ha d'arribar abans de les modificacions de la configuració.
El pas directe funciona en la direcció oposada a un reenviament d'entrada, i el firmware fa servir prou sovint una sola etiqueta per a tots dos com per confondre tothom. En un client Linux el tallafocs local pot descartar GRE molt abans que l'encaminador hi intervingui, així que el protocol 47 necessita la seva pròpia regla i cal carregar l'ajudant conntrack. L'ufw d'Ubuntu guarda aquestes regles al fitxer before, perquè les regles d'allow normals no poden expressar un número de protocol. Després recarregueu el tallafocs en lloc de reiniciar la màquina.
# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep greL2TP i IPsec darrere de dos NAT
L2TP dins d'IPsec necessita UDP 500 per a l'intercanvi de claus, UDP 4500 quan es detecta NAT i ESP com a protocol 50. Cada un es filtra de manera independent, així que una regla que en permet un no demostra res sobre els altres dos. Dos encaminadors en sèrie tradueixen cada paquet dues vegades i els extrems ja no coincideixen en què s'ha negociat.
Ponteu el mòdem exterior o desactiveu el NAT de l'encaminador interior, perquè l'adreça pública arribi al dispositiu que acaba el túnel. On no sigui possible cap de les dues, el túnel s'ha d'iniciar des de dins del límit del doble NAT, no acabar-s'hi.
Xarxes d'operador i compartició d'adreces
Una adreça WAN dins de 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 o 100.64.0.0/10 vol dir que l'encaminador no té cap adreça pública i que cap reenviament d'entrada des d'internet no el pot assolir. El NAT de nivell d'operador, a més, filtra els protocols que no espera, i GRE és una víctima freqüent en enllaços mòbils. Compareu l'adreça WAN del mateix encaminador, no l'adreça que un lloc de consulta indica per a un client que hi ha darrere.
Fer funcionar el mateix encaminador en una línia per cable separa una troballa d'operador d'un error de configuració en una sola prova. On l'operador refusa el protocol, les opcions que queden són un altre transport al 443 o un túnel iniciat des de dins.
Llegiu la llista d'escoltes abans de tancar ports
Un escaneig de ports alarmant sovint és només el conjunt de funcions que arriba activat. Inventarieu les escoltes, aparellau cada socket amb una funció i després desactiveu la funció en lloc de bloquejar el port, perquè les dues visions no es desviïn.
ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500Els valors per defecte de SoftEther són un bon exemple: TCP 443, 992 i 5555, amb les funcions L2TP/IPsec i de túnel DNS que afegeixen els seus propis sockets. Desactivar aquestes funcions elimina les escoltes en lloc d'amagar-les, i la prova des d'un amfitrió extern us diu si l'operador deixa passar el port. Una escolta que respon localment encara pot estar tancada més amunt, així que compareu l'adreça WAN del mateix encaminador amb el que informa un servei extern.