IKE-identitet eller endpoint-adresse: undgå at blande dem sammen
En IKE-identitet af typen FQDN er en bogstavelig godkendelsesværdi, ikke et omvendt DNS-opslag. Hold endpoint-adresse, lokal identitet og forventet peer adskilt.
Læs et felt mærket FQDN-identitet som en bogstavelig streng, ikke som en anmodning om det omvendte DNS-navn på din offentlige adresse. I strongSwans parser er det præcis det, en streng, og at læse den opløser den aldrig til et endpoint. Netop det fjerner den mest almindelige distraktion, når du vælger identifikatorer til en peer. Kontrollerne nedenfor forhindrer de tre involverede værdier i at smelte sammen til én.
Et mærke er ikke et opslag
Leverandørers grænseflader bruger ord som FQDN og hostname løst, og mærket på en boks siger intet om kodningen bag det. Et apparat, der kalder et felt Client FQDN, kan sende et FQDN, en streng i e-mailform eller en nøgen adresse. Behandl teksten og typen som to separate beslutninger, og registrer begge.
Intet ved en bogstavelig identitet kræver DNS. Det er et krav, den anden ende kontrollerer, ikke et navn, netværket skal opløse.
Tre separate værdier, skrevet hver for sig
Tre opgaver ligger bag én konfigurationsskærm, og at smelte dem sammen er den dyre fejl. Én værdi er endpoint-adressen, som afgør, hvor pakkerne skal hen. En anden er den lokale identitet, denne peer fremviser, og den tredje er den identitet, du forventer fra den fjerne ende, før du godkender den. Skriv dem som tre linjer i ændringssagen, for alt mindre beskriver en VPN snarere end 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 |
Eksempel-identiteterne skal vælges og autoriseres som en del af udrulningen. De er krav, som godkendelsen verificerer, ikke legitimationsoplysninger, der gør nogen peer troværdig, så en plausibel streng autoriserer intet.
Typen er en del af værdien
Referencen for strongSwan-identiteter adskiller FQDN, værdier i e-mailform, IP-adresser og andre kodninger, så kodningen betyder lige så meget som tegnene. To enheder kan acceptere identisk tekst under forskellige typer og stadig afvise hinanden. Et notat, der registrerer værdien uden dens type, er halv en konfiguration.
Spørg leverandøren, hvilken type apparatet faktisk sender, og bekræft det med en afkodning i stedet for grænsefladens mærke. En gættet type er en uoverensstemmelse, der venter på den næste ændring.
Hver side skal tilfredsstille den anden
Hver sides lokale identitet skal bestå den anden sides godkendelsespolitik. Det er ikke det samme som at indsætte én streng i hvert identitetsfelt på begge enheder, hvilket er den genvej, der giver en konfiguration, ingen kan fejlfinde.
Certifikatgodkendelse tilføjer sine egne krav, fordi certifikatets identitet og tillidsbetingelserne står ved siden af den IKE-identitet, du skrev ind. Et IKE-identitetsmatch alene autoriserer ikke en certifikat-peer.
Hvor DNS betyder noget, og hvad din version tvinger
Et gateway-hostname, der bruges til opdagelse, kræver faktisk fungerende DNS, og det krav hører til at finde endpointet snarere end til noget omvendt opslag af en indtastet identitet. Hold de to adskilt i ændringssagen, fordi en opdagelsesfejl og en identitetsuoverensstemmelse læses ens i en klientlog og repareres forskellige steder.
Læs parseren for det produkt og den version, du faktisk kører, før du kopierer syntaks, der tvinger en type, da ældre strongSwan-udgivelser opførte sig anderledes, og andre leverandører tilføjer deres egne begrænsninger. Når du sammenligner de to ender, hold fire ting sammen: forventet identitet, fremvist identitet, type og godkendelsesfejlen. Det sæt gør en uoverensstemmelse til bevis i stedet for en mening.