IKE-identitet eller endepunktadresse: ikke bland dem
En IKE-identitet av typen FQDN er en bokstavelig autentiseringsverdi, ikke et omvendt DNS-oppslag. Hold endepunktadressen, den lokale identiteten og den forventede peer-en atskilt.
Les et felt merket FQDN-identitet som en bokstavelig streng, ikke som en forespørsel om det omvendte DNS-navnet til den offentlige adressen din. I strongSwans parser er det nettopp det, en streng, og å lese den løser den aldri til et endepunkt. Nettopp det fjerner den vanligste distraksjonen når du velger identifikatorer for en peer. Kontrollene nedenfor hindrer de tre involverte verdiene i å smelte sammen til én.
En etikett er ikke et oppslag
Leverandørenes grensesnitt bruker ord som FQDN og hostname løst, og etiketten på en boks sier ingenting om kodingen bak den. En enhet som kaller et felt Client FQDN, kan sende en FQDN, en streng i e-postform eller en naken adresse. Behandle teksten og typen som to separate beslutninger, og registrer begge.
Ingenting ved en bokstavelig identitet krever DNS. Det er en påstand den andre enden kontrollerer, ikke et navn nettverket må løse.
Tre separate verdier, skrevet separat
Tre oppgaver ligger bak én konfigurasjonsskjerm, og å slå dem sammen er den dyre feilen. Én verdi er endepunktadressen, som avgjør hvor pakkene går. En annen er den lokale identiteten denne peer-en viser fram, og den tredje er identiteten du forventer fra den fjerne enden før du autentiserer den. Skriv dem som tre linjer i endringssaken, fordi noe mindre beskriver en VPN og ikke et forhold.
| 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 |
Eksempelidentitetene må velges og autoriseres som en del av utrullingen. De er påstander som autentiseringen verifiserer, ikke legitimasjon som gjør noen peer pålitelig, så en plausibel streng autoriserer ingenting.
Typen er en del av verdien
referansen for strongSwan-identiteter skiller FQDN, verdier i e-postform, IP-adresser og andre kodinger, så kodingen betyr like mye som tegnene. To enheter kan godta samme tekst under ulike typer og likevel avvise hverandre. Et notat som registrerer verdien uten typen, er en halv konfigurasjon.
Spør leverandøren hvilken type enheten faktisk sender, og bekreft det med en dekoding i stedet for grensesnittets etikett. En gjettet type er et avvik som venter på neste endring.
Hver side må tilfredsstille den andre
Den lokale identiteten til hver side må passere den andre sidens autentiseringspolicy. Det er ikke det samme som å lime én streng inn i hvert identitetsfelt på begge enhetene, som er snarveien som gir en konfigurasjon ingen kan feilsøke.
Sertifikatautentisering legger til egne krav, fordi sertifikatets identitet og tillitsvilkårene står ved siden av IKE-identiteten du skrev inn. En IKE-identitet som stemmer alene autoriserer ikke en sertifikat-peer.
Hvor DNS betyr noe, og hva versjonen din tvinger fram
Et gateway-hostname som brukes til oppdagelse trenger faktisk fungerende DNS, og det kravet hører til å finne endepunktet og ikke til noe omvendt oppslag av en innskrevet identitet. Hold de to atskilt i endringssaken, fordi en oppdagelsesfeil og et identitetsavvik leses likt i en klientlogg og repareres på ulike steder.
Les parseren for produktet og versjonen du faktisk kjører før du kopierer syntaks som tvinger fram en type, siden eldre strongSwan-utgivelser oppførte seg annerledes og andre leverandører legger til egne begrensninger. Når du sammenligner de to endene, hold fire ting sammen: forventet identitet, presentert identitet, type og autentiseringsfeilen. Det settet gjør et avvik til bevis i stedet for en mening.