Uelekezaji wa DHCP wa ASA kupitia VPN ya site-to-site: mwongozo wa hatua kwa hatua

Uelekezaji hufanya kazi kwa hatua tatu, na ni hatua ya kati pekee inayovuka VPN. Mteja hutangaza kwenye sehemu ya tawi, ASA hubadilisha tangazo hilo kuwa ombi la unicast kwa seva ya DHCP, na seva hujibu anwani ya uelekezaji badala ya mteja. Pitia hatua kwa mpangilio huo, na matukio mengi ya «uelekezaji umeharibika» huishia kwenye sera inayokosekana au mstari wa setroute uliosomwa vibaya.

Hatua ya kwanza: washa uelekezaji kwenye kiolesura kinachoelekea mteja

Kwenye ASA ya tawi, uelekezaji ni sifa ya kiolesura kinachotazama wateja. Seva inaweza kutangazwa kimataifa pamoja na kiolesura chake kinachofikika, au chini ya kiolesura hicho kinachoelekea mteja ili jedwali la uelekezaji lichague njia ya kutoka. Maumbo hayo mawili hayabadilishani, na kunakili lile lisilo sahihi ni mahali pa kwanza ambapo mwongozo hupotea njia.

Kagua usanidi unaoendelea kabla ya kubadilisha chochote: kiolesura kipi kimewasha uelekezaji, umbo lipi la seva lipo, na kama setroute imeunganishwa na kiolesura cha mteja. Ikiwa ASA pia inaendesha seva ya DHCP kwa sehemu nyingine, simama na usome orodha ya vikwazo; seva na uelekezaji haviwezi kuwashwa kwa wakati mmoja kwenye kifaa kimoja.

Uelekezaji huweka anwani yake inayoelekea mteja kwenye uwanja wa anwani ya lango. Seva itajibu anwani hiyo, kwa hiyo lazima ifikike kutoka eneo la mbali kupitia handaki, si kwa ndani pekee.

Hatua ya pili: beba trafiki inayozalishwa na ASA kupitia handaki

Hii ndiyo hatua ambayo watu huiruka. VPN ya site-to-site inayotegemea sera kwa kawaida hujengwa kwa trafiki kati ya subneti, na ombi la uelekezaji huzalishwa na ASA yenyewe. Ikiwa orodha ya ufikiaji ya handaki na ramani ya crypto zinalingana tu na mitiririko kutoka mwenyeji wa tawi kwenda subneti ya seva, pakiti ya uelekezaji inaweza isiingie handakini kabisa. Kagua orodha ya ufikiaji pande zote mbili, si mstari wa tawi-kwenda-seva pekee.

Thibitisha kwamba trafiki yenye maslahi inashughulikia chanzo cha uelekezaji cha ASA na anwani ya seva, na kwamba mwelekeo wa kurudi unaruhusiwa pia. Katika muundo unaotegemea VTI uamuzi wa uelekezaji ni rahisi zaidi, lakini msaada wa uelekezaji juu ya VTI ulikuja katika toleo maalum; mwongozo wa DHCP wa ASA unataja 9.14(1), kwa hiyo kagua picha kabla ya kunakili mfano wa VTI kwenye kifaa cha zamani zaidi.

Ping kutoka ASA kwenda seva yenyewe haithibitishi mengi. Inaweza kufanikiwa kwa njia nyingine, kwa anwani nyingine ya chanzo, au chini ya sera ambayo pakiti za uelekezaji hazilingani nayo.

Hatua ya tatu: soma jibu na chaguo la setroute

RFC 2131 inasema seva hutuma jibu lake kwa anwani iliyo katika giaddr wakati uwanja huo si sifuri. Kwa hiyo njia ya kurudi lazima ielekezwe kwenye anwani ya uelekezaji, na sera ya handaki lazima iruhusu mwelekeo kutoka seva kwenda uelekezaji. Ikiwa ombi lilipita lakini toleo halikuja kamwe, hapa ndipo pa kuangalia.

Kisha tenga mambo mawili yanayosikika sawa. Neno la ufunguo setroute hubadilisha au huongeza chaguo la router chaguo-msingi ambalo ASA humpa mteja. Haliweki njia kwenye ASA na haliundi sera ya VPN. Mteja anayepata anwani lakini hafiki popote mara nyingi ana tatizo la setroute au wigo, si tatizo la handaki. Jaribu kwa mteja asiye na lango tuli na uangalie router chaguo-msingi ipi inaonekana kwenye toleo.

Soma toleo kutoka mwanzo hadi mwisho: anwani iliyotolewa, maski, router chaguo-msingi, DNS na muda wa kukodisha. Kisha acha ukodishaji ufanywe upya. Uelekezaji unaofanya kazi mara moja na kushindwa wakati wa kuhuisha kwa kawaida una tatizo la wigo, ukodishaji au njia ya kurudi ambalo ubadilishanaji wa kwanza ulificha.

Ninachokagua kabla ya kusema imerekebishwa

Anzia kwa mteja na ukamate tangazo, kisha thibitisha kwamba ASA iliipeleka kwa anwani yake mwenyewe kama giaddr. Upande wa mbali thibitisha kwamba seva iliona ombi hilo na ikachagua wigo unaolingana na tawi. Ukirudi tawini, thibitisha kwamba mteja alikubali toleo na anafikia lango lake.

Ikiwa hatua yoyote ni kimya, kagua sera au njia inayolingana badala ya kuongeza tamko lingine la uelekezaji. Usanidi wa uelekezaji kwa kawaida huwa sahihi wakati mtu anapandisha suala; kilichobadilika ni sera ya handaki au njia ya kurudi.

Andika hatua tatu kwenye rekodi ya mabadiliko: kiolesura kinachoelekea mteja, sera ya VPN inayoshughulikia trafiki ya uelekezaji, na njia ya kurudi ya seva kwenda giaddr. Rekodi hiyo ndiyo inayofanya ujenzi wa tawi unaofuata kuwa kazi inayoweza kurudiwa badala ya kikao cha utatuzi. Pia inamwambia mhandisi anayefuata ni pato lipi la amri la kukusanya kwanza.