Mitme alavõrguga IPsec kaotab tagasiliikluse? Loendage reqid-id

Liiklus lahkub ühest kohast ega tule kunagi tagasi, mõlemad lüüsid teatavad lõpetatud läbirääkimisest ja ainus vihje on hunnik vastusteta väljuvaid pakette. Linuxi lõpp-punktis ei ole tavaline põhjus krüpteerimise tugevus, MTU ega marsruutimistabel. See on poliitikakirjete granulaarsus ja number, mis seob iga poliitika turvaassotsiatsiooniga. Allolev protseduur loeb need kaks andmebaasi enne, kui midagi muud puudutatakse.

Eraldage sümptom enne, kui midagi muudate

Ühesuunaline rike lõpetatud IKE läbirääkimisega kitsendab probleemi andmete teele. Kas väljuv poliitika sobis ja vastus visati ära, või ei jõudnud vastus kunagi kohale, sest teisel poolel polnud millegagi seda saata. Rakenduse seisukohast näevad mõlemad ühesugused välja ja xfrm-andmebaasid eristavad neid.

Ärge alustage MTU-st. Vale MTU tekitab tõrkeid ja fragmenteerumise sümptomeid, mitte puhast suunajaotust kasvavate väljuvate loenduritega.

Lugege poliitika-andmebaasi ja olekuandmebaasi

Linuxis otsustavad krüpteerimise poliitikakirjed, seega sobiv poliitika, mitte marsruut, viib paketi tunnelisse. Käivitage ip xfrm policy, et näha selektoreid, suunda, prioriteeti ja iga kirje mall, ning ip xfrm state, et näha loodud assotsiatsioone nende reqid-idega. Poliitika ja assotsiatsioon on selle reqid-iga seotud.

Vaadake kõiki kolme suunda. Väljuv ja sisenev katavad liiklust selle hosti juurde ja juurest; edastussuund on oluline, kui host marsruudib teiste eest. Ühes suunas puuduv või erinev kirje seletab ühesuunalist tulemust ilma ühegi krüptograafilise veata.

Klassikaline asümmeetria: üks reqid mitme alavõrgu jaoks

Sage rike tuleb partnerilt, kes paigaldab kõigi läbiräägitud alavõrkude poliitikad ühe reqid-i alla, mis juhtub racooni generate_policy require puhul. Liiklus väljub siis viimasena loodud assotsiatsiooni kaudu, samal ajal kui teine pool hoiab iga alavõrgu jaoks eraldi assotsiatsiooni. Vastused saabuvad assotsiatsioonile, mille reqid ei tähista poliitikat, mis peaks need vastu võtma, ja tuum viskab need pärast dekrüpteerimist ära.

Parandus on konfiguratsiooni muudatus, mitte tulemüürireegel: generate_policy unique; annab igale poliitikale oma reqid-i, nii et partneri poliitikapõhistel assotsiatsioonidel on sobivad partnerid. Rakendage see, läbirääkige uuesti ja loendage erinevad reqid-id oodatavate alavõrkude jaoks, enne kui kuulutate edu.

Kui kaks alavõrku jagavad endiselt ühte reqid-i, samal ajal kui teine pool ootab kahte, olete asümmeetria leidnud. Kirjutage vastendus üles, sest see on tõend, et järgmine muudatus selle parandas või säilitas.

Selektorid tulevad läbirääkimisest, mitte teie konfiguratsioonist

Kaitstud vahemikud on see, millega mõlemad otsad nõustusid, mitte see, mida üks pool küsis. Klient, kes pakub hostipaari laia kaugvahemiku vastu, saab lüüsi kitsendatud versiooni ja klient ei saa seda laiendada. Lugege paigaldatud selektoreid, mitte neid oma kohalikus failis.

Kui eesmärk on vastupidine, hoida üks sihtkoht tunnelist väljas, lisage möödasõidupoliitika madalama prioriteedinumbriga, et see võidaks automaatselt paigaldatud kirje üle. Mallita poliitika lubab lihtteksti, mis teeb sellest muudatuse kirje jaoks teadliku erandi, mitte silumissammu.

Kontrollige selles järjekorras ja teadke, kuidas tagasi pöörata

Loetlege poliitikad iga alavõrgu jaoks mõlemas suunas, sealhulgas edastussuund, kui host marsruudib. Loendage erinevad reqid-id ja kinnitage üks poliitika kohta sellel poolel, kes seda ootab. Võrrelge paigaldatud selektoreid läbiräägitud omadega. Pärast võtmeuuendust lugege assotsiatsioonipõhised loendurid uuesti, sest uuritud assotsiatsioon võib juba kadunud olla. Kontrollige marsruute viimasena, sest kaugalavõrgu puuduv marsruut annab sarnase ühesuunalise sümptomi puhaste poliitikaloenduritega.

Enne partneri muutmist salvestage mõlema xfrm-käsu praegune väljund. Kui uus säte ei taasta tagasisuunda, on selle väljundi taastamine kiirem tagasipööramine kui tunnel mälust uuesti üles ehitada, ja see hoiab võrdluse ausana.