DHCP relay ng ASA sa isang site-to-site VPN: sunod-sunod na gabay

Gumagana ang relay sa tatlong bahagi, at ang gitnang bahagi lang ang tumatawid sa VPN. Nagbo-broadcast ang kliyente sa segment ng sangay, ginagawa ng ASA ang broadcast na iyon na unicast na kahilingan sa DHCP server, at sumasagot ang server sa address ng relay at hindi sa kliyente. Daanan ang mga bahagi sa ganoong pagkakasunod-sunod, at karamihan ng kaso ng «sira ang relay» ay nauuwi sa nawawalang patakaran o maling nabasang setroute na linya.

Unang bahagi: i-enable ang relay sa interface na nakaharap sa kliyente

Sa ASA ng sangay, ang relay ay katangian ng interface na nakatingin sa mga kliyente. Maaaring ideklara ang server nang pangkalahatan kasama ang naaabot na interface nito, o sa ilalim ng interface na nakaharap sa kliyente upang piliin ng routing table ang labasan. Hindi mapagpapalit ang dalawang anyo, at ang kopyahin ang mali ay ang unang lugar kung saan nalilihis ang isang gabay.

Suriin ang tumatakbong config bago magbago ng anuman: aling interface ang may enable na relay, aling anyo ng server ang naroroon, at kung nakaattach ang setroute sa interface ng kliyente. Kung nagpapatakbo rin ang ASA ng DHCP server para sa ibang segment, huminto at basahin ang listahan ng paghihigpit; hindi maaaring i-enable ang server at relay nang sabay sa iisang aparato.

Inilalagay ng relay ang sarili nitong address na nakaharap sa kliyente sa field ng gateway address. Iyon ang address na sasagutin ng server, kaya dapat itong maabot mula sa malayong site sa pamamagitan ng tunnel, hindi lang lokal.

Ikalawang bahagi: dalhin ang trapik na nililikha ng ASA sa tunnel

Ito ang hakbang na nilalaktawan ng mga tao. Ang site-to-site VPN na nakabatay sa patakaran ay karaniwang ginagawa para sa trapik sa pagitan ng mga subnet, at ang kahilingan ng relay ay ang ASA mismo ang gumagawa. Kung ang access list ng tunnel at ang crypto map ay tumutugma lamang sa mga daloy mula sa host ng sangay patungo sa subnet ng server, maaaring hindi kailanman makapasok ang packet ng relay sa tunnel. Suriin ang access list sa dalawang direksyon, hindi lang ang linyang sangay-patungo-server.

Tiyakin na ang trapik na mahalaga ay sumasaklaw sa pinagmulan ng relay ng ASA at sa address ng server, at pinapayagan din ang pabalik na direksyon. Sa disenyong nakabatay sa VTI, mas simple ang desisyon sa routing, ngunit ang suporta sa relay sa VTI ay dumating sa isang partikular na release; ang gabay sa DHCP ng ASA ay tumutukoy sa 9.14(1), kaya suriin ang image bago kopyahin ang halimbawa ng VTI sa mas lumang aparato.

Ang ping mula sa ASA patungo sa server ay kakaunti ang pinapatunayan nang mag-isa. Maaari itong magtagumpay sa ibang landas, sa ibang source address, o sa ilalim ng patakarang hindi tinutugunan ng mga packet ng relay.

Ikatlong bahagi: basahin ang tugon at ang opsiyon ng setroute

Sinasabi ng RFC 2131 na ipinapadala ng server ang tugon nito sa address sa giaddr kapag ang field na iyon ay hindi zero. Kaya dapat i-route ang pabalik na landas patungo sa address ng relay, at dapat payagan ng patakaran ng tunnel ang direksyong server-patungo-relay. Kung nakapasok ang kahilingan ngunit hindi kailanman dumating ang alok, dito dapat tumingin.

Pagkatapos, paghiwalayin ang dalawang bagay na magkatunog. Binabago o dinadagdag ng keyword na setroute ang opsiyon ng default router na ibinibigay ng ASA sa kliyente. Hindi ito nag-iinstall ng ruta sa ASA at hindi gumagawa ng patakaran ng VPN. Ang kliyenteng nakakuha ng address ngunit walang naabot ay madalas may problema sa setroute o saklaw, hindi sa tunnel. Subukan ito sa kliyenteng walang static na gateway at tingnan kung aling default router ang lumilitaw sa alok.

Basahin ang alok mula simula hanggang dulo: alok na address, mask, default router, DNS at tagal ng lease. Pagkatapos, hayaang mag-renew ang lease. Ang relay na gumana isang beses at nabigo sa renew ay karaniwang may problema sa saklaw, lease o pabalik na landas na itinago ng unang palitan.

Ano ang sinusuri ko bago sabihing ayos na

Magsimula sa kliyente at hulihin ang broadcast, pagkatapos tiyakin na ipinagpatuloy ito ng ASA gamit ang sarili nitong address bilang giaddr. Sa malayong panig, tiyakin na nakita ng server ang kahilingang iyon at pumili ng saklaw na tugma sa sangay. Pagbalik sa sangay, tiyakin na tinanggap ng kliyente ang alok at naaabot nito ang gateway nito.

Kung tahimik ang alinmang bahagi, suriin ang katumbas na patakaran o ruta sa halip na magdagdag ng isa pang pahayag ng relay. Karaniwang tama na ang config ng relay sa oras na may nag-escalate; ang nabago ay ang patakaran ng tunnel o ang pabalik na ruta.

Isulat ang tatlong bahagi sa rekord ng pagbabago: interface na nakaharap sa kliyente, patakaran ng VPN na sumasaklaw sa trapik ng relay, at ang pabalik na ruta ng server patungo sa giaddr. Ang rekord na iyon ang gumagawa sa susunod na pagbuo ng sangay na paulit-ulit na trabaho sa halip na sesyon ng pag-debug. Sinasabi rin nito sa susunod na inhinyero kung aling output ng command ang unang kolektahin.