ASA DHCP-ripetilo trans lok-al-loka VPN: praktika trairo

La ripetilo funkcias en tri partoj, kaj nur la meza transiras la VPN-on. Kliento dissendas en la branĉa segmento, la ASA ŝanĝas tiun dissendon en unuĉelan peton al la DHCP-servilo, kaj la servilo respondas al la ripetila adreso anstataŭ al la kliento. Trairu la partojn en tiu ordo, kaj plej multaj kazoj de «la ripetilo estas difektita» solviĝas per mankanta politiko aŭ mislegita linio setroute.

Parto unua: ŝaltu la ripetilon sur la klienta interfaco

Sur la ASA de la branĉo ripetilo estas eco de la interfaco rigardanta al la klientoj. La servilo povas esti deklarita tutmonde kun sia atingebla interfaco, aŭ sub tiu klienta interfaco por ke la enkursiga tabelo elektu la eliron. Tiuj du formoj ne estas interŝanĝeblaj, kaj kopii la malĝustan estas la unua loko, kie trairo misvojiĝas.

Kontrolu la kurantan agordon antaŭ ol ŝanĝi ion: kiu interfaco havas la ripetilon ŝaltita, kiu servila formo ĉeestas, kaj ĉu setroute estas ligita al la klienta interfaco. Se la ASA ankaŭ funkciigas DHCP-servilon por alia segmento, haltu kaj legu la limigan liston; servilo kaj ripetilo ne povas esti ŝaltitaj samtempe sur la sama aparato.

La ripetilo metas sian propran klientan adreson en la kampon de porda adreso. Al tiu adreso la servilo respondos, do ĝi devas esti atingebla de la fora loko tra la tunelo, ne nur loke.

Parto dua: portu la trafikon generitan de la ASA tra la tunelo

Ĉi tiu estas la paŝo, kiun homoj preterlasas. Politiko-bazita lok-al-loka VPN kutime estas konstruata por trafiko inter subretoj, kaj la ripetilan peton generas la ASA mem. Se la alirlisto de la tunelo kaj la kriptomapo kongruas nur kun fluoj de branĉa gastiganto al la servila subreto, la ripetila paketo eble neniam eniros la tunelon. Kontrolu la alirliston en ambaŭ direktoj, ne nur la linion de branĉo al servilo.

Konfirmu, ke la interesa trafiko kovras la ripetilan fonton de la ASA kaj la servilan adreson, kaj ke ankaŭ la revena direkto estas permesita. En VTI-bazita dezajno la enkursiga decido estas pli simpla, sed subteno de ripetilo trans VTI venis en specifa eldono; la ASA-gvidilo pri DHCP nomas 9.14(1), do kontrolu la bildon antaŭ ol kopii VTI-ekzemplon al pli malnova aparato.

Ping de la ASA al la servilo mem pruvas malmulte. Ĝi povas sukcesi laŭ alia vojo, kun alia fonta adreso, aŭ sub politiko, kiun la paketoj de la ripetilo ne kongruas.

Parto tria: legu la respondon kaj la opcion setroute

RFC 2131 diras, ke la servilo sendas sian respondon al la adreso en giaddr kiam tiu kampo ne estas nulo. Do la revena vojo devas enkursigi al la ripetila adreso, kaj la tunela politiko devas permesi la direkton de servilo al ripetilo. Se la peto trapasis sed la oferto neniam alvenas, jen kie vi rigardu.

Poste apartigu du aferojn, kiuj sonas simile. La ŝlosilvorto setroute ŝanĝas aŭ aldonas la opcion de implicita enkursigilo, kiun la ASA transdonas al la kliento. Ĝi ne instalas itineron sur la ASA kaj ne kreas VPN-politikon. Kliento, kiu ricevas adreson sed atingas nenion, ofte havas problemon pri setroute aŭ pri amplekso, ne pri tunelo. Testu ĝin per kliento sen statika pordo kaj observu, kiu implicita enkursigilo aperas en la oferto.

Legu la oferton de komenco ĝis fino: proponita adreso, masko, implicita enkursigilo, DNS kaj luotempo. Poste lasu la luon renoviĝi. Ripetilo, kiu funkcias unufoje kaj malsukcesas ĉe renovigo, kutime havas problemon pri amplekso, luo aŭ revena vojo, kiun la unua interŝanĝo kaŝis.

Kion mi kontrolas antaŭ ol nomi ĝin riparita

Komencu ĉe la kliento kaj kaptu la dissendon, poste konfirmu, ke la ASA plusendis ĝin kun sia propra adreso kiel giaddr. Sur la fora flanko konfirmu, ke la servilo vidis tiun peton kaj elektis amplekson kongruan al la branĉo. Reen en la branĉo konfirmu, ke la kliento akceptis la oferton kaj atingas sian pordon.

Se iu parto silentas, kontrolu la konforman politikon aŭ itineron anstataŭ aldoni plian ripetilan deklaron. La ripetila agordo kutime jam estas ĝusta kiam iu eskalas; la tunela politiko aŭ la revena itinero estas tio, kio ŝanĝiĝis.

Skribu la tri partojn en la ŝanĝprotokolon: klienta interfaco, VPN-politiko kovranta la ripetilan trafikon, kaj la revena itinero de la servilo al giaddr. Ĝuste tiu protokolo faras la sekvan branĉan konstruon ripetebla tasko anstataŭ sencimiga sesio. Ĝi ankaŭ diras al la sekva inĝeniero, kiun komandeligon kolekti unue.