Az IPsec-házirend elnyeli a helyi forgalmat: hogyan ismerhető fel

Az asztalon álló nyomtató abban a pillanatban abbahagyja a válaszadást, amikor az alagút felépül, és semmi sem említi a nyomtatót az alagút konfigurációjában. Általában az történt, hogy egy védett tartományt elég szélesre írtak ahhoz, hogy magába foglalja, így a gép most olyan forgalmat próbál titkosítani, amelynek a helyi szegmensen kellett volna maradnia. A telepített házirend elolvasása megmagyarázza az elfogást; a megfelelő helyen történő szűkítése védve tartja a távoli forgalmat. Az út a sikertelen kéréstől az illeszkedő házirendig néhány percet vesz igénybe.

Kövesse végig a folyamatot, mielőtt módosít egy szelektort

Kezdje a sikertelen kérésnél, és írjon fel négy értéket: a forrás címet, amelyet a gép használ, a pontos célt, az útvonalat, amelyet a kernel választ, és a házirendet, amely ehhez a párhoz illeszkedik.

Ez a négy tény dönti el, hogy az elfogás szándékos-e vagy véletlen. Egy cél, amely a távoli szelektoron belülre esik, tervezés szerint védett, még akkor is, ha a terv hibás volt. Egy azon kívüli cél, amelyet mégis elfognak, azt jelenti, hogy valami más illeszkedik, és a szelektor módosítása nem segít. Mindkét eset gyakori, és egyetlen parancs különbözteti meg őket.

Tegye ezt még azelőtt, hogy bármit szerkesztene, mert az érdekes eset a helyi alhálózat, amely átfedésben van a kapcsolat által védett privát tartománnyal. Az ismerős előtagok, például a 192.168.0.0/16 sok hálózatban előfordulnak, és az egyikükre írt szelektor csendesen lefedheti az önét.

Háromféle helyi, amelyek eltérően viselkednek

Az ehhez a hoszthoz rendelt cél, az ugyanazon a linken lévő cél és egy másik interfész mögötti cél három különböző eset. A kernel mindegyiket másként kezeli, amikor eldönti, hogy a forgalomnak szüksége van-e védelemre.

Az átjáró által generált forgalom sem ugyanaz, mint az ügyféltől továbbított forgalom. Egy házirend, amely helyesnek tűnik a továbbított forgalomhoz, elfoghatja az átjáró saját felügyeleti munkamenetét, és így a rendszergazda elveszíti a hozzáférést, miközben az alagutat javítja.

A hasznos szokás, hogy hangosan megnevezze az esetet: ez a csomag tőlem jön, a linkemre megy, vagy rajtam halad át? Minden válasz más helyre mutat, ahol szűkíteni lehet. Az eset leírása azt is megakadályozza, hogy a következő ember újra elvégezze ugyanezt a munkát.

Amikor a védett tartomány egy teljes privát tér, mindhárom eset egyszerre beleeshet, és a tünet egy olyan gép lesz, amely semmit sem ér el az alagút végpontján kívül.

A telepített házirendet olvassa, ne a fájlt

A konfigurációs fájlok a szándékot írják le; a kernel azokat a házirendeket tartja, amelyek ténylegesen illeszkednek. Mutassa meg mindkettőt, és az eltérést tekintse első leletnek.

Ezek a parancsok mutatják a célhoz választott útvonalat és a telepített házirendeket mindkét irányban:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Az útvonal megmondja, melyik interfészt használná a csomag. A házirendek listája megmondja, hogy ezután alkalmaznak-e sablont erre a csomagra, a kapcsolatok listája pedig megmutatja, mely szelektorokat hiszi a démon telepítettnek. Ha a cél megjelenik egy távoli szelektorban, megtalálta az elfogást találgatás nélkül.

Szűkítse a szelektort, vagy kerülje meg a célt

Két támogatott javítás létezik, és különböző kérdésekre válaszolnak. A szelektor szűkítése azt mondja, hogy ez a kapcsolat csak kisebb tartományt véd, ami helyes, ha a szélesebb tartomány hiba volt. Egy megkerülés hozzáadása azt mondja, hogy ezt a konkrét célt soha nem szabad védeni, ami helyes, ha a védett tartomány valóban széles, és egy cél a kivétel.

Válassza az elsőt, amikor lehet, mert egy kisebb szelektort könnyebb átgondolni, és látszik a kapcsolat definíciójában. Válassza a másodikat, amikor a széles tartomány szándékos, és a kivétel egyetlen hoszt vagy alhálózat, amelyet meg tud nevezni.

Mindkettő ahhoz a konfigurációhoz tartozik, amely a kapcsolatot birtokolja. A kézzel hozzáadott futásidejű szabály eltűnik a következő újracsatlakozáskor, és a hiba abban a pillanatban tér vissza, amikor már senki nem emlékszik a kerülőútra.

Újratelepítést túlélő kivételek

A módosítás után ismételje meg ugyanazt az ártalmatlan kérést, és nézze ugyanazokat a számlálókat. A helyi célnak válaszolnia kellene, a szándékolt távoli célnak pedig továbbra is titkosított forgalmat kellene mutatnia.

Ez a két ellenőrzés megerősíti, hogy a kivétel túlélte, a védelem pedig nem:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Ezután szándékosan bontsa meg és csatlakoztassa újra az alagutat, és ismételje meg mindkettőt. Az a kivétel, amely az újracsatlakozás előtt működik és utána nem, rossz rétegre került, és ez a leggyakoribb módja annak, hogy ez a probléma visszatér.