Több alhálózatos IPsec nem hozza vissza a forgalmat? Számolja meg a reqid-eket
A több alhálózatos alagúton át egyirányú forgalom általában szabályzat- és reqid-eltérés, nem titkosítási vagy útválasztási hiba. Olvassa sorban az xfrm adatbázisokat.
A forgalom elhagyja az egyik helyszínt és soha nem tér vissza, mindkét átjáró befejezett tárgyalást jelent, és az egyetlen nyom egy rakás válasz nélküli kimenő csomag. Linux végponton a szokásos ok nem a titkosítás erőssége, az MTU vagy egy útválasztási tábla. Hanem a szabályzatbejegyzések granularitása és az a szám, amely minden szabályzatot egy biztonsági társításhoz köt. Az alábbi eljárás ezt a két adatbázist olvassa be, mielőtt bármi máshoz nyúlna.
Válassza szét a tünetet, mielőtt bármit módosít
A befejezett IKE-tárgyalás melletti egyirányú hiba az adatútra szűkíti a problémát. Vagy a kimenő szabályzat illeszkedett, és a válasz el lett dobva, vagy a válasz soha nem érkezett meg, mert a másik oldalnak nem volt mivel elküldenie. Egy alkalmazásból a két eset egyformán néz ki, és az xfrm adatbázisok megkülönböztetik őket.
Ne az MTU-val kezdje. A rossz MTU akadásokat és töredezési tüneteket okoz, nem tiszta irányszétválást növekvő kimenő számlálókkal.
Olvassa be a szabályzat-adatbázist és az állapot-adatbázist
Linuxon a titkosításról szabályzatbejegyzések döntenek, tehát egy illeszkedő szabályzat, nem egy útvonal visz egy csomagot az alagútba. Futtassa a ip xfrm policy parancsot a szelektorok, az irány, a prioritás és a sablon megtekintéséhez, és a ip xfrm state parancsot a létrejött társítások és reqid-jeik megtekintéséhez. A szabályzatot és a társítást ez a reqid kapcsolja össze.
Nézze meg mindhárom irányt. A kimenő és a bejövő a hoszthoz és a hoszttól menő forgalmat fedi; a továbbítási irány akkor számít, amikor a hoszt másoknak irányít. Egy hiányzó vagy eltérő bejegyzés egy irányban magyarázza az egyirányú eredményt minden kriptográfiai hiba nélkül.
A klasszikus aszimmetria: egy reqid több alhálózathoz
Gyakori hiba, amikor a partner az összes tárgyalt alhálózat szabályzatát egyetlen reqid alá telepíti, ami a racoon generate_policy require beállításával fordul elő. A forgalom ekkor az utoljára létrehozott társításon megy ki, míg a másik oldal alhálózatonként külön társítást tart. A válaszok olyan társításon érkeznek, amelynek reqid-je nem jelöli azt a szabályzatot, amelynek fogadnia kellene őket, és a kernel a visszafejtés után eldobja őket.
A javítás konfigurációmódosítás, nem tűzfalszabály: a generate_policy unique; minden szabályzatnak saját reqid-et ad, így a partner szabályzatonkénti társításainak megfelelő partnereik vannak. Alkalmazza, tárgyaljon újra, és számolja meg a különböző reqid-eket a várt alhálózatokhoz, mielőtt sikert hirdet.
Ha két alhálózat még mindig osztozik egy reqid-en, miközben a másik oldal kettőt vár, megtalálta az aszimmetriát. Jegyezze fel a leképezést, mert ez a bizonyíték arra, hogy a következő módosítás kijavította vagy megőrizte.
A szelektorok a tárgyalásból származnak, nem a konfigurációjából
A védett tartományok azok, amelyekben mindkét vég megegyezett, nem az, amit az egyik fél kért. Az az ügyfél, amely hosztpárt ajánl egy széles távoli tartomány ellenében, az átjáró szűkített változatát kapja, és az ügyfél nem szélesítheti ki. A telepített szelektorokat olvassa, ne a helyi fájljában lévőket.
Amikor a cél az ellenkezője, egy célpont alagúton kívül tartása, adjon hozzá egy megkerülő szabályzatot alacsonyabb prioritásszámmal, hogy legyőzze az automatikusan telepített bejegyzést. A sablon nélküli szabályzat sima szöveget engedélyez, ami szándékos kivétellé teszi egy változásjegyzőkönyvhöz, nem pedig hibakeresési lépéssé.
Ebben a sorrendben ellenőrizzen, és tudja, hogyan lépjen vissza
Listázza a szabályzatokat minden alhálózathoz mindkét irányban, beleértve a továbbítási irányt, ha a hoszt irányít. Számolja meg a különböző reqid-eket, és erősítse meg szabályzatonként egyet azon az oldalon, amely várja. Hasonlítsa össze a telepített szelektorokat a tárgyaltakkal. Kulcsfrissítés után olvassa újra a társításonkénti számlálókat, mert a vizsgált társítás már eltűnhetett. Az útvonalakat utoljára ellenőrizze, mivel a távoli alhálózat felé hiányzó útvonal hasonló egyirányú tünetet ad tiszta szabályzatszámlálókkal.
Mielőtt módosítja a partnert, mentse a két xfrm parancs jelenlegi kimenetét. Ha az új beállítás nem állítja helyre a visszirányt, ennek a kimenetnek a visszaállítása gyorsabb visszagörgetés, mint az alagút emlékezetből történő újraépítése, és őszintén tartja az összehasonlítást.