Öt cím-szerep egy IPsec-profilban, és melyik a hibás

Egy tipikus kapcsolatdefinícióban öt különböző feladat kap címet, és ezeknek nem kell egyezniük egymással. A rendszergazdák elakadnak, mert egy ésszerű ösztön, hogy minden mező ugyanarra a gazdagépre mutasson, legalább három esetükben hibás. A kiút az, hogy először megnevezzük a tünetet, majd megnézzük azt az egy vagy két mezőt, amely okozhatja.

Az öt feladat, fontossági sorrendben

A szállítási végpont az a hely, ahová az IKE-csere eljut. A hitelesített azonosság az a név, amelyet mindkét fél bizonyít, és azt házirendhez mérik, nem útválasztási táblához. A védett alhálózatok azok a szelektorok, amelyek eldöntik, melyik belső forgalom tartozik az alagútba. Ezután ott van a forrás, amelyet akkor használnak, amikor maga az átjáró kezdeményez beszélgetést, végül pedig az alsó réteg következő ugrása a partner eléréséhez.

A left és right típusú résztvevő-címkék egy kapcsolat két oldalának konvenciói, nem a helyi és a távoli szinonimái. Olvassa el a ténylegesen telepített megvalósítás kézikönyvét, mielőtt feltételezi, hogy egy kulcs azt jelenti, amit egy másik termék értett alatta.

Első döntés: semmi sem jön létre

Amikor a naplókban egyáltalán nem jelenik meg csere, a végpont az első gyanúsított: rossz cím, szűrt útvonal vagy olyan interfész, amelyen a démon nem figyel. Csak akkor lépjen tovább az azonosságmezőkre, ha a kézfogás látható, mert az azonosságot a cserén belül ítélik meg, nem előtte. A szűrt útvonal és a rossz cím a kliens felől azonosnak látszik, ezért a figyelő oldalt ellenőrizze, mielőtt bármit szerkesztene. Erősítse meg, hogy a démon a várt interfészhez van kötve, mert az egy címen figyelő szolgáltatás pontosan úgy néz ki, mint egy blokkolt útvonal.

A fordításon keresztül megfigyelt nyilvános cím nem ugyanaz, mint az azonosság, amelyet a partner bizonyít. Egy cím megváltoztatása, hogy megfeleljen annak, amit a csomagrögzítés a távoli végén mutat, gyakori és hibás javítás.

Második döntés: az alagút áll, és a forgalom meghal

A szelektorok döntik el, mi kerül az alagútba, és az itteni eltérés olyan kapcsolatot eredményez, amely sikeresen tárgyal, miközben az alkalmazás továbbra is meghiúsul. A távoli félnek a védett tartományát saját távoli tartományaként kell megneveznie, és pontosan ott lopódznak be a fordított értékek.

Szerkesztés előtt olvassa el a két konfigurációt egymás mellett. Az egyik gazdagép helyi tartománya a másik távoli tartománya, és egyetlen felcserélt pár megmagyaráz egy alagutat, amely semmit sem visz át. Szűkítse a párt, mielőtt a kulcsokhoz nyúl: egy alhálózat az alagúton belül és egy kívül megmondja, hogy a szelektor vagy az útválasztás a hibás.

Harmadik döntés: csak az átjáró saját forgalma hiúsul meg

Az ügyfelek számára továbbított forgalom tökéletesen működhet, miközben az átjáró által indított kérés meghiúsul, mert annak a folyamnak nincs örökölhető ügyfélforrása. Az előnyben részesített forrás beállítása pontosan erre az esetre létezik, és ez nem forrásfordítás: forráscímet választ ahelyett, hogy átírna egyet.

Egy másik címet kifejezetten hozzákötő alkalmazás felülbírálhatja a preferenciát, ezért erősítse meg a csomag tényleges forrását, mielőtt arra jutna, hogy a beállítást figyelmen kívül hagyják. Az átjáró saját interfészén rögzítsen, ahelyett hogy a konfiguráció szándékában bízna.

A következő ugrás helyi utasítás

Az alsó réteg következő ugrása megmondja ennek a gazdagépnek, hogyan érje el a partnert, és a távoli félnek nincs szüksége ugyanarra az értékre. Megosztott beállításként kezelni, vagy egy alapértelmezett átjárót fixen kódolni abban a pillanatban törik el, amikor az útvonal megváltozik vagy egy második út megjelenik.

Néhány megvalósítás itt különleges értékeket kínál. Amit a kézikönyv a telepített verzióhoz felsorol, az az egyetlen biztonságos válasz, és a helyi útválasztási tábla a bizonyíték arra, hogy működött. Amikor egy partner név szerint elérhető, de cím szerint nem, az az eltérés a lelet, nem pedig kikerülendő részlet.

Olvassa a profilt mindkét végéről

A szerepek papíron való megfordítása a leggyorsabb átvizsgálás: cserélje fel a védett tartományokat, tartsa meg mindkét fél saját következő ugrását és saját azonosságát. Ami nem éli túl a cserét, az valószínűleg a rossz feladathoz van rendelve.

Ezután szerepenként egy folyamot teszteljen: partnerek közötti elérhetőség, belső ügyfélfolyam és az átjáróról induló kérés. Három teszt megmondja, melyik feladat van rosszul hozzárendelve, anélkül hogy újra megnyitná a konfigurációt. Adja hozzá az eredményt a jegyhez a módosított mező mellé, mert a következő mérnök ugyanezzel a profillal találkozik.