L2TP/IPsec-PSK geweigerd: eerst de dialoog, dan de bestanden

Je plakt de vooraf gedeelde sleutel uit het bericht van de beheerder in de NetworkManager-dialoog, zet het vinkje om hem te tonen, en hij komt teken voor teken overeen. De verbinding eindigt toch in een authenticatiefout voordat de tunnel staat. Toen ik dat de eerste keer zag, dacht ik dat de sleutel fout was; dat was hij niet. Twee andere dingen bepalen wat de daemon werkelijk leest: het geheimenbestand dat de plug-in voor die verbinding schrijft, en of de waarde ongewijzigd door de dialoog is gekomen.

De gang hieronder volgt de sleutel van het veld naar het bestand, en juist die volgorde vertelt je waar hij verloren ging. Doe het op de machine die faalt, niet op de machine die werkt, want het verschil tussen die twee is meestal de bestandsindeling en niet de sleutel.

Begin bij de dialoog, maar vertrouw het veld niet

Open het IPsec-tabblad van de verbinding en typ de sleutel opnieuw in plaats van hem te plakken. Een sleutel die uit een chatbericht, een pdf of een wachtwoordbeheerder is gekopieerd, kan aankomen met een regeleinde aan het eind dat het veld niet toont, en de zichtbare tekens zien er nog steeds goed uit.

Klik op de knop om het wachtwoord te tonen en kijk naar het eind van de tekenreeks, niet naar het midden. Laat de cursor een lege regel onder de tekst achter, verwijder die dan en typ het laatste teken opnieuw. Die ene correctie lost een verrassend deel van dit soort meldingen op, en kost minder dan het lezen van welke log dan ook.

Komt de sleutel uit een ticketsysteem dat lange regels afbreekt, vraag hem dan op via een kanaal dat niet afbreekt. Vergelijk de lengtes met de beheerder in plaats van twee tekenreeksen naast elkaar te bekijken; een verloren teken op een afbreekpunt is onzichtbaar in een proportioneel lettertype.

Volg de sleutel tot in /etc/ipsec.d

De plug-in geeft de PSK nooit als argument op een commandoregel aan de IPsec-daemon. In plaats daarvan bewaart hij de waarde in een geheimenbestand en regelt hij dat de daemon dat bestand opneemt, door een include-regel aan /etc/ipsec.secrets toe te voegen als die ontbreekt. Wat de dialoog vasthoudt, is invoer voor dat gegenereerde bestand, niet de waarde die in gebruik is.

Som op wat er bestaat voordat je iets verandert:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Oudere releases van de plug-in schreven één bestand per verbinding, vernoemd naar de UUID van de verbinding, bijvoorbeeld /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Een profiel verwijderen in de applet verwijdert dat bestand niet betrouwbaar. Staat er nog een oud bestand van een vorige server op de schijf en wordt het nog steeds opgenomen, dan kan de daemon een geheim kiezen dat bij een profiel hoort dat je niet meer gebruikt, en de verbinding faalt terwijl het zichtbare veld juist is.

Begrijp wat de wijziging in 1.2.12 met upgrades deed

Plug-inversie 1.2.12 verving de geheimenbestanden per verbinding door één gedeeld bestand, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Een upgrade ruimt de oudere bestanden per UUID niet op, en een bestaande include /etc/ipsec.d/*.secrets-regel neemt ze nog steeds op. Versie 1.2.16 veranderde de omgang met standaardvoorstellen, niet de indeling van de geheimen.

Die geschiedenis verklaart waarom twee machines met wat op hetzelfde profiel lijkt zich anders gedragen. De sleutel is identiek; de set bestanden die de daemon opneemt niet. Als je een verweesd bestand verwijdert, zet het dan opzij in plaats van het te wissen, bevestig de verbinding en wis het pas als de werkende toestand is vastgelegd. Hernoemen houdt de oude waarde herstelbaar als blijkt dat de fout ergens anders zit.

Scheid de tekens die het opslagformaat niet kan bevatten

De strongSwan-documentatie over de gedeelde geheimreeks stelt dat de waarde geen regeleinde of dubbel aanhalingsteken mag bevatten. Een sleutel die uit een document is geplakt, kan beide bevatten zonder enig visueel verschil in een normale dialoog.

Sinds 1.2.12 is de opgeslagen waarde geen platte tekst. De plug-in codeert de PSK in base64 voordat hij het bestand bereikt, en de release-opmerkingen noemen die codering als de reden dat een dubbel aanhalingsteken nu aanvaardbaar is in een sleutel. Een in het veld getypt aanhalingsteken is dus voorstelbaar; dat geldt niet voor elk controleteken.

Lengte is een andere beperking. Er geldt geen universeel minimum voor L2TP/IPsec-software: sommige clients accepteren sleutels korter dan twintig tekens en sommige gateways dwingen een minimum af. Wordt een korte sleutel geweigerd, dan hoort de regel bij het serverbeleid of bij de validatie van die client, en iets lokaals verhogen verandert dat niet.

Lees welke authenticatielaag faalde

Voer eerst ipsec --version uit, want strongSwan en Libreswan gebruiken verschillende bestandsnamen en syntaxis, en advies voor de een kan de ander beschadigen. Lees daarna de faalfase uit het bericht van de client of het log van de daemon: een klacht over de vooraf gedeelde sleutel is een andere gebeurtenis dan een geweigerde gebruikersnaam en wachtwoord.

De PSK authenticeert de eindpunten van de tunnel. De gebruikersnaam en het wachtwoord authenticeren de persoon binnen L2TP, en PPP behandelt ze nadat de IPsec-associatie staat. Een juiste PSK met een verkeerd account faalt alsnog, en een account wijzigen repareert geen sleutel die de daemon nooit goed las.

Als je het ticket sluit, noteer dan alle vier: plug-inversie, het gebruikte geheimenbestand, of de sleutel opnieuw is getypt of geplakt, en de laag die in de fout wordt genoemd. Zo kan iedereen die deze gang later herhaalt meteen doorspringen naar het verschil tussen de werkende en de falende machine.