Prečo bezpečnostná politika IPsec nie je položkou smerovacej tabuľky

Pošlite ping na 10.20.0.5 tunelom a nič sa nevráti, zatiaľ čo smerovacia tabuľka tvrdí, že tá podsieti je dostupná. Smerovanie a IPsec odpovedajú na rôzne otázky a iba jedna z nich je o dostupnosti. Dopredné vyhľadanie vyberie cestu, potom databáza bezpečnostnej politiky rozhodne, či tú cestu treba chrániť, nechať tak alebo odmietnuť. Keď sa obe nezhodujú, paket ticho zomrie, preto ich čítajte v tomto poradí.

Začnite vyhľadaním, nie tabuľkou

Opýtajte sa jadra, čo by skutočne urobilo: ip route get 10.20.0.5 vypíše zvolenú trasu, výstupné rozhranie a zdrojovú adresu, ktorú by použilo. Prefix, pravidlo politiky, značka alebo preferovaný zdroj môžu tento výsledok zmeniť, preto je živé vyhľadanie lepšie ako čítanie tabuľky okom.

Testujte cieľ vnútri chráneného rozsahu, nie adresu brány. Dosiahnutie brány na druhej strane dokazuje len to, že nejaká trasa existuje; nič nehovorí o podsieti, ktorú skutočne potrebujete. Potom potvrďte, že rozhranie vybrané vyhľadaním je to, ktoré očakávate, že tunel použije.

Zlaďte selektory na oboch stranách

Databáza politiky má vlastné položky a každá uvádza smer, zdroj, cieľ a protokol, a potom hovorí, čo sa má stať s vyhovujúcimi paketmi. Na výpis použite ip xfrm policy; príznaky ukazujú, či je akcia chrániť, obísť alebo zablokovať. Politika, ktorej selektory sú širšie alebo užšie než váš testovací tok, sa s ním nezhodne a paket odchádza nechránený. To je porucha, ktorú hľadáte, nie chýbajúca trasa.

Porovnajte skutočné hodnoty: zdroj, cieľ, protokol a porty. Ak vyhľadanie vyriešilo jednu dvojicu adries, zatiaľ čo položka politiky pokrýva inú, oba pohľady opisujú inú prevádzku. Spustite obe znova s rovnakým tuplom, kým urobíte záver, inak upravíte politiku, ktorá nikdy nebola na ceste.

Zhoda politiky nie je nainštalovaný stav

Vyhovujúca politika len hovorí, že paket musí byť chránený; jadro stále potrebuje bezpečnostnú asociáciu, aby ochranu vykonalo. Vypíšte ich pomocou ip xfrm state, alebo pomocou swanctl --list-sas, keď rokovania vedie strongSwan, a prečítajte selektory a počítadlá pri každej položke.

Keď politika vyhovuje a žiadna asociácia nepokrýva tie isté selektory, paket sa zahodí namiesto odoslania v otvorenom tvare. To je to zahodenie, ktoré treba hľadať, keď tunel beží, ale jedna podsieti zlyháva. Počítadlá povedia zvyšok: asociácia, ktorá nikdy nerastie, nebola nikdy vybraná, zatiaľ čo tá, ktorá rastie a napriek tomu skončí zahodením, ukazuje na vzdialenú stranu. Oprava selektorov a obnova kľúčov sú rôzne opravy, preto sa rozhodnite, ktorú potrebujete, kým sa dotknete konfigurácie.

Čo tunel založený na trase ešte vyžaduje

Rozhranie XFRM robí z tunela zariadenie, do ktorého možno smerovať, čo je naozaj užitočné. Neodstraňuje však politiku a stav, ktoré rozhodujú, čo sa stane, keď tam paket dorazí. Trasa prispieva ďalším skokom a ničím viac.

Ak zariadenie existuje a trasa doň ukazuje, ale žiadna asociácia nezodpovedá vnútorným selektorom, paket sa zahodí a žiadne množstvo úprav trás nevytvorí kľúče ani selektory. Skontrolujte rozhranie s tým istým zdrojom a cieľom, ktoré ste smerovali, a potom to porovnajte so zoznamom stavov.

Pred akoukoľvek úpravou vyjasnite vlastníctvo

Firewall hostiteľa pridáva tretie rozhodnutie, o ktorom nevie ani jedna z dvoch databáz. Správna trasa plus vyhovujúca politika plus nainštalovaná asociácia môžu stále skončiť zahodeným paketom a aplikácia hlási len vypršanie časového limitu. Potvrďte, že firewall povoľuje chránenú prevádzku, kým obviníte IPsec. Zachytávanie na tunelovom zariadení a na fyzickom rozhraní ukáže, na ktorej strane šifrovania paket zmizol.

Vlastníctvo konfigurácie rozhoduje, či vaša oprava prežije reštart. Jedna komponenta môže inštalovať stav, zatiaľ čo iná spravuje trasy, a ručná úprava druhej sa prepíše pri najbližšom spustení tunela. Zmeňte konfiguráciu vlastníka a potom oba pohľady znova prečítajte; RFC 4301 udržuje obe databázy oddelené, keď musíte to rozdelenie niekomu inému vysvetliť.