Příchozí IPsec protějšek neodpovídá žádnému profilu? Zkontrolujte čtyři pole

Váš protějšek hlásí, že tunel je nahoře, vaše strana neukazuje žádnou bezpečnostní asociaci a konfigurační soubor zjevně obsahuje odpovídající název připojení. Všechna tři tvrzení mohou být současně pravdivá. Příchozí vyjednávání se porovnává s běžící konfigurací podle adresy protějšku, identity, kterou předkládá, a provozu, který navrhuje. Soubor na disku, který nebyl nikdy načten, identita, která neodpovídá očekávané hodnotě, nebo pár selektorů posunutý o jeden prefix — každé z toho vytváří ticho. Projděte čtyři skupiny polí v pořadí, v jakém postupuje responder.

Začněte paketem, ne souborem

Responder obdrží požadavek IKE, hledá definici, která může tohoto protějšku přijmout, a poté pokračuje ověřením a výběrem provozu. Pokud v prvním kroku neodpovídá žádná načtená definice, vyjednávání skončí dřív, než se k uživateli dostane jakákoli užitečná chyba.

Proto „konfigurace vypadá správně“ není důkaz. Otázkou je, co běžící služba načetla a který záznam pro tento pokus vybrala. Výpis stavu na to odpovídá jediným příkazem, zatímco buffer editoru odpovídá na jinou otázku. Zkontrolujte výpis, než soubor znovu změníte.

První skupina polí: definice, která je skutečně načtená

Zkontrolujte běžící stav nástrojem, který vlastní démon: příkazem stavu vypisujícím načtená připojení, ne bufferem editoru. Ověřte, že očekávaný záznam existuje, je povolen pro zamýšlené chování při startu a byl načten po vaší poslední úpravě. Uložit soubor bez opětovného načtení je nejčastější příčinou věty „opravil jsem to a nic se nezměnilo“.

Ověřte také, který soubor služba čte. Distribuce se liší a připojení zapsané do špatného includu se tiše ignoruje, místo aby bylo odmítnuto. Pokud výpis stavu váš záznam vůbec nezobrazuje, podezírejte cestu includu dřív než syntaxi.

Druhá skupina polí: koncové body nejsou identity

Adresa, ze které se protějšek připojuje, a identita, kterou se ověřuje, jsou oddělená pole. Název hostitele, rozlišující jméno, identifikátor klíče i adresa mohou sloužit jako identita IKE podle konfigurace a vůbec nemusí vypadat jako veřejná adresa.

Párování koncových bodů může zahrnovat i pohled NAT: adresa viděná v síti se může lišit od adresy, o níž si protějšek myslí, že ji má. V modelu připojení libreswan jsou left a right označení dvou účastníků, nikoli pevné pořadí lokálního a vzdáleného, a proto kopírování funkční konfigurace z jiného pracoviště se záměnou adres není spolehlivý překlad.

Zapište očekávanou identitu obou stran a pověření, které ji ověřuje. Pokud se tyto dva řádky neshodují, sebevětší ladění adres shodu nepřinese.

Třetí skupina polí: provoz, který je chráněn

Selektory popisují vnitřní rozsahy zdroje a cíle, jejich adresní rodinu a jakékoli omezení protokolu či portu. Návrh pro adresu jednoho hostitele není stejný požadavek jako pro celou podsíť a responder nakonfigurovaný pro podsíť jej může odmítnout nebo zúžit.

Když se oba konce neshodují, porovnejte zamýšlený tok z obou pohledů, místo abyste rozšiřovali každý selektor, aby se něco spojilo. Zeptejte se každého správce na tok, o kterém si myslí, že ho chrání, a pak obě odpovědi porovnejte. Nesoulad je obvykle prefix hostitele na jedné straně a podsíť na druhé. Tunel, který odpovídá proto, že teď chrání všechno, je jiné bezpečnostní rozhodnutí a takové, které nikdo neschválil.

Čtvrtá skupina polí: čtete jednu implementaci

Libreswan, starší Openswan a strongSwan mají různé nástroje správy, různou syntaxi konfigurace a různý pořádek párování. Funkční příklad z jednoho neříká nic přesného o prioritě výběru profilu ani o formulaci chyb jiného, proto ověřujte podle dokumentace démona na tomto hostiteli.

Propojte jeden pokus od začátku do konce: zdrojovou adresu iniciátora, nabízenou identitu a navržené selektory — proti zprávě o výběru respondera a načtenému záznamu, který pojmenovává. Nulové počitadla zapouzdření a rozbalení říkají jen, že pozorované asociace tyto pakety nepřenášely; nepojmenovávají koncový bod, který návrh odmítl, ani nedokazují, že v té chvíli existoval odpovídající záznam.

Po koordinované opravě ověřte vybraný profil a asociaci, poté vyzkoušejte skutečně povolenou službu a cestu její odpovědi. Shoda profilu umožňuje vyjednávání a vyjednávání není poslední kontrolou přístupu.