Identita IKE nebo adresa koncového bodu: nezaměňujte je
Identita IKE typu FQDN je doslovná ověřovací hodnota, nikoli reverzní vyhledání DNS. Udržujte adresu koncového bodu, místní identitu a očekávaný protějšek odděleně.
Čtěte pole označené jako identita FQDN jako doslovný řetězec, nikoli jako žádost o reverzní jméno DNS vaší veřejné adresy. V parseru strongSwan je to přesně to, řetězec, a jeho čtení ho nikdy nepřeloží na koncový bod. Už tento fakt odstraňuje nejčastější rozptýlení při volbě identifikátorů pro protějšek. Níže uvedené kontroly brání tomu, aby se tři zúčastněné hodnoty slily v jednu.
Označení není vyhledání
Rozhraní výrobců používají slova jako FQDN a hostname volně a označení na krabici nic neříká o kódování, které je za ním. Zařízení, které pole nazývá Client FQDN, může poslat FQDN, řetězec ve tvaru e-mailu nebo holou adresu. Berte text a typ jako dvě samostatná rozhodnutí a zaznamenejte obě.
Nic u doslovné identity nevyžaduje DNS. Je to tvrzení, které kontroluje druhá strana, ne jméno, které musí síť překládat.
Tři oddělené hodnoty, odděleně zapsané
Za jednou konfigurační obrazovkou stojí tři úlohy a jejich sloučení je drahá chyba. Jedna hodnota je adresa koncového bodu, která rozhoduje, kam pakety půjdou. Další je místní identita, kterou tento protějšek předkládá, a třetí je identita, kterou očekáváte od vzdálené strany, než ji ověříte. Zapište je jako tři řádky do tiketu změny, protože cokoli méně popisuje VPN, a ne vztah.
| 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 |
Příkladové identity musí být vybrány a autorizovány jako součást nasazení. Jsou to tvrzení, která ověřování kontroluje, ne přihlašovací údaje, které by učinily kterýkoli protějšek důvěryhodným, takže věrohodně vypadající řetězec nic neautorizuje.
Typ je součástí hodnoty
Referenční příručka identit strongSwan odděluje FQDN, hodnoty ve tvaru e-mailu, IP adresy a další kódování, takže kódování záleží stejně jako znaky. Dvě zařízení mohou přijmout stejný text pod různými typy a přesto se navzájem odmítnout. Poznámka, která zaznamená hodnotu bez jejího typu, je polovina konfigurace.
Zeptejte se dodavatele, jaký typ zařízení skutečně posílá, a potvrďte to dekódováním, ne popiskem rozhraní. Uhodnutý typ je neshoda čekající na další změnu.
Každá strana musí uspokojit tu druhou
Místní identita každé strany musí projít zásadou ověřování druhé strany. To není totéž jako vložit jeden řetězec do každého pole identity na obou zařízeních, což je zkratka, která vytvoří konfiguraci, kterou nikdo nedokáže ladit.
Ověřování certifikátem přidává vlastní požadavky, protože identita certifikátu a podmínky důvěry stojí vedle identity IKE, kterou jste zadali. Shoda identity IKE sama o sobě neautorizuje protějšek s certifikátem.
Kde záleží na DNS a co vynucuje vaše verze
Název hostitele brány používaný pro zjišťování skutečně potřebuje fungující DNS a tento požadavek patří k hledání koncového bodu, ne k nějakému reverznímu vyhledání zadané identity. V tiketu je držte oddělené, protože selhání zjišťování a neshoda identity se v klientském logu čtou podobně a opravují se na různých místech.
Přečtěte si parser produktu a verze, kterou skutečně provozujete, než zkopírujete syntaxi, která vynucuje typ, protože starší verze strongSwan se chovaly jinak a jiní výrobci přidávají vlastní omezení. Když porovnáváte oba konce, držte pohromadě čtyři věci: očekávanou identitu, předloženou identitu, typ a chybu ověřování. Tato sada mění neshodu v důkaz místo názoru.