La connexió funcionava dijous, l'actualització es va executar divendres, i dilluns el client gira a “connecting” i es rendeix. Mateix portàtil, mateix servidor, mateix compte, mateixa clau compartida prèviament. No es va editar res del perfil, i per això els sospitosos evidents, la contrasenya i el tallafoc, us fan perdre el temps.

El que ha canviat és la llista de transformacions que la vostra màquina està disposada a oferir. Les dues piles IPsec que s'utilitzen a Ubuntu, strongSwan i Libreswan, eliminen algoritmes que ja no consideren segurs, i el connector de NetworkManager que les precedeix té la seva pròpia llista, que es mou amb un calendari diferent. Un servidor fixat a 3DES, SHA1 i un grup Diffie-Hellman de 1024 bits pot acabar no sentint res del que accepta.

Què va canviar realment l'actualització

Dues capes alimenten l'oferta d'IKEv1. El dimoni inclou un conjunt de propostes per defecte compilat, i el connector L2TP o bé hi confia o bé proporciona la seva pròpia llista. Abans de NetworkManager-l2tp 1.2.16 el connector hi confiava, així que la vostra oferta era el que el dimoni instal·lat considerava raonable. A partir d'1.2.16 el connector envia una llista documentada inspirada en els clients de Windows i Apple, i aquesta llista és més àmplia que el defecte antic però ja no conté totes les combinacions heredades al capdavant de la cua.

Aquesta separació explica un mode de fallada que la gent troba confús: dues màquines a la mateixa versió d'Ubuntu poden comportar-se de manera diferent perquè una té el paquet de la distribució i l'altra té un pedaç retroportat, i la versió del dimoni en totes dues sembla idèntica en un informe d'error. Comproveu la versió del connector, no només la del dimoni, abans de concloure que l'actualització no ha canviat res de rellevant.

Hi ha un parany més petit a la mateixa àrea. Els dos dimonis escriuen els grups Diffie-Hellman de corba el·líptica de manera diferent, un escriu ecp384 i l'altre ecp_384. Enganxeu l'ortografia incorrecta al diàleg Avançat i el dimoni rebutjarà la configuració com a no analitzable, cosa que al registre apareix com un problema de negociació i no com una errata de configuració.

Llegiu la fallada abans de canviar res

Comenceu per quin rerefons esteu executant, perquè la resposta decideix tant la sintaxi com la ubicació del registre.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Després llegiu l'intercanvi mateix. A strongSwan el dimoni escriu al journal en una versió actual i a /var/log/syslog en una de més antiga, i la part interessant és la proposta que envia, no la línia final. Esteu buscant text sobre cap proposta coincident, que és un problema d'algoritme; una fallada d'autenticació, que apunta a la clau o al compte; o un temps d'espera simple, que apunta a la connectivitat.

Aquests tres resultats es tracten com un sol símptoma massa sovint. Un temps d'espera amb un registre de dimoni buit vol dir que els paquets no arriben. Un rebuig de proposta vol dir que han arribat i s'han refusat. Si el registre està silenciós, pugeu el nivell de depuració del connector per a un intent i baixeu-lo després, perquè la sortida detallada omple un journal ràpidament.

La fase 1 i la fase 2 són apostes separades

IKEv1 negocia dues vegades. El mode principal construeix l'associació de seguretat IKE a partir d'un algoritme de xifratge, un algoritme d'integritat, un grup Diffie-Hellman i un mètode d'autenticació. El mode ràpid després construeix l'associació ESP que transportarà L2TP. Un servidor és lliure d'acceptar la primera i rebutjar la segona, així que un perfil mig correcte falla més tard del que espereu i sembla un error diferent.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

El signe d'exclamació és sintaxi de strongSwan per a una entrada estricta: oferiu aquesta única combinació i res més. Sense ell l'entrada s'afegeix a una llista de reserva, cosa que va bé quan el peer és modern i és contraproduent quan és un aparell amb una única política codificada. Tracteu el parell de dalt com una il·lustració de la forma, no com una recomanació per a res del que estigueu construint avui.

Canvieu un camp i repetiu la prova

En un connector actual, la prova inicial més ràpida és buidar del tot els dos camps de propostes i tornar a connectar, perquè la llista per defecte subministrada ja inclou les combinacions habituals de Windows i Apple. En un connector més antic, buidar-los torna el control a un dimoni que pot haver descartat l'algoritme que el vostre servidor exigeix, i la fallada empitjora.

Si buidar-los no ajuda, establiu el parell estricte que documenta el vostre servidor, una fase cada cop. Canvieu la fase 1, torneu a connectar i llegiu el registre abans de tocar la fase 2. Quan una combinació finalment funcioni, anoteu-la al costat del model de servidor i de la versió del connector, perquè els valors per defecte es tornaran a moure i aquesta nota és el que converteix la propera actualització en una comprovació de cinc minuts.

Articles relacionats