ASA DHCP relay per site-to-site VPN: žingsnis po žingsnio
Pereikite tris ASA DHCP relay etapus per site-to-site VPN: kliento sąsają, relę perduodamo srauto tunelio politiką ir atsakymą į giaddr.
Relay veikia trimis etapais, ir tik vidurinis kerta VPN. Klientas transliuoja filialo segmente, ASA paverčia tą transliaciją unicast užklausa DHCP serveriui, o serveris atsako į relay adresą, o ne į klientą. Pereikite etapus šia tvarka, ir dauguma atvejų „relay sugedęs“ susiveda į trūkstamą politiką arba neteisingai perskaitytą setroute eilutę.
Pirmas etapas: įjunkite relay kliento pusės sąsajoje
Filialo ASA relay yra sąsajos, nukreiptos į klientus, savybė. Serverį galima deklaruoti globaliai su pasiekiama sąsaja arba po ta kliento pusės sąsaja, kad maršrutų lentelė pasirinktų išėjimą. Šios dvi formos nėra sukeičiamos, o neteisingos kopijavimas yra pirmoji vieta, kur vadovas pakrypsta ne ta linkme.
Prieš ką nors keisdami patikrinkite veikiančią konfigūraciją: kuri sąsaja turi įjungtą relay, kokia serverio forma yra, ir ar setroute prijungtas prie kliento sąsajos. Jei ASA taip pat paleidžia DHCP serverį kitam segmentui, sustokite ir perskaitykite apribojimų sąrašą; serverio ir relay negalima įjungti vienu metu tame pačiame įrenginyje.
Relay įrašo savo kliento pusės adresą į tinklų sietuvos adreso lauką. Būtent į šį adresą serveris atsakys, todėl jis turi būti pasiekiamas iš tolimos vietos per tunelį, ne tik vietoje.
Antras etapas: perkelkite ASA generuojamą srautą per tunelį
Tai žingsnis, kurį žmonės praleidžia. Politika pagrįsta site-to-site VPN paprastai statoma srautui tarp potinklių, o relay užklausą generuoja pati ASA. Jei tunelio prieigos sąrašas ir crypto žemėlapis atitinka tik srautus iš filialo mazgo į serverio potinklį, relay paketas gali niekada nepatekti į tunelį. Patikrinkite prieigos sąrašą abiem kryptimis, ne tik eilutę iš filialo į serverį.
Patvirtinkite, kad dominantis srautas apima ASA relay šaltinį ir serverio adresą, ir kad atgalinė kryptis taip pat leidžiama. VTI pagrįstoje konstrukcijoje maršrutizavimo sprendimas paprastesnis, tačiau relay palaikymas per VTI atsirado konkrečiame leidime; ASA DHCP vadovas nurodo 9.14(1), todėl patikrinkite atvaizdą prieš kopijuodami VTI pavyzdį į senesnį įrenginį.
Ping iš ASA į serverį pats savaime mažai ką įrodo. Jis gali pavykti kitu keliu, su kitu šaltinio adresu arba pagal politiką, kurios relay paketai neatitinka.
Trečias etapas: perskaitykite atsakymą ir setroute parinktį
RFC 2131 teigia, kad serveris siunčia atsakymą į adresą giaddr lauke, kai tas laukas nelygus nuliui. Taigi atgalinis kelias turi būti maršrutizuojamas į relay adresą, o tunelio politika turi leisti kryptį iš serverio į relay. Jei užklausa praėjo, bet pasiūlymas taip ir neatkeliavo, čia ir reikia žiūrėti.
Tada atskirkite du panašiai skambančius dalykus. Raktažodis setroute pakeičia arba prideda numatytojo maršrutizatoriaus parinktį, kurią ASA duoda klientui. Jis neįdiegia maršruto ASA ir nesukuria VPN politikos. Klientas, kuris gauna adresą, bet nieko nepasiekia, dažnai turi setroute arba apimties problemą, o ne tunelio. Išbandykite su klientu be statinės tinklų sietuvos ir stebėkite, kuris numatytasis maršrutizatorius atsiranda pasiūlyme.
Perskaitykite pasiūlymą nuo pradžios iki pabaigos: siūlomas adresas, kaukė, numatytasis maršrutizatorius, DNS ir nuomos laikas. Tada leiskite nuomai atsinaujinti. Relay, kuris kartą veikia, o atnaujinant nepavyksta, paprastai turi apimties, nuomos arba atgalinio kelio problemą, kurią pirmasis apsikeitimas paslėpė.
Ką tikrinu prieš sakydamas, kad sutvarkyta
Pradėkite nuo kliento ir užfiksuokite transliaciją, tada patvirtinkite, kad ASA perdavė ją su savo adresu kaip giaddr. Tolimoje pusėje patvirtinkite, kad serveris matė tą užklausą ir pasirinko filialui tinkamą apimtį. Grįžę į filialą patvirtinkite, kad klientas priėmė pasiūlymą ir pasiekia savo tinklų sietuvą.
Jei kuris nors etapas tyli, patikrinkite atitinkamą politiką arba maršrutą, o ne pridėkite dar vieną relay teiginį. Relay konfigūracija paprastai jau būna teisinga, kai kas nors eskaluoja; pasikeitė tunelio politika arba atgalinis maršrutas.
Įrašykite tris etapus į pakeitimų žurnalą: kliento pusės sąsaja, VPN politika, apimanti relay srautą, ir serverio atgalinis maršrutas į giaddr. Būtent šis įrašas paverčia kito filialo statybą pakartojamu darbu, o ne derinimo sesija. Jis taip pat pasako kitam inžinieriui, kokią komandos išvestį rinkti pirmiau.