strongSwan EAP: de IKE-identiteit tegenover de verwachte AAA-naam

EAP-authenticatie over IKEv2 kan van een client vragen om twee verschillende servernamen in één verbinding te valideren. De gateway die IKE beëindigt, presenteert één identiteit, en de EAP-backend die de interne TLS-uitwisseling beëindigt, kan een andere presenteren. In strongSwan staan ze in verschillende configuratieblokken, en een naam in het verkeerde blok levert een fout op die op een certificaatprobleem lijkt. Juist het lezen van welke validatie mislukte, zegt welk blok je moet aanpassen.

Eén verbinding, twee serveridentiteiten

De eerste identiteit hoort bij de IKE-uitwisseling. De client kiest een adres en verwacht dat de tegenpartij een bepaalde identiteit bewijst, meestal de naam in het gateway-certificaat.

De tweede hoort bij EAP. Met PEAP of TTLS bouwt de client een TLS-tunnel naar de authenticatieserver binnen de IKE SA, en die interne server presenteert zijn eigen certificaat. Als de backend een aparte host is, wijkt zijn naam af van die van de gateway. Een client die alleen de eerste naam controleert, accepteert wat de tweede beweert. En een client met één naam op beide plaatsen faalt zodra de twee echt verschillen.

Beide namen komen uit de configuratie van de operator, niet uit het certificaat dat de fout laat verdwijnen. De operator om de uitrolgegevens vragen is sneller dan twee hostnamen raden.

Welk veld bij welke laag hoort

In swanctl zijn het adres en de IKE-identiteit aparte instellingen, en de EAP-identiteit is een derde.

Het externe adres bepaalt waar pakketten heen gaan, en de externe identiteit zegt wat de tegenpartij moet bewijzen. De EAP-verwachting staat onder het local-blok, omdat die de EAP-uitwisseling van deze client beschrijft en niet het IKE-gedrag van de tegenpartij. Precies die plaats wordt verkeerd gelezen. De naam staat in de configuratie van de client terwijl hij een server beschrijft, en daarom lijkt hij misplaatst.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

Dat fragment is geen volledige verbinding; vertrouwensmateriaal, inloggegevens en beleid voor kindverbindingen moeten er nog zijn. Het woord voor woord in een werkend bestand kopiëren zou instellingen vervangen die je nog nodig hebt.

Waarom aaa_id onder local staat

Het local-blok beschrijft wat deze kant tijdens de authenticatie doet, inclusief de methode die hij gebruikt en de identiteit die hij voor die methode van de andere kant verwacht. Niets erin beweert dat de AAA-server op dezelfde machine draait.

De standaardwaarde maakt de val scherper. Als er geen expliciete waarde is ingesteld, volgt de verwachte AAA-identiteit de externe identiteit, zodat een uitrol met één naam werkt en het verschil verbergt. Een expliciete waarde telt alleen als de EAP-uitrol echt ergens anders eindigt. Hem zonder die reden op een andere naam zetten, maakt een fout die de operator niet kan reproduceren. Lees de uitrol voordat je een tweede naam bedenkt.

Houd de waarde identiek aan wat het backend-certificaat werkelijk beweert, inclusief de vorm van de naam. Een punt aan het eind of een jokerteken dat de host niet dekt, is genoeg om de controle te laten falen.

Frontends die de splitsing niet kunnen uitdrukken

Een NetworkManager-profiel is niet dezelfde configuratie-interface als swanctl. De plugin erachter biedt een smaller set identiteitsbesturingen, en welke bestaan hangt af van de geïnstalleerde versie.

Dat maakt uit wanneer de uitrol echt twee namen nodig heeft. Een veld met het label serveridentiteit kan de ene laag configureren en de andere niet, zodat een profiel correct kan lijken en toch de interne controle kan falen. Controleer wat de geïnstalleerde plugin ondersteunt voordat je aanneemt dat het profiel de opzet kan uitdrukken. Kan het dat niet, dan ligt de keuze bij de operator: een ander provisioningpad of een gecorrigeerd ontwerp van de serveridentiteit. PEAP verzwakken of elke naam accepteren verandert het authenticatiebeleid in plaats van het te repareren.

Het alternatief is niet iets om op de client te bedenken. Vraag de ondersteunde opzet schriftelijk en bewaar dat antwoord bij het profiel.

Onderscheid een identiteitsconflict van een verlopen certificaat

Een naamconflict en een verlopen certificaat zijn verschillende fouten, en de log onderscheidt ze. Lees de melding voordat je besluit welk veld je wijzigt.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

De beoogde AAA-identiteit instellen verlengt geen certificaat en vestigt geen vertrouwen in de uitgever, en een certificaat verlengen corrigeert geen verkeerde verwachte naam. Lees welke validatie mislukte voordat je nog een identiteitsveld aanpast. Laad daarna de configuratie opnieuw en bevestig dat de geladen verbinding de ingestelde waarde toont, want een bewerkt bestand dat nooit is geladen, verandert niets. Schrijf beide namen en hun lagen in de uitrolnotities.