IKE-identitet eller endepunktadresse: ikkje blande dei
Ein IKE-identitet av typen FQDN er ein bokstaveleg autentiseringsverdi, ikkje eit omvendt DNS-oppslag. Hald endepunktadressa, den lokale identiteten og den venta peer-en skilde.
Les eit felt merkt FQDN-identitet som ein bokstaveleg streng, ikkje som ein førespurnad om det omvende DNS-namnet til den offentlege adressa di. I parsaren til strongSwan er det nettopp det, ein streng, og å lese han løyser han aldri til eit endepunkt. Nettopp det fjernar den vanlegaste distraksjonen når du vel identifikatorar for ein peer. Kontrollane nedanfor hindrar dei tre involverte verdiane i å smelte saman til éin.
Eit merke er ikkje eit oppslag
Grensesnitta til leverandørane brukar ord som FQDN og hostname laust, og merket på ein boks seier ingenting om kodinga bak han. Ein eining som kallar eit felt Client FQDN, kan sende ein FQDN, ein streng i e-postform eller ei naken adresse. Handsame teksten og typen som to separate avgjerder, og registrer båe.
Ingenting ved ein bokstaveleg identitet krev DNS. Det er ein påstand den andre enden kontrollerer, ikkje eit namn nettet må løyse.
Tre skilde verdiar, skrivne kvar for seg
Tre oppgåver ligg bak ein konfigurasjonsskjerm, og å slå dei saman er den dyre feilen. Éin verdi er endepunktadressa, som avgjer kvar pakkane går. Ein annan er den lokale identiteten denne peer-en viser fram, og den tredje er identiteten du ventar frå den fjerne enden før du autentiserer han. Skriv dei som tre linjer i endringssaka, fordi noko mindre skildrar ein VPN og ikkje eit tilhøve.
| 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 |
Døme-identitetane må veljast og autoriserast som ein del av utrullinga. Dei er påstandar som autentiseringa verifiserer, ikkje legitimasjon som gjer nokon peer påliteleg, så ein plausibel streng autoriserer ingenting.
Typen er ein del av verdien
referansen for strongSwan-identitetar skil FQDN, verdiar i e-postform, IP-adresser og andre kodingar, så kodinga tel like mykje som teikna. To einingar kan godta same tekst under ulike typar og likevel avvise kvarandre. Eit notat som registrerer verdien utan typen, er ein halv konfigurasjon.
Spør leverandøren kva type eininga faktisk sender, og stadfest det med ei dekoding i staden for grensesnittmerket. Ein gissa type er eit avvik som ventar på neste endring.
Kvar side må tilfredsstille den andre
Den lokale identiteten til kvar side må passere autentiseringspolitikken til den andre sida. Det er ikkje det same som å lime éin streng inn i kvart identitetsfelt på båe einingane, som er snarvegen som gjev ein konfigurasjon ingen kan feilsøkje.
Sertifikatautentisering legg til eigne krav, fordi identiteten til sertifikatet og tillitsvilkåra står ved sida av IKE-identiteten du skreiv inn. Ein IKE-identitet som stemmer åleine autoriserer ikkje ein sertifikatpeer.
Kvar DNS tel, og kva versjonen din tvingar fram
Eit gateway-hostname som vert brukt til oppdaging treng faktisk fungerande DNS, og det kravet høyrer til å finne endepunktet og ikkje til noko omvendt oppslag av ein innskriven identitet. Hald dei to skilde i endringssaka, fordi ein oppdagingsfeil og eit identitetsavvik les likt i ein klientlogg og vert reparerte på ulike stader.
Les parsaren for produktet og versjonen du faktisk køyrer før du kopierer syntaks som tvingar fram ein type, sidan eldre strongSwan-utgivingar oppførte seg annleis og andre leverandørar legg til eigne avgrensingar. Når du samanliknar dei to endane, hald fire ting saman: venta identitet, presentert identitet, type og autentiseringsfeilen. Det settet gjer eit avvik til bevis i staden for ei meining.