IKEv2 serveradress vs identitet: vad klienten faktiskt kontrollerar
Adressen säger var man ska ringa; identiteten säger vilken kamrat man ska acceptera. Att blanda ihop dem är anledningen till att en flyttad gateway eller ett nytt certifikat går sönder IKEv2.
En gateway som byter adress kan fortsätta att fungera medan samma gateway bakom ett nytt certifikat stannar, och det omvända händer också. Adressen talar om för klienten vart den ska skicka paket; den autentiserade identiteten talar om för klienten om den peer som svarar är den som den ska lita på. IKEv2 behåller dessa som två separata fält, vilket är användbart när du slutar behandla dem som en sträng. De är också konfigurerade på olika ställen, så den ena kan vara korrekt medan den andra är fel.
Kontrollera dem i denna ordning och sluta vid den första missmatchningen, eftersom de senare kontrollerna antar att de tidigare godkända.
Först, vilket värde är adressen
Anslutningsadressen är vad klienten än ringer: en IP, ett DNS namn som löser sig till ett eller ett lastbalanserat gränssnitt. Det är transportinformation och inget mer. Identiteten åker i IKEv2 ID-nyttolasten och matchas sedan mot kamratens certifikat. Ett DNS namn i adressrutan blir inte den förväntade identiteten, och en rå IP blir inte identiteten bara för att uttaget är anslutet till det.
I termer av strongSwan är adressen right eller left, och den förväntade identiteten är rightid eller leftid, och det är vad IKEv2 konfigurationsdokumentationen beskriver. Om du bara någonsin har redigerat adressen har du konfigurerat hälften av paret.
För det andra, vad certifikatet kan bevisa
Identiteten har en typ och certifikatet måste ha ett matchande namn. En DNS-identitet uppfylls av en dNSName-post i ämnets alternativa namntillägg; en IP-identitet behöver en iPAddress-post. Ett certifikat utfärdat för vpn.example.com bevisar ingenting om den bokstavliga adressen 203.0.113.10, och ett som utfärdats för den adressen bevisar ingenting om namnet. Återutgivning för ett annat namn är därför inte en drop-in-ersättning, även när samma nyckel och CA återanvänds.
Moderna kunder ignorerar det vanliga namnet när det finns ett alternativt ämnesnamn, och många ignorerar det helt. Om listan SAN inte innehåller värdet som klienten kontrollerar, misslyckas handskakningen efter att certifikatet redan har accepterats som tillförlitligt, vilket är anledningen till att loggen läses som ett identitetsfel snarare än ett förtroendefel.
För det tredje, hur varje kund anger förväntningarna
Windows tar servernamnet eller adressen du skrev och kräver att certifikatet matchar det, så att skriva en IP skapar en IP-förväntning. Androids IKEv2-klient beter sig på samma sätt och båda avvisar ett giltigt, offentligt pålitligt certifikat som namnger en annan värd. En profil kan börja misslyckas bara för att någon ersatte värdnamnet med dess adress under en migrering. Titta på vad klienten frågade efter innan du tittar på vad certifikatet innehåller.
På strongSwan är förväntningen explicit: ställ in rightid på den identitet som servern faktiskt presenterar, vilket kan skilja sig från höger. Om du ställer in den på %any accepteras vad kamraten erbjuder och tar bort exakt den check du försöker behålla.
För det fjärde, separera användarinloggning från peer-identitet
EAP autentisering och serveridentitet svarar på olika frågor. En EAP identitet som [email protected] säger vem användaren är, efter att klienten har bestämt sig för att servern är den rätta. Att rotera det lösenordet kan inte fixa en felmatchning av peer-identitet, eftersom anslutningen aldrig når användarinloggningsstadiet.
En sanerad rapport bör namnge båda: identiteten som klienten förväntade sig, identiteten som servern presenterade och certifikatets SAN-poster.
För det femte, ändra det genom en verifierad kanal
När gatewayen rör sig legitimt, uppdatera adressen först och lämna identiteten ifred, eftersom det är fallet IKEv2 hanterar bra. När själva identiteten ändras, behandla den som en förtroendehändelse och hämta det nya värdet från en källa som du redan litar på, inte från den slutpunkt som för närvarande misslyckas. Ett meddelande som levereras över anslutningen du försöker validera är inte bevis på den anslutningen.
Anteckna den slutliga adressen, identiteten och SAN-listan tillsammans i profilanteckningarna. Nästa person som rör certifikatet kommer då att se vem av de tre som får flytta.