DHCP relay na ASA přes VPN typu site-to-site: praktický průvodce

Relay funguje ve třech fázích a jen prostřední překračuje VPN. Klient vyšle broadcast v segmentu pobočky, ASA z něj udělá unicast požadavek na DHCP server a server odpovídá na adresu relaye, ne na adresu klienta. Projděte fáze v tomto pořadí a většina případů „relay je rozbitý“ se vyřeší chybějící politikou nebo špatně přečteným řádkem setroute.

První fáze: zapněte relay na rozhraní obráceném ke klientům

Na ASA v pobočce je relay vlastností rozhraní, které směřuje ke klientům. Server lze deklarovat globálně s jeho dostupným rozhraním, nebo pod tímto klientským rozhraním, aby směrovací tabulka vybrala výstup. Tyto dvě formy nejsou zaměnitelné a kopírování té špatné je první místo, kde se průvodce zvrtne.

Před jakoukoli změnou zkontrolujte běžící konfiguraci: které rozhraní má relay zapnutý, která forma serveru je přítomna a zda je setroute připojen ke klientskému rozhraní. Pokud ASA provozuje i DHCP server pro jiný segment, zastavte se a přečtěte seznam omezení; server a relay nelze zapnout současně na stejném zařízení.

Relay vkládá svou vlastní klientskou adresu do pole adresy brány. Právě na tuto adresu bude server odpovídat, takže musí být dostupná ze vzdáleného webu přes tunel, ne jen lokálně.

Druhá fáze: přeneste provoz generovaný ASA tunelem

Tohle je krok, který lidé přeskakují. VPN typu site-to-site založená na politikách se obvykle staví pro provoz mezi podsítěmi a relay požadavek generuje sama ASA. Pokud access list tunelu a crypto mapa odpovídají jen tokům z hostitele v pobočce do podsítě serveru, relay paket se do tunelu nemusí vůbec dostat. Zkontrolujte access list v obou směrech, ne jen řádek z pobočky na server.

Ověřte, že zajímavý provoz pokrývá zdroj relaye na ASA i adresu serveru a že je povolen i zpětný směr. U návrhu založeného na VTI je směrovací rozhodnutí jednodušší, ale podpora relaye přes VTI přišla v konkrétním vydání; průvodce DHCP na ASA uvádí 9.14(1), takže před kopírováním příkladu VTI na starší zařízení zkontrolujte image.

Ping z ASA na server sám o sobě mnoho nedokazuje. Může uspět jinou cestou, s jinou zdrojovou adresou nebo pod politikou, které pakety relaye neodpovídají.

Třetí fáze: přečtěte odpověď a volbu setroute

RFC 2131 říká, že server posílá odpověď na adresu v giaddr, když toto pole není nulové. Proto zpětná cesta musí směrovat na adresu relaye a tunelová politika musí povolit směr ze serveru na relay. Pokud požadavek prošel, ale nabídka nikdy nedorazí, hledejte tady.

Pak oddělte dvě věci, které znějí podobně. Klíčové slovo setroute mění nebo přidává volbu výchozí brány, kterou ASA předává klientovi. Neinstaluje trasu na ASA a nevytváří VPN politiku. Klient, který dostane adresu, ale na nic se nedostane, má často problém s setroute nebo s rozsahem, ne s tunelem. Otestujte to klientem bez statické brány a sledujte, která výchozí brána se v nabídce objeví.

Přečtěte nabídku od začátku do konce: nabízená adresa, maska, výchozí brána, DNS a doba pronájmu. Pak nechte pronájem obnovit. Relay, který jednou funguje a při obnově selže, má obvykle problém s rozsahem, pronájmem nebo zpětnou cestou, který první výměna skryla.

Co kontroluji, než to prohlásím za opravené

Začněte u klienta a zachyťte broadcast, pak ověřte, že jej ASA přeposlal se svou vlastní adresou jako giaddr. Na vzdálené straně ověřte, že server tento požadavek viděl a vybral rozsah odpovídající pobočce. Zpět v pobočce ověřte, že klient nabídku přijal a dosáhne na svou bránu.

Pokud je některá fáze tichá, zkontrolujte odpovídající politiku nebo trasu, místo abyste přidávali další relay příkaz. Konfigurace relaye bývá v době eskalace už správná; změnila se tunelová politika nebo zpětná trasa.

Zapište tři fáze do záznamu o změně: klientské rozhraní, VPN politika pokrývající relay provoz a zpětná trasa serveru na giaddr. Právě tento záznam dělá z další stavby pobočky opakovatelnou práci místo ladící session. Také říká dalšímu inženýrovi, který výstup příkazu sbírat první.