Forbindelsen virkede torsdag, opgraderingen kørte fredag, og mandag spinner klienten på “connecting” og giver op. Samme bærbare, samme server, samme konto, samme foruddelte nøgle. Intet i profilen blev redigeret, og derfor spilder de oplagte mistænkte, adgangskoden og firewallen, din tid.

Det, der ændrede sig, er listen over transformationer, som din maskine er villig til at tilbyde. Begge de IPsec-stakke, der bruges på Ubuntu, strongSwan og Libreswan, fjerner algoritmer, som de ikke længere anser for sikre, og NetworkManager-pluginet foran dem har sin egen liste, der flytter sig efter en anden tidsplan. En server fastlåst til 3DES, SHA1 og en 1024-bit Diffie-Hellman-gruppe kan ende med ikke at høre noget, den accepterer.

Hvad opgraderingen faktisk ændrede

To lag leverer IKEv1-forslaget. Dæmonen leverer et indbygget standardsæt af forslag, og L2TP-pluginet overlader det enten til den eller leverer sin egen liste. Før NetworkManager-l2tp 1.2.16 overlod pluginet det, så dit forslag var hvad den installerede dæmon anså for rimeligt. Fra 1.2.16 sender pluginet en dokumenteret liste modelleret efter Windows- og Apple-klienter, og den liste er bredere end den gamle standard, men indeholder ikke længere enhver ældre kombination forrest i køen.

Den opdeling forklarer en fejltilstand, som folk finder forvirrende: to maskiner på samme Ubuntu-udgivelse kan opføre sig forskelligt, fordi den ene har distributionspakken og den anden har en backport, og dæmonversionen på begge ser identisk ud i en fejlrapport. Kontroller pluginversionen, ikke kun dæmonversionen, før du konkluderer, at opgraderingen ikke ændrede noget relevant.

Der er en mindre fælde i samme område. De to dæmoner staver de elliptiske-kurve Diffie-Hellman-grupper forskelligt, den ene skriver ecp384 og den anden ecp_384. Indsæt den forkerte stavemåde i Advanced-dialogen, og dæmonen afviser indstillingen som uparserbar, hvilket i loggen viser sig som et forhandlingsproblem snarere end en tastefejl i konfigurationen.

Læs fejlen, før du ændrer noget

Start med hvilken backend du kører, fordi svaret afgør både syntaksen og loggens placering.

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

Læs derefter selve udvekslingen. På strongSwan skriver dæmonen til journalen på en aktuel udgivelse og til /var/log/syslog på en ældre, og den interessante del er det forslag, den sender, ikke den sidste linje. Du leder efter formuleringer om intet matchende forslag, hvilket er et algoritmeproblem; en godkendelsesfejl, som peger på nøglen eller kontoen; eller en almindelig timeout, som peger på tilgængelighed.

Disse tre udfald bliver alt for ofte behandlet som ét symptom. En timeout med en tom dæmonlog betyder, at pakkerne ikke ankommer. En afvisning af forslaget betyder, at de ankom og blev afvist. Hvis din log er tavs, så hæv pluginets fejlfindingsniveau for et enkelt forsøg og sænk det bagefter, fordi det detaljerede output hurtigt fylder en journal.

Fase 1 og fase 2 er separate væddemål

IKEv1 forhandler to gange. Hovedtilstand bygger IKE-sikkerhedsassociationen ud fra en krypteringsalgoritme, en integritetsalgoritme, en Diffie-Hellman-gruppe og en godkendelsesmetode. Hurtig tilstand bygger derefter ESP-associationen, som skal bære L2TP. En server er fri til at acceptere den første og afvise den anden, så en halvkorrekt profil fejler senere, end du forventer, og ligner en anden fejl.

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

Udråbstegnet er strongSwan-syntaks for en streng post: tilbyd denne ene kombination og intet andet. Uden det slutter posten sig til en reservliste, hvilket er fint, når modparten er moderne, og kontraproduktivt, når den er et apparat med én hårdt kodet politik. Betragt parret ovenfor som en illustration af formen, ikke som en anbefaling til noget, du bygger i dag.

Ændr ét felt, og gentag så testen

På et aktuelt plugin er den hurtigste første test at rydde begge forslagsfelter helt og genoprette forbindelsen, fordi den medfølgende standardliste allerede indeholder de almindelige Windows- og Apple-kombinationer. På et ældre plugin giver rydningen kontrollen tilbage til en dæmon, der måske har droppet den algoritme, din server insisterer på, og fejlen bliver værre.

Hvis rydningen ikke hjælper, så indstil det strenge par, som din server dokumenterer, én fase ad gangen. Ændr fase 1, genopret forbindelsen, og læs loggen, før du rører fase 2. Når en kombination endelig virker, så skriv den ned ved siden af servermodellen og pluginversionen, fordi standarderne flytter sig igen, og den note er det, der gør den næste opgradering til et femminutters tjek.

Relaterede artikler