vpnc-groepsgeheim of je login: welk veld neemt wat?
Een vpnc-profiel vraagt om een groeps-ID, een groepsgeheim en een XAuth-login, en mensen stoppen het accountwachtwoord in het verkeerde vak. Koppel elk veld aan zijn rol.
De eerste keer dat iemand je een vpnc-profiel geeft, vraagt het inlogvenster vier dingen en leest het alsof het één wachtwoord wil. Dat wil het niet: een vooraf gedeeld groepsgeheim en een individuele XAuth-login zijn aparte waarden met aparte eigenaren, en het accountwachtwoord in het groepsveld zetten levert een fout op die op een slecht wachtwoord lijkt in plaats van op een verkeerd veld. De koppeling goed krijgen is de hele opgave hier. Het protocol eronder is iemands anders migratieproject, en daarom is niets hiervan een argument om nieuwe IKEv1-tunnels te bouwen.
Twee geheimen, twee eigenaren, één venster
Een groepsgeheim hoort bij het gatewayprofiel. Iedereen die via dat profiel verbindt, gebruikt dezelfde waarde, en juist daarom kan het geen persoon identificeren en kan het niet van één laptop worden ingetrokken zonder het voor alle andere gebruikers van het profiel te wijzigen. De XAuth-gebruikersnaam en het wachtwoord horen juist bij de mens, en de gateway beoordeelt ze in een tweede fase nadat de IPsec-associatie al staat.
Die tweefasige vorm is wat mensen missen. Tunnelopbouw en gebruikerauthenticatie zijn verschillende uitwisselingen met verschillende invoer, dus een client die de inlogvraag nooit bereikt, is helemaal niet mislukt bij de login. Lees het venster als twee kolommen in plaats van één: profielbrede waarden links, persoonlijke waarden rechts. Als een verbinding mislukt, is de kolom die je het laatst invulde niet automatisch de schuldige.
Koppel de velden aan de rol, niet aan het label
vpnc benoemt zijn richtlijnen in de projectdocumentatie, en elke grafische frontend hernoemt ze. Vertaal de rol van elke waarde, dan doen de labels er niet meer toe:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Een frontend die «Gebruikersnaam» en «Wachtwoord» naast een groepsveld toont, is niet fout — het zijn dezelfde drie waarden onder andere namen. Wat stukgaat, is een veld invullen omdat een waarde erin past. Een groepsgeheim dat als gebruikerswachtwoord wordt geplakt, authenticeert het profiel en faalt daarna in de gebruikersfase; een accountwachtwoord dat als groepsgeheim wordt geplakt, faalt eerder, vóór enige vraag, en stuurt mensen naar firewalls voor een probleem dat in een tekstveld woont.
Wat een groeps-ID niet is
Het woord groep nodigt uit tot een verkeerde lezing. Een groeps-ID is hier een selectie die de gateway vertelt welke profielconfiguratie moet worden toegepast; het zegt niets over lidmaatschap van een directory, en een overeenkomende naam aan beide kanten is toeval tot de beheerder het bevestigt. Autorisatie gebeurt nadat XAuth slaagt, bepaald door wat de gateway geconfigureerd is te raadplegen, en niets daarvan is zichtbaar in het clientvenster.
Dezelfde voorzichtigheid geldt voor het groepsgeheim. Het kennen is geen identiteit, en één geheim rond een team laten gaan is een operationele beslissing met gevolgen die de client je niet kan tonen.
Los de dubbelzinnige instructie op voordat je verbindt
Overdrachtsnotities uit het verleden bevatten vaak een regel als «gebruik het toegewijde openbare IP». Die zin kan het adres betekenen waarvan een allowlist aan de andere kant verwacht dat je verkeer aankomt, dat is een uitgangseigenschap van het netwerk van de beheerder en heeft niets te maken met het eindpunt dat je in het gatewayveld typt. Vraag welke van de twee bedoeld is voordat de waarde ergens heen gaat. Omgekeerd ingevuld stuurt het elk pakket naar een adres dat nooit antwoordt, en de resulterende time-out leest als een geblokkeerde poort.
Vraag vier dingen via het geverifieerde kanaal van de organisatie: welke client en welk protocol worden ondersteund, welk eindpunt te gebruiken, welke identiteit de gateway presenteert en hoe inloggegevens worden overgedragen. Houd echte geheimen buiten schermafbeeldingen, tickets en gedeelde foutzoeknotities. Schakel geen certificaatcontroles uit en plak geen oude cijferlijst om een anders geconfigureerde dienst compatibel te laten lijken, want een verbinding die alleen werkt door de verificatie te verzwakken is niet de verbinding die je moest bouwen.
Houd het oude profiel eerlijk
IKEv1 is verouderd, en RFC 9395 is het document dat je aanhaalt wanneer de migratievraag opkomt. Een geslaagde veldkoppeling is geen bewijs dat het protocol in een nieuw ontwerp hoort; wat het koopt is een werkende verbinding terwijl de vervanging gepland wordt, plus een schriftelijke scope en een eigenaar voor die migratie.
Controleer daarna tegen de eis in plaats van tegen het venster. Bevestig na het verbinden dat de tunnelinterface het verwachte adres heeft en dat een interne bestemming erdoorheen wordt gerouteerd; als de oorspronkelijke eis een uitgangsadres voor een allowlist noemde, bevestig dat adres dan ook, want dat is een ander feit dan dat de tunnel staat. Een profiel dat correct authenticeert en niets routeert, is toch gezakt voor de taak waarvoor het is gemaakt.