IKE-identiteit of endpointadres: haal ze niet door elkaar

Lees een veld met het label FQDN-identiteit als een letterlijke tekenreeks, niet als een verzoek om de reverse-DNS-naam van je openbare adres. In de parser van strongSwan is het precies dat, een tekenreeks, en het lezen ervan lost het nooit op naar een endpoint. Dat feit alleen al haalt de meest voorkomende afleiding weg wanneer je identificaties voor een peer kiest. De controles hieronder voorkomen dat de drie betrokken waarden in één samensmelten.

Een label is geen lookup

Leveranciersinterfaces gebruiken woorden als FQDN en hostname losjes, en het label op een doos zegt niets over de codering erachter. Een apparaat dat een veld Client FQDN noemt, kan een FQDN, een tekenreeks in e-mailvorm of een kaal adres sturen. Behandel de tekst en het type als twee afzonderlijke beslissingen en leg beide vast.

Niets aan een letterlijke identiteit vereist DNS. Het is een bewering die de andere kant controleert, geen naam die het netwerk moet oplossen.

Drie afzonderlijke waarden, apart opgeschreven

Drie taken zitten achter één configuratiescherm, en ze samenvoegen is de dure fout. Eén waarde is het endpointadres, dat bepaalt waar de pakketten heen gaan. Een andere is de lokale identiteit die deze peer presenteert, en de derde is de identiteit die je van de andere kant verwacht voordat je die authenticeert. Schrijf ze als drie regels in de wijzigingsticket, want alles minder beschrijft een VPN in plaats van een relatie.

De voorbeeldidentiteiten moeten als onderdeel van de uitrol worden gekozen en geautoriseerd. Het zijn beweringen die de authenticatie verifieert, geen inloggegevens die een peer betrouwbaar maken, dus een plausibel uitziende tekenreeks autoriseert niets.

Het type is deel van de waarde

referentie voor strongSwan-identiteiten onderscheidt FQDN, waarden in e-mailvorm, IP-adressen en andere coderingen, dus de codering telt even zwaar als de tekens. Twee apparaten kunnen dezelfde tekst onder verschillende typen accepteren en elkaar toch weigeren. Een notitie die de waarde zonder het type vastlegt, is een halve configuratie.

Vraag de leverancier welk type het apparaat werkelijk stuurt, en bevestig dat met een decodering in plaats van met het interfacelabel. Een geraden type is een mismatch die op de volgende wijziging wacht.

Elke kant moet de andere voldoen

De lokale identiteit van elke kant moet het authenticatiebeleid van de andere kant doorstaan. Dat is niet hetzelfde als één tekenreeks in elk identiteitsveld op beide apparaten plakken, wat de snelkoppeling is die een configuratie oplevert die niemand kan debuggen.

Authenticatie met een certificaat voegt eigen eisen toe, omdat de identiteit van het certificaat en de vertrouwensvoorwaarden naast de IKE-identiteit staan die je hebt getypt. Een overeenkomende IKE-identiteit alleen autoriseert geen certificaatpeer.

Waar DNS telt, en wat je versie afdwingt

Een gateway-hostname die voor discovery wordt gebruikt, heeft wel werkende DNS nodig, en die eis hoort bij het vinden van het endpoint en niet bij een reverse-lookup van een getypte identiteit. Houd de twee apart in de ticket, want een discovery-fout en een identiteitsmismatch lezen vergelijkbaar in een clientlog en worden op verschillende plaatsen gerepareerd.

Lees de parser voor het product en de versie die je werkelijk draait voordat je syntaxis kopieert die een type afdwingt, omdat oudere strongSwan-versies zich anders gedroegen en andere leveranciers eigen beperkingen toevoegen. Wanneer je de twee kanten vergelijkt, houd vier dingen bij elkaar: verwachte identiteit, gepresenteerde identiteit, type en de authenticatiefout. Die set maakt van een mismatch bewijs in plaats van een mening.