IPsec s viacerými podsieťami stráca spätnú prevádzku? Spočítajte reqid

Prevádzka opustí jedno miesto a už sa nikdy nevráti, obe brány hlásia dokončené vyjednávanie a jediným vodítkom je hromada odchádzajúcich paketov bez odpovedí. Na linuxovom koncovom bode nebýva príčinou sila šifrovania, MTU ani smerovacia tabuľka. Je to zrnitosť položiek politiky a číslo, ktoré spája každú politiku s bezpečnostnou asociáciou. Postup nižšie číta tieto dve databázy, skôr než sa čohokoľvek iného dotkne.

Rozdeľte príznak, kým čokoľvek zmeníte

Jednosmerná porucha s dokončeným vyjednávaním IKE zužuje problém na dátovú cestu. Buď politika pre odchádzajúcu prevádzku sedela a odpoveď bola zahodená, alebo odpoveď nikdy nedorazila, lebo druhá strana nemala čím ju poslať. Z pohľadu aplikácie vyzerajú oba prípady rovnako a databázy xfrm ich rozlíšia.

Nezačínajte MTU. Zlé MTU spôsobuje zasekávanie a príznaky fragmentácie, nie čisté rozdelenie smeru s rastúcimi odchádzajúcimi čítačmi.

Prečítajte databázu politík a databázu stavov

V Linuxe o šifrovaní rozhodujú položky politiky, takže zodpovedajúca politika, nie trasa, dostane paket do tunela. Spustite ip xfrm policy a uvidíte selektory, smer, prioritu a šablónu každej položky, a ip xfrm state na zobrazenie zavedených asociácií s ich reqid. Politika a asociácia sú spojené týmto reqid.

Pozrite sa na všetky tri smery. Odchádzajúci a prichádzajúci pokrývajú prevádzku k tomuto hostiteľovi a od neho; smer preposielania je dôležitý, keď hostiteľ smeruje za iných. Chýbajúca alebo odlišná položka v jednom smere vysvetľuje jednosmerný výsledok bez akejkoľvek kryptografickej poruchy.

Klasická asymetria: jeden reqid pre viacero podsietí

Častá porucha pochádza od partnera, ktorý nainštaluje politiky pre všetky vyjednané podsiete pod jediným reqid, čo sa deje s generate_policy require pri racoone. Prevádzka potom odchádza cez asociáciu zavedenú naposledy, kým druhá strana drží samostatnú asociáciu pre každú podsieť. Odpovede prichádzajú na asociáciu, ktorej reqid neoznačuje politiku, ktorá by ich mala prijať, a jadro ich po dešifrovaní zahodí.

Oprava je zmena konfigurácie, nie pravidlo firewallu: generate_policy unique; dá každej politike vlastný reqid, takže asociácie partnera na politiku majú zodpovedajúcich partnerov. Použite to, znovu vyjednajte a spočítajte rôzne reqid pre očakávané podsiete, kým vyhlásite úspech.

Ak dve podsiete stále zdieľajú reqid, kým druhá strana očakáva dve, našli ste asymetriu. Zapíšte mapovanie, pretože je dôkazom, že ich ďalšia zmena opravila alebo zachovala.

Selektory pochádzajú z vyjednávania, nie z vašej konfigurácie

Chránené rozsahy sú to, na čom sa oba konce dohodli, nie to, o čo jedna strana požiadala. Klient ponúkajúci pár hostiteľov proti širokému vzdialenému rozsahu dostane zúženú verziu brány a nemôže ju rozšíriť. Čítajte nainštalované selektory, nie tie vo svojom miestnom súbore.

Keď je cieľom opak, teda udržať jeden cieľ mimo tunela, pridajte politiku obchádzania s nižším číslom priority, aby porazila automaticky nainštalovanú položku. Politika bez šablóny povoľuje otvorený text, čo z nej robí zámernú výnimku pre záznam zmeny, nie krok ladenia.

Overujte v tomto poradí a vedzte, ako sa vrátiť späť

Vypíšte politiky pre každú podsieť v oboch smeroch, vrátane smeru preposielania, ak hostiteľ smeruje. Spočítajte rôzne reqid a potvrďte jeden na politiku na strane, ktorá ho očakáva. Porovnajte nainštalované selektory s vyjednanými. Po obnove kľúča znova prečítajte čítače asociácie, lebo asociácia, ktorú ste skontrolovali, už môže byť preč. Trasy skontrolujte nakoniec, keďže chýbajúca trasa k vzdialenej podsieti dáva podobný jednosmerný príznak s čistými čítačmi politiky.

Kým zmeníte partnera, uložte aktuálny výstup oboch príkazov xfrm. Ak nové nastavenie neobnoví spätný smer, obnovenie tohto výstupu je rýchlejší návrat než znovuvytvorenie tunela z pamäti a udržuje čestné porovnanie.