Per què PPTP i L2TP/IPsec s'aturen abans del nom d'usuari?
Sense sol·licitud de nom d'usuari, PPP no ha començat mai, de manera que la fallada és al transport, a l'intercanvi de claus o a la configuració del túnel. Comproveu l'ordre de les etapes abans de reinstal·lar.
Que no aparegui el nom d'usuari és un regal diagnòstic: PPP encara no ha començat, així que el compte, la contrasenya i la política de domini encara no s'han consultat. En una connexió PPTP o L2TP/IPsec, el client demana les credencials només després que el túnel existeixi i que el servidor hagi iniciat una sessió PPP. Tot el que pot fallar abans d'aquest moment és transport, intercanvi de claus o configuració del túnel, una superfície molt més petita que «la VPN està espatllada».
Una sol·licitud absent redueix la fallada a tres etapes
Anoteu l'última etapa que ha reeixit visiblement, perquè cadascuna té un propietari i una solució diferents. Endevinar la configuració del compte mentre esteu encallats dues etapes abans és com desapareix una tarda.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Un client que expira sense cap sol·licitud no va obtenir mai cap associació IPsec, així que la fallada és a IKE o en si els vostres paquets arriben al gateway. El que informa que està verificant credencials i després cau va arribar més enllà del que el missatge suggereix. Una sol·licitud seguida d'un rebuig és autenticació PPP, i això pertany a un article de compte, no a aquest.
Primera etapa: el protocol que un tallafoc descarta en silenci
PPTP necessita TCP 1723 per al canal de control i el protocol IP 47 per al camí de dades, i tots dos viatgen per separat. Moltes xarxes reenvien 1723 i descarten el protocol 47, cosa que produeix un túnel que negocia i després no transporta absolutament res. Un encaminador que fa NAT també necessita un pas GRE, i un camí d'accés només IPv6 no pot transportar PPTP sota cap configuració.
L2TP sobre IPsec gasta el port 500 en IKE i el port 4500 en la travessa de NAT, i després embolcalla el propi trànsit L2TP en 1701, mentre ESP transporta la càrrega protegida quan l'associació existeix. Permeteu els dos ports de control però no ESP i obtindreu exactament el símptoma del títol: progrés visible i després un client mort abans de qualsevol diàleg de credencials. Provar des d'un punt d'accés mòbil és una manera barata de separar un problema de client d'un problema de camí.
Segona etapa: una clau que no és la clau, una proposta que no s'ofereix
Una clau prèviament compartida que no coincideix falla de pressa i en silenci, i la versió habitual és una clau que sembla correcta a la pantalla mentre porta un salt de línia enganxat o un espai final. En un client Linux el diàleg no és necessàriament la font de veritat: el connector L2TP del NetworkManager guarda secrets en fitxers sota /etc/ipsec.d/, i un fitxer antic per connexió que /etc/ipsec.secrets encara inclou s'utilitzarà en lloc del que acabeu d'escriure. Copieu aquell fitxer a un lloc segur, traieu-lo del camí d'inclusió i després torneu a escriure la clau a mà.
L'altra meitat d'aquesta etapa és la proposta. Els dos extrems han de coincidir en el mateix conjunt d'algorismes de fase 1 — xifratge, integritat i grup Diffie-Hellman — i en transformacions ESP coincidents per a la fase 2, o l'associació no es forma en absolut. Un gateway que només ofereix 3DES, SHA1 i MODP1024 rebutjarà un client configurat per a algorismes més forts, i el seu registre anomena la transformació rebutjada. El registre anomena la discrepància si el llegiu en lloc de reiniciar el servei una altra vegada. En lloc de copiar una cadena d'algorismes d'un fil de fòrum, pregunteu al gateway quines transformacions negociarà realment: ike-scan apuntat a la seva adreça retorna les transformacions que negociarà. Si l'única oferta és criptografia que la vostra política ja no permet, la solució és al gateway, no en una rebaixa del client.
A Windows la clau i el mètode d'autenticació viuen al perfil de VPN, i una discrepància apareix abans de la sol·licitud de credencials, no després. Quan el receptor és un Windows Server, confirmeu que el rol d'accés remot està instal·lat, que el certificat coincideix amb el nom al qual es connecten els clients i que cap filtre de ports és més estret que els protocols anteriors.
Tercera etapa: el túnel existeix i PPP no comença mai
Quan IKE es completa i la sol·licitud encara no apareix, mireu el dimoni del túnel i no el tallafoc. L2TP necessita alguna cosa que escolti a UDP 1701 — xl2tpd o kl2tpd a Linux, el servei d'accés remot a Windows — i un servei instal·lat però aturat sembla des del client igual que un paquet descartat. Comproveu l'oient abans de tornar a obrir regles que ja heu verificat. Després PPP ha de negociar, i el primer intercanvi LCP és on sol aterrar una fallada silenciosa.
Una trampa d'aquesta etapa no és cap fallada de xarxa: Windows permet una sola connexió d'un tipus de VPN determinat alhora, així que un segon intent retorna l'error 937, «una altra connexió d'aquest tipus està en ús». És una regla local, i la manera de saltar-se-la és un altre dispositiu, un altre tipus de túnel o compartir l'única connexió que ja existeix.
Llegiu el registre en ordre d'etapes en lloc d'endevinar
Atureu el client, torneu-lo a engegar i llegiu els components en l'ordre en què escriuen al registre. És a dir, primer el dimoni IPsec — strongSwan o Libreswan, i ipsec --version us diu quin — després el dimoni L2TP, després pppd. El component que hagi escrit l'últim abans de la fallada marca l'etapa a investigar, perquè tot el que ve després en la seqüència no es va executar de cap manera.
Verifiqueu amb una connexió nova i no amb una sessió desada, perquè un client que es reconnecta des de la memòria cau pot saltar-se parts de l'intercanvi i reproduir un resultat obsolet. Confirmeu abast, intercanvi de claus, túnel i PPP d'un en un, en aquest ordre. Llavors la sol·licitud absent deixa de ser un misteri i es converteix en la segona línia d'una llista amb la qual realment es pot treballar. Aquesta llista és també el que entregueu a l'equip de xarxa, a qui d'altra manera es demanaria que revisés el tallafoc per una fallada que viu en un dimoni no iniciat.