Aling VRF ang umabot sa kapareha ng VPN at alin ang nagdadala ng packet?

Bawat tunnel sa loob ng routing context ng kliyente ay kailangan pa ring maabot ang malayong kapareha nito, at ang paghahanap na iyon ay maaaring mangyari sa ganap na ibang talahanayan. Ang maling paggawa nito ay gumagawa ng isa sa mga pinakalitong pagkabigo sa IPsec na may kamalayan sa VRF: umaangat ang tunnel, mukhang naroroon ang mga ruta, at namamatay ang trapiko dahil isa sa dalawang paghahanap ang gumamit ng maling konteksto. Isagawa ang apat na hakbang sa ibaba nang sunod-sunod, at isulat nang hiwalay ang dalawang destinasyon.

Dalawang paghahanap, isang tunnel

Ang panlabas na naka-encapsulate na packet ay naka-address sa transport address ng kapareha, at ito ay niruruta bago pa man umiral ang anumang proteksyon. Ang panloob na packet ay naka-address sa server ng kliyente at niruruta pagkatapos ng decapsulation, sa loob ng konteksto ng kliyente. Iyon ay dalawang destinasyon, dalawang paghahanap at kadalasan ay dalawang magkaibang talahanayan.

Tinatawag ng dokumentasyon ng Cisco para sa IPsec na may kamalayan sa VRF ang mga ito na VRF ng harap na pinto at panloob na VRF. Ang harap na pinto ay nagdadala ng naka-encrypt na transport, at ang panloob na konteksto ay nagdadala ng protektadong trapiko. Walang anuman sa pagpapangalan ng tunnel sa isang kliyente ang nagpapalitaw sa alinman sa dalawang ruta.

Kaya ilista ang apat na katotohanan bago baguhin ang isang configuration: ang transport address ng kapareha at ang kontekstong umaabot dito, pagkatapos ang prefix ng server at ang kontekstong umaabot dito. Kung hindi mo mapunan ang apat, malapit ka nang manghula. Mahal ang panghuhula sa larangang ito, dahil ang rutang idinagdag sa maling talahanayan ay maaaring magpagana ng isang daloy habang tahimik na sinisira ang isa pa. Ang apat na katotohanan ay tumatagal ng sampung minuto upang kolektahin at nakakatipid ng isang araw ng pagsusuri ng capture.

Kumpirmahin ang paghahanap ng transport para sa kapareha

Magsimula sa harap na pinto, dahil ang tunnel na hindi maabot ang kapareha nito ay hindi kailanman magpapadaan ng kahit isang protektadong packet. Sa IOS, hingin ang ruta patungo sa kapareha sa loob ng transport VRF at hindi sa pandaigdigang talahanayan.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

Sinasagot ng unang utos kung naaabot ang address ng kapareha sa kontekstong iyon, inililista ng pangalawa ang mga VRF na tunay na umiiral, at ipinapakita ng pangatlo kung nabuo ang isang security association. Ang address ng kapareha na nalulutas lamang sa pandaigdigang talahanayan ay ang klasikong pagkakamali sa harap na pinto, at lumilitaw ito bilang isang negosasyon ng IKE na hindi kailanman nagsisimula.

Suriin din ang pagtatalaga ng interface. Inaatas ng dokumentadong pag-uugali na magkasundo ang VRF ng harap na pinto ng tunnel at ang VRF ng interface ng WAN; ang hindi pagkakasundo ay maaaring hayaang lumabas ang isang packet at gayon pa man ay hadlangan ang tugon na maproseso sa tamang konteksto.

Kumpirmahin ang panloob na paghahanap para sa server

Kapag napatunayan na ang harap na pinto, lumipat sa konteksto ng kliyente at itanong ang parehong tanong tungkol sa prefix ng server. Ang paghahanap na ito ang nagpapasya kung ang isang na-decapsulate na packet ay maipapasa.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

Ipinapakita ng unang utos ang panloob na ruta, at ipinapakita ng pangalawa ang kalagayan ng sesyon kasama ang mga kontekstong iniugnay ng platform dito. Kung umiiral ang ruta ngunit tinutukoy ng mga detalye ng sesyon ang maling panloob na konteksto, nagpapasa ang tunnel sa isang talahanayang hindi alam ang prefix ng kliyente.

Ang ruta sa pandaigdigang talahanayan ay hindi ebidensya para sa alinman sa dalawang paghahanap. Ginagamit ang mga pandaigdigang ruta kapag ang isang packet ay hindi nauugnay sa isang VRF, at binabago ng interface ng tunnel na itinalaga sa isang konteksto ng kliyente ang ugnayang iyon. Kung wala ang panloob na ruta, ang packet ay nade-decapsulate at pagkatapos ay itinatapon dahil sa kawalan ng entry sa pagpapasa, na mukhang pagkawala ng packet at hindi pagkakamali sa ruta.

Ilagay ang setting kung saan ito inaasahan ng modelo

Ang parehong dokumentasyon ay nagtatangi ng mga modelo ng configuration, at ang setting na kabilang sa isa ay hindi kinakailangang kabilang sa isa pa. Para sa mga interface ng tunnel na gumagamit ng proteksyon ng tunnel, ang panloob na VRF ay tinukoy sa interface ng tunnel. Sa mga disenyong nakabatay sa crypto map, ang panloob na VRF ay bahagi ng entry ng crypto map. Ang paglilipat ng utos na may katulad na pangalan sa pagitan ng mga modelo nang hindi sinusuri ang papel nito ay ang paraan kung paano nagiging pana-panahon ang isang gumaganang disenyo.

Ang ruta at pagkakakilanlan ay magkaibang usapin. Ang maabot ay hindi kailanman pumapalit sa isang profile ng kapareha na tatanggapin ng device, at ang pagpapalit ng pangalan ng VRF ay hindi dapat baguhin ang mga kredensyal na inaalok. Suriin ang dalawa pagkatapos ng anumang pagbabago, dahil ang tunnel na nakikipagnegosasyon sa maling profile ay makakabuo pa rin ng asosasyon at walang maipapasa.

Sa huli, itala ang apat na katotohanan at ang mga utos na nagpatunay sa mga ito sa talaan ng pagbabago. Mamamana ng susunod na inhinyero ang tunnel at hindi ang pangangatwiran, at ang maikling tala na nagbabanggit sa dalawang konteksto ay mas mahalaga kaysa sa diagram na walang nag-a-update.