IKE-identitet eller slutpunktsadress: blanda inte ihop dem
En IKE-identitet av typen FQDN är ett bokstavligt autentiseringsvärde, inte en omvänd DNS-sökning. Håll slutpunktsadressen, den lokala identiteten och den förväntade peer-en åtskilda.
Läs ett fält märkt FQDN-identitet som en bokstavlig sträng, inte som en begäran om det omvända DNS-namnet för din publika adress. I strongSwans parser är det precis det, en sträng, och att läsa den löser den aldrig till en slutpunkt. Just det tar bort den vanligaste distraktionen när du väljer identifierare för en peer. Kontrollerna nedan hindrar de tre inblandade värdena från att smälta samman till ett.
En etikett är inte en sökning
Leverantörernas gränssnitt använder ord som FQDN och hostname löst, och etiketten på en låda säger ingenting om kodningen bakom den. En enhet som kallar ett fält Client FQDN kan skicka en FQDN, en sträng i e-postform eller en naken adress. Behandla texten och typen som två separata beslut och registrera båda.
Ingenting i en bokstavlig identitet kräver DNS. Det är ett påstående som andra sidan kontrollerar, inte ett namn som nätverket måste lösa.
Tre separata värden, skrivna separat
Tre uppgifter ligger bakom en enda konfigurationsskärm, och att slå ihop dem är det dyra misstaget. Ett värde är slutpunktsadressen, som avgör vart paketen går. Ett annat är den lokala identitet som denna peer presenterar, och det tredje är den identitet du förväntar dig från den bortre änden innan du autentiserar den. Skriv dem som tre rader i ändringsärendet, eftersom något mindre beskriver en VPN och inte en relation.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
Exempelidentiteterna måste väljas och auktoriseras som en del av utrullningen. De är påståenden som autentiseringen verifierar, inte inloggningsuppgifter som gör någon peer pålitlig, så en rimlig sträng auktoriserar ingenting.
Typen är en del av värdet
referensen för strongSwan-identiteter skiljer FQDN, värden i e-postform, IP-adresser och andra kodningar, så kodningen spelar lika stor roll som tecknen. Två enheter kan acceptera samma text under olika typer och ändå avvisa varandra. En anteckning som registrerar värdet utan dess typ är en halv konfiguration.
Fråga leverantören vilken typ enheten faktiskt skickar, och bekräfta det med en avkodning i stället för gränssnittets etikett. En gissad typ är en avvikelse som väntar på nästa ändring.
Varje sida måste tillfredsställa den andra
Varje sidas lokala identitet måste passera den andra sidans autentiseringspolicy. Det är inte samma sak som att klistra in en enda sträng i varje identitetsfält på båda enheterna, vilket är genvägen som ger en konfiguration som ingen kan felsöka.
Certifikatautentisering lägger till egna krav, eftersom certifikatets identitet och förtroendevillkoren står bredvid den IKE-identitet du skrev in. En IKE-identitet som stämmer ensam auktoriserar inte en certifikatpeer.
Var DNS spelar roll, och vad din version tvingar fram
Ett gateway-hostname som används för upptäckt behöver verkligen fungerande DNS, och det kravet hör till att hitta slutpunkten och inte till någon omvänd sökning av en inskriven identitet. Håll de två åtskilda i ärendet, eftersom ett upptäcktsfel och en identitetsavvikelse läses likartat i en klientlogg och repareras på olika ställen.
Läs parsern för den produkt och version du faktiskt kör innan du kopierar syntax som tvingar fram en typ, eftersom äldre strongSwan-utgåvor betedde sig annorlunda och andra leverantörer lägger till egna begränsningar. När du jämför de två ändarna, håll fyra saker tillsammans: förväntad identitet, presenterad identitet, typ och autentiseringsfelet. Den uppsättningen gör en avvikelse till bevis i stället för en åsikt.