Check Point VSX VPN: výběr odkazu, nebo neshoda peeru?

Dvě různé změny dávají stejný příznak, když se tunel typu site-to-site v Check Pointu přestane zvedat: peer vidí jinou vnější adresu, nebo odmítá identitu IKE, kterou nyní dostává. Na snímku pořízeném z jedné strany vypadají obě stejně. K rozhodnutí, kterou z nich máte, jsou potřeba tři kontroly a ani jedna z nich není panel výběru odkazu.

Pomýlíte-li pořadí, ladíte výběr zdroje, abyste opravili neshodu identity. Tak se stejný tunel opravuje dvakrát a po další změně trasy se znovu rozbije.

Tři podmínky, které oba případy oddělují

Podmínka první: odpovídá nakonfigurovaný koncový bod peeru adrese, která skutečně dorazí? Pokud pakety přicházejí do vzdálené brány z adresy, kterou peer nespojuje s vaším objektem peeru, vyjednávání selže dřív, než se vymění jakákoli identita. Podmínka druhá: odpovídá identita IKE v návrhu hodnotě, kterou peer očekává? To je autentizace, ne transport. Podmínka třetí: je volba, kterou chcete změnit, podporovaná pro tento virtuální systém v této verzi? Žádné viditelné nastavení na tyto otázky neodpovídá.

Selže-li první podmínka, máte problém se směrováním nebo překladem. Selže-li druhá, máte problém s kontraktem peeru. Je-li třetí neznámá, přestaňte konfigurovat.

Nejdřív si sestavte záznam o vnějším peeru

Než na cokoli sáhnete, zapište virtuální systém, verzi softwaru a nainstalovanou úroveň aktualizací. Pak zaznamenejte vnější rozhraní, trasu ke vzdálenému peeru, očekávané zdrojové adresy před NAT a po NAT a nakonfigurovaný koncový bod vzdáleného peeru.

Vnitřní chráněné prefixy držte v samostatné části tohoto záznamu. Změna vnějšího zdroje a změna chráněné adresy LAN jsou různé operace, které náhodou žijí ve stejné politice.

Ke každému snímku, který si ponecháte, přidejte směr. Vyjednávání iniciované lokálně a odpověď vzdálenému peeru mohou volit odlišně, takže snímek bez označení je slabý důkaz. Označte soubor virtuálním systémem a iniciátorem.

Přečtěte si, co výběr odkazu skutečně odděluje

Průvodce Check Pointu k výběru odkazu v R81.20 odděluje tři věci, které lidé slévají v jednu: jak vzdálený peer překládá adresu brány, která trasa nese odchozí provoz a která zdrojová IP adresa se použije. Každá odpovídá na jinou otázku. Ani jedna z nich nemění identitu, kterou peer autentizuje.

Toto oddělení vysvětluje, proč změna trasy může změnit viditelnou vnější adresu, aniž by se dotkla identity IKE, a proč změna identity může zlomit tunel, jehož směrování je bezchybné.

RFC 7296 kreslí stejnou hranici pro samotné IKE: identifikační datová jednotka není transportní adresa. Výrobci toto rozdělení implementují, nepředefinovávají je.

Rozhodujte podle důkazů, ne podle panelu nastavení

Pokud peer hlásí neznámou nebo neodpovídající identitu, opravte objekt peeru nebo konfiguraci identity, ne výběr zdroje. Pokud peer nic nehlásí a váš snímek ukazuje pakety odcházející z neočekávané adresy, opravte nejdřív směrování nebo překlad. Pokud obojí vypadá správně a tunel stále nefunguje, pořiďte snímek na vzdálené straně a porovnejte, co přijala. Teprve když se adresa i identita shodují a cesta je stále špatná, stává se některá volba výběru odkazu kandidátem.

Než tuto volbu na VSX nakonfigurujete, získejte pokyny k podporovaným funkcím pro příslušnou verzi nebo výslovné prohlášení dodavatele pro kontext virtuálního systému. Starší zpráva o tom, že funkce nebyla dostupná, je historie, ne současný zákaz, a panel nastavení není prohlášení o podpoře.

Slaďte oba konce a záznam si ponechte

Jakmile máte podporovaný návrh, projděte vnější dosažitelnost, konfiguraci koncového bodu peeru a shodu identity společně, jako jeden kontrakt. Pak naplánujte akceptaci pro tři případy: počáteční spojení, spojení iniciované vzdálenou stranou a selhání, které očekáváte při přerušení cesty.

Uložte pozorované vnější adresy vedle kontextu aktivního virtuálního systému. Příští změna trasy se pak porovnává s dokumentovaným kontraktem, a ne s něčí pamětí výchozí hodnoty.