ASA DHCP relay site-to-site VPN fölött: lépésről lépésre

A relay három szakaszban működik, és csak a középső halad át a VPN-en. Az ügyfél broadcastot küld a fiók szegmensén, az ASA ezt unicast kéréssé alakítja a DHCP-kiszolgáló felé, a kiszolgáló pedig a relay címére válaszol, nem az ügyfélre. Járja végig a szakaszokat ebben a sorrendben, és a «a relay elromlott» esetek többsége hiányzó szabályzatra vagy félreolvasott setroute sorra vezethető vissza.

Első szakasz: engedélyezze a relayt az ügyfél felé néző interfészen

A fiók ASA-ján a relay annak az interfésznek a tulajdonsága, amely az ügyfelek felé néz. A kiszolgáló globálisan deklarálható az elérhető interfészével, vagy ez alatt az ügyfél felé néző interfész alatt, hogy az útválasztási tábla válassza ki a kimenetet. Ez a két forma nem felcserélhető, és a rossz másolása az első hely, ahol egy útmutató félresiklik.

Változtatás előtt ellenőrizze a futó konfigurációt: melyik interfészen van engedélyezve a relay, melyik kiszolgálóforma van jelen, és hogy a setroute az ügyfélinterfészhez kapcsolódik-e. Ha az ASA egy másik szegmenshez DHCP-kiszolgálót is futtat, álljon meg, és olvassa el a korlátozások listáját; kiszolgáló és relay nem engedélyezhető egyszerre ugyanazon a gépen.

A relay a saját ügyfél felé néző címét teszi az átjárócím mezőbe. Erre a címre fog a kiszolgáló válaszolni, ezért a távoli helyről az alagúton át elérhetőnek kell lennie, nem csak helyben.

Második szakasz: vigye át az ASA által generált forgalmat az alagúton

Ez az a lépés, amelyet az emberek kihagynak. A szabályzatalapú site-to-site VPN általában az alhálózatok közötti forgalomra épül, a relay kérést pedig maga az ASA állítja elő. Ha az alagút hozzáférési listája és a crypto map csak a fiók-gazdagéptől a kiszolgáló alhálózata felé menő folyamokra illeszkedik, a relay csomag soha nem is kerülhet be az alagútba. Ellenőrizze a hozzáférési listát mindkét irányban, ne csak a fióktól a kiszolgáló felé menő sort.

Erősítse meg, hogy az érdekes forgalom lefedi az ASA relay-forrását és a kiszolgáló címét, és hogy a visszirány is engedélyezett. VTI-alapú kialakításnál az útválasztási döntés egyszerűbb, de a VTI fölötti relay-támogatás egy adott kiadásban érkezett; az ASA DHCP-útmutatója a 9.14(1) kiadást jelöli meg, ezért ellenőrizze az image-et, mielőtt VTI-példát másol egy régebbi eszközre.

Az ASA és a kiszolgáló közötti ping önmagában keveset bizonyít. Sikerülhet más útvonalon, más forráscímmel, vagy olyan szabályzat alatt, amelynek a relay csomagjai nem felelnek meg.

Harmadik szakasz: olvassa el a választ és a setroute opciót

Az RFC 2131 szerint a kiszolgáló a válaszát a giaddr mezőben lévő címre küldi, ha az a mező nem nulla. Tehát a visszaútnak a relay címére kell irányulnia, és az alagút-szabályzatnak engedélyeznie kell a kiszolgálótól a relay felé mutató irányt. Ha a kérés átjutott, de az ajánlat soha nem érkezik meg, itt érdemes keresni.

Ezután válasszon szét két hasonlóan hangzó dolgot. A setroute kulcsszó megváltoztatja vagy hozzáadja az alapértelmezett útválasztó opciót, amelyet az ASA az ügyfélnek ad. Nem telepít útvonalat az ASA-ra, és nem hoz létre VPN-szabályzatot. Az az ügyfél, amely címet kap, de semmit nem ér el, gyakran setroute vagy hatókör-problémával küzd, nem alagútproblémával. Tesztelje statikus átjáró nélküli ügyféllel, és figyelje, melyik alapértelmezett útválasztó jelenik meg az ajánlatban.

Olvassa el az ajánlatot elsőtől utolsóig: felajánlott cím, maszk, alapértelmezett útválasztó, DNS és bérleti idő. Ezután hagyja megújulni a bérletet. Az a relay, amely egyszer működik, és megújításkor elbukik, általában hatókör-, bérleti vagy visszaút-problémával küzd, amelyet az első csere elrejtett.

Mit ellenőrzök, mielőtt javítottnak nyilvánítom

Kezdje az ügyfélnél, és rögzítse a broadcastot, majd erősítse meg, hogy az ASA a saját címével továbbította giaddr-ként. A távoli oldalon erősítse meg, hogy a kiszolgáló látta a kérést, és a fiókhoz illő hatókört választott. Visszatérve a fiókba erősítse meg, hogy az ügyfél elfogadta az ajánlatot, és eléri az átjáróját.

Ha bármelyik szakasz néma, ellenőrizze a megfelelő szabályzatot vagy útvonalat, ahelyett hogy újabb relay-utasítást adna hozzá. A relay konfigurációja általában már helyes, mire valaki eszkalálja az esetet; az alagút-szabályzat vagy a visszaút az, ami megváltozott.

Írja be a három szakaszt a változásnyilvántartásba: ügyfél felé néző interfész, a relay-forgalmat lefedő VPN-szabályzat és a kiszolgáló visszaútja a giaddr címre. Ez a nyilvántartás teszi a következő fióképítést megismételhető munkává hibakeresési ülés helyett. Azt is megmondja a következő mérnöknek, melyik parancskimenetet gyűjtse be először.