Amikor az IKEv2 TS_UNACCEPTABLE-t ad vissza, hasonlítsa össze a valódi alhálózatokat

A TS_UNACCEPTABLE-t lefedettségi nézeteltérésként olvassa, nem sérült profilként. Az átjáró azt mondja, hogy a két fél nem tudott megegyezni abban, mely címeket hordozhat ez az alagút. Az IKE SA már állhat abban a pillanatban, ezért az ügyfél csatlakozottnak látszhat anélkül, hogy gyermek SA lenne mögötte. Ha így keretezi, a munka mechanikussá válik. Írja fel mindkét fél szándékolt előtagjait, hasonlítsa össze őket egy irányban, és szűkítse, amíg nem metszenek.

Először írja fel a szándékolt párokat

Mielőtt hozzányúl a konfigurációhoz, soroljon fel négy értéket: a kezdeményező forrástartományát, annak céltartományát és ugyanazt a párt a válaszadó szemszögéből. Jegyezze fel mindegyik címcsaládját is. Az IPv4-tartomány és az IPv6-tartomány különböző szelektorfajták, és egyik sem hajtható be a másik hasznos terhelésébe.

Adjon hozzá minden protokoll- vagy portkorlátozást, amelyet a házirend hordoz. A csak TCP 445-öt engedélyező szabály egy fájlszerver felé szűkebb halmazt ír le, mint az alhálózat, amelyben ül. Ha kihagyja a jegyzeteiből, a tárgyalás eredménye következetlennek tűnik olyan okokból, amelyeket nem lát.

Fordítsa meg a címkéket az összehasonlítás előtt

A helyi és a távoli viszonylagos címkék. Az ügyfél helyi előtagja az átjáró távoli tartománya, az átjáró helyi tartománya pedig az ügyfél távoli tartománya. Ezért a két vég képernyőképei soha nem illeszkednek, és szó szerinti összehasonlításuk a délután elvesztegetésének szokásos módja.

A válaszadó szűkítheti az ajánlatot egy elfogadható részhalmazra ahelyett, hogy elutasítaná. Ez az eredmény rosszabb a tiszta kudarcnál, mert félig működik. Kérjen 10.0.0.0/16-ot, amikor a házirend 10.0.5.0/24-et engedélyez, és végül olyan gyermek SA-ja lehet, amely csak azt a /24-et fedi. Egy gazdagép válaszol, minden más kiesik, és semmi nem mondja ezt az ügyfélben. A tárgyalás sikerességének megállapítása előtt a kért helyett az elfogadott szelektorokat olvassa.

Az alapértelmezett útvonalat kérő road warrior profilok folyamatosan itt landolnak. A megosztott hozzáféréshez épített átjáró a teljes tartományú ajánlatot a saját alhálózataira szűkíti, és az ügyfélnek el kell fogadnia a szűkített eredményt, vagy hangosan meg kell buknia.

Egyetlen kísérletből olvassa ki az elutasítást

Gyűjtse össze mindkét naplót ugyanabból a csatlakozási kísérletből. A mentett profil azt mutatja, mit konfigurált, nem azt, mit javasoltak, és a strongSwanon a swanctl --log kiírja a kapott értesítést a hordozott szelektorokkal együtt.

Ezután vizsgálja meg, mi települt valójában. A swanctl --list-sas a gyermek SA szelektorait mutatja, a ip xfrm policy pedig ugyanazokat a tartományokat mutatja kernelházirend-bejegyzésként. Egy gyermek SA abban a listában olyan szelektorokkal, amelyeket nem szándékozott, szűkítési esemény; gyermek SA nélkül, TS_UNACCEPTABLE-lel a naplóban viszont elutasítás.

Amíg ott van, válassza szét a közeli szomszédokat. Az INVALID_SELECTORS egy létrejött gyermek SA-n belüli szelektorra panaszkodik, míg az INTERNAL_ADDRESS_FAILURE azt jelenti, hogy a válaszadó nem tudott virtuális címet kiosztani, ami készletprobléma, nem lefedettségi probléma.

Ellenőrizze, mi csökkenti csendben a halmazt

Három dolog csökkenti a szelektorhalmazt anélkül, hogy bármit mondana. A válaszadó házirendje az első, alhálózati listákon, csoportszabályokon vagy felhasználónkénti engedélyezésen keresztül, amelyek részhalmazra csökkentik az ajánlatot. A címcsalád a második: a kettős veremmel rendelkező ügyfél gyakran IPv6-ot javasol az IPv4 mellett, és elutasítást kap olyan tartományokra, amelyeket az átjáró soha nem konfigurált.

A protokoll- és portkorlátozások a harmadik. Ahol a házirend csak TCP 445-öt engedélyez, a gyermek SA feljöhet, míg az ICMP és az UDP kívül marad, és a felhasználó törött alagutat jelent, pedig egyetlen protokoll volt minden, amit valaha engedélyeztek.

Ezért az önmagukban vett címbővítés nem tud javítani egy portkorlátozott házirendet, és pontosan ez az az eset, amely a legvalószínűbben éli túl változatlanul a három hibaelhárítási kört.

Bizonyítsa a lefedettséget odaillő forgalommal

A gyermek SA telepítése után küldjön egy kérést, amely biztosan az elfogadott tartományokon belülre esik. A számlálókat figyelje az állapotikon helyett: a ip -s xfrm state és a ip xfrm policy mögötti számlálók nőnek, amikor egy csomag illeszkedik és védetté válik. A valódi forgalom után nullán maradó bájtszám azt jelenti, hogy a kernel soha nem választotta azt a házirendet.

Az a nulla útvonalválasztási vagy házirend-sorrendi probléma, nem kriptográfiai probléma. A felhasználó helyéről nézve pontosan úgy néz ki, mint egy szelektor elutasítása, ezért érdemes összegyűjteni a számlálókat, mielőtt újra megnyitja a profilt. A csak egy irányban növekvő számlálók inkább a visszaútra mutatnak.

Fejezze be azzal, hogy az elfogadott párt beírja a jegybe, az eredetileg kért tartomány mellé. Tartsa a kiválasztást olyan szűken, mint a követelmény, mert a hiba törlése egy privát tartománynak az összes címre cserélésével sokkal több hozzáférést ad, mint amit a fiókhoz jóváhagytak.