Identita IKE alebo adresa koncového bodu: nezamieňajte ich
Identita IKE typu FQDN je doslovná overovacia hodnota, nie reverzné vyhľadávanie DNS. Udržujte oddelene adresu koncového bodu, lokálnu identitu a očakávaného peer.
Čítajte pole označené ako identita FQDN ako doslovný reťazec, nie ako žiadosť o reverzné DNS meno vašej verejnej adresy. V parseri strongSwan je to presne to, reťazec, a jeho čítanie ho nikdy nepreloží na koncový bod. Už tento fakt odstraňuje najčastejšie rozptýlenie pri výbere identifikátorov pre peer. Nižšie uvedené kontroly bránia tomu, aby sa tri zúčastnené hodnoty zliali do jednej.
Označenie nie je vyhľadávanie
Rozhrania výrobcov používajú slová ako FQDN a hostname voľne a označenie na krabici nič nehovorí o kódovaní za ním. Zariadenie, ktoré pole nazýva Client FQDN, môže poslať FQDN, reťazec v tvare e-mailu alebo holú adresu. Berte text a typ ako dve samostatné rozhodnutia a zaznamenajte obe.
Nič v doslovnej identite nevyžaduje DNS. Je to tvrdenie, ktoré kontroluje druhá strana, nie meno, ktoré musí sieť preložiť.
Tri oddelené hodnoty, oddelene zapísané
Za jednou konfiguračnou obrazovkou stoja tri úlohy a ich zlúčenie je drahá chyba. Jedna hodnota je adresa koncového bodu, ktorá rozhoduje, kam pakety idú. Ďalšia je lokálna identita, ktorú tento peer predkladá, a tretia je identita, ktorú očakávate od vzdialenej strany, kým ju overíte. Zapíšte ich ako tri riadky do tiketu zmeny, pretože čokoľvek menej opisuje VPN a nie vzťah.
| 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 |
Príkladové identity treba vybrať a autorizovať ako súčasť nasadenia. Sú to tvrdenia, ktoré overovanie kontroluje, nie prihlasovacie údaje, ktoré by urobili ktorýkoľvek peer dôveryhodným, takže vierohodne vyzerajúci reťazec nič neautorizuje.
Typ je súčasťou hodnoty
referencia identít strongSwan oddeľuje FQDN, hodnoty v tvare e-mailu, IP adresy a iné kódovania, takže kódovanie záleží rovnako ako znaky. Dve zariadenia môžu prijať rovnaký text pod rôznymi typmi a napriek tomu sa navzájom odmietnuť. Poznámka, ktorá zaznamená hodnotu bez jej typu, je polovica konfigurácie.
Opýtajte sa výrobcu, aký typ zariadenie skutočne posiela, a potvrďte to dekódovaním, nie označením rozhrania. Uhádnutý typ je nezhoda čakajúca na ďalšiu zmenu.
Každá strana musí uspokojiť tú druhú
Lokálna identita každej strany musí prejsť politikou overovania druhej strany. To nie je to isté ako vložiť jeden reťazec do každého poľa identity na oboch zariadeniach, čo je skratka, ktorá vytvorí konfiguráciu, ktorú nikto nedokáže ladiť.
Overovanie certifikátom pridáva vlastné požiadavky, pretože identita certifikátu a podmienky dôvery stoja vedľa vami zadanej identity IKE. Samotná zhoda identity IKE neautorizuje peer s certifikátom.
Kde záleží na DNS a čo vynucuje vaša verzia
Názov hostiteľa brány používaný na zisťovanie naozaj potrebuje fungujúce DNS a táto požiadavka patrí k hľadaniu koncového bodu, nie k nejakému reverznému vyhľadávaniu zadanej identity. V tikete ich držte oddelene, pretože zlyhanie zisťovania a nezhoda identity sa v klientskom logu čítajú podobne a opravujú sa na rôznych miestach.
Prečítajte si parser produktu a verzie, ktorú skutočne prevádzkujete, skôr než skopírujete syntax, ktorá vynucuje typ, pretože staršie vydania strongSwan sa správali inak a iní výrobcovia pridávajú vlastné obmedzenia. Keď porovnávate oba konce, držte spolu štyri veci: očakávanú identitu, predloženú identitu, typ a chybu overenia. Táto sada mení nezhodu na dôkaz namiesto názoru.