Relay funguje v troch fázach a len prostredná prechádza cez VPN. Klient vysiela broadcast v segmente pobočky, ASA z neho urobí unicast požiadavku na DHCP server a server odpovedá na adresu relayu, nie na adresu klienta. Prejdite fázy v tomto poradí a väčšina prípadov „relay je pokazený“ sa vyrieši chýbajúcou politikou alebo nesprávne prečítaným riadkom setroute.

Prvá fáza: zapnite relay na rozhraní obrátenom ku klientom

Na ASA v pobočke je relay vlastnosťou rozhrania, ktoré smeruje ku klientom. Server možno deklarovať globálne s jeho dostupným rozhraním, alebo pod týmto klientskym rozhraním, aby smerovacia tabuľka vybrala výstup. Tieto dve formy nie sú zameniteľné a kopírovanie tej nesprávnej je prvé miesto, kde sa sprievodca zvrtne.

Pred akoukoľvek zmenou skontrolujte bežiacu konfiguráciu: ktoré rozhranie má relay zapnutý, ktorá forma servera je prítomná a či je setroute pripojený ku klientskemu rozhraniu. Ak ASA prevádzkuje aj DHCP server pre iný segment, zastavte sa a prečítajte zoznam obmedzení; server a relay nemožno zapnúť súčasne na tom istom zariadení.

Relay vkladá svoju vlastnú klientsku adresu do poľa adresy brány. Práve na túto adresu bude server odpovedať, takže musí byť dostupná zo vzdialeného webu cez tunel, nielen lokálne.

Druhá fáza: preneste prevádzku generovanú ASA tunelom

Toto je krok, ktorý ľudia preskakujú. VPN typu site-to-site založená na politikách sa zvyčajne stavia pre prevádzku medzi podsieťami a relay požiadavku generuje samotná ASA. Ak access list tunela a crypto mapa zodpovedajú len tokom z hostiteľa v pobočke do podsiete servera, relay paket sa do tunela nemusí vôbec dostať. Skontrolujte access list v oboch smeroch, nielen riadok z pobočky na server.

Overte, že zaujímavá prevádzka pokrýva zdroj relayu na ASA aj adresu servera a že je povolený aj spätný smer. Pri návrhu založenom na VTI je smerovacie rozhodnutie jednoduchšie, ale podpora relayu cez VTI prišla v konkrétnom vydaní; sprievodca DHCP na ASA uvádza 9.14(1), takže pred kopírovaním príkladu VTI na staršie zariadenie skontrolujte image.

Ping z ASA na server sám o sebe veľa nedokazuje. Môže uspieť inou cestou, s inou zdrojovou adresou alebo pod politikou, ktorej pakety relayu nezodpovedajú.

Tretia fáza: prečítajte odpoveď a voľbu setroute

RFC 2131 hovorí, že server posiela odpoveď na adresu v giaddr, keď to pole nie je nulové. Preto spätná cesta musí smerovať na adresu relayu a tunelová politika musí povoliť smer zo servera na relay. Ak požiadavka prešla, ale ponuka nikdy nedorazí, hľadajte tu.

Potom oddeľte dve veci, ktoré znejú podobne. Kľúčové slovo setroute mení alebo pridáva voľbu predvolenej brány, ktorú ASA odovzdáva klientovi. Neinštaluje trasu na ASA a nevytvára VPN politiku. Klient, ktorý dostane adresu, ale na nič sa nedostane, má často problém s setroute alebo s rozsahom, nie s tunelom. Otestujte to klientom bez statickej brány a sledujte, ktorá predvolená brána sa v ponuke objaví.

Prečítajte ponuku od začiatku do konca: ponúkaná adresa, maska, predvolená brána, DNS a čas prenájmu. Potom nechajte prenájom obnoviť. Relay, ktorý raz funguje a pri obnove zlyhá, má zvyčajne problém s rozsahom, prenájmom alebo spätnou cestou, ktorý prvá výmena skryla.

Čo kontrolujem, než to vyhlásim za opravené

Začnite pri klientovi a zachyťte broadcast, potom overte, že ho ASA preposlala so svojou vlastnou adresou ako giaddr. Na vzdialenej strane overte, že server videl túto požiadavku a vybral rozsah, ktorý zodpovedá pobočke. Späť v pobočke overte, že klient ponuku prijal a dosiahne svoju bránu.

Ak je niektorá fáza tichá, skontrolujte zodpovedajúcu politiku alebo trasu, namiesto pridania ďalšieho relay príkazu. Konfigurácia relayu býva v čase eskalácie už správna; zmenila sa tunelová politika alebo spätná trasa.

Zapíšte tri fázy do záznamu o zmenách: klientske rozhranie, VPN politika pokrývajúca relay prevádzku a spätná trasa servera na giaddr. Práve tento záznam robí z ďalšej stavby pobočky opakovateľnú prácu namiesto ladiacej session. Tiež hovorí ďalšiemu inženýrovi, ktorý výstup príkazu zbierať ako prvý.

Súvisiace články