Isang direksyon lang ang gumagana sa return traffic ng Azure P2S VPN

Berde ang icon ng tunnel, mukhang nagpapahintulot ang NSG, mukhang tama ang mga epektibong ruta, at gayon pa man ay hindi pa rin makapagbukas ang VM ng koneksyon pabalik sa konektadong client. Ang karaniwang palagay ay simetriko ang gumaganang point-to-site tunnel: kung naaabot ng client ang VM, naaabot din ng VM ang client. Ang palagay na iyon ang mali sa pangangatwiran, hindi sa configuration. Maaaring magdala ang tunnel ng isang direksyon ng hindi hinihiling na daloy at iwaksi ang isa, at ang pag-aayos ay nakasalalay sa kung aling layer ang nagwawaksi nito.

Mito: ang konektadong tunnel ay dalawang-direksyong tunnel

Ang VPN tunnel ay landas ng patakaran, hindi kawad. Bawat direksyon ay itinatapat sa mga selector, ruta at filter, at alinman sa mga ito ay maaaring magpayag sa isang direksyon habang hinaharangan ang isa.

Sa pagsasagawa, karaniwan ang asimetriya kaya ang direksyon ay dapat nasa unang pagsubok, hindi sa huli. Nag-uumpisa ang client, sinusubaybayan ng gateway ang daloy, at sinusundan ng tugon ang estadong nalikha. Ang VM na nag-uumpisa ng bagong daloy ay walang ganoong estado, kaya umaasa ito sa landas ng pagbabalik na tahasang naruruta at pinapayagan. Kapag wala ang landas na iyon, namamatay ang pagtatangkang kumonekta bago pa ito makita ng anumang aplikasyon.

Subukan ang direksyon bago subukan ang maabot

Pumili ng isang address ng client, isang address ng VM at isang protocol. Kumonekta mula sa client at itala ang resulta; pagkatapos ay simulan ang parehong pagsubok mula sa VM at itala rin iyon. Kung nagtagumpay ang una at nabigo ang pangalawa, gumagana ang pool ng client, ang pagkakaugnay ng gateway at ang landas mula sa client patungo sa VNet.

Ang susunod na hakbang ay ebidensya, hindi mas maraming patakaran. Suriin ang NSG sa subnet ng VM sa dalawang direksyon, basahin ang mga epektibong ruta sa NIC ng VM, at kunan ng packet ang VM habang nagpapadala ng trapiko ang client. Ang kahilingang dumarating na walang tugon ay problema sa filter o ruta ng pagbabalik; ang kahilingang hindi dumarating ay problema sa landas. Huwag ituring na patunay ng kawalan ng maabot ang VM ang isang bigong ping, dahil maaaring iwaksi ng patakaran ng ICMP ang tugon habang gumagana ang TCP.

Ang return path ng IKEv2 point-to-site ang karaniwang pinaghihinalaan

Sa ulat ng Azure sa likod ng artikulong ito, naaabot ng client ang mga VM sa IKEv2, ngunit nabigo ang papasok na ICMP mula sa VM patungo sa client hanggang sa ilipat ang uri ng tunnel ng gateway sa OpenVPN. Sinasabi ng nag-ulat na kinumpirma ng Microsoft ang isang limitasyon sa landas ng IKEv2 point-to-site, kung saan ang trapikong pabalik mula sa VM patungo sa client ay hindi naruruta nang simetriko maliban kung ang client ang nag-umpisa ng session. Umaasa ang IKEv2 sa mga selector ng trapiko, at hindi iginagalang ng gateway ang direksyon ng pagbabalik sa kasong iyon.

Hindi nito ginagawang mas mahusay na uri ng tunnel ang OpenVPN sa pangkalahatan. Ginagawa nitong baryabol ang uri ng tunnel sa matris ng pagsubok para sa workload na ito.

Ang pagpalit ng uri ng tunnel ay pagbabago ng serbisyo, hindi switch. Bawat client ay nangangailangan ng tugmang profile, at maaaring mangailangan ang gateway ng ibang certificate o setup ng authentication. Muling likhain ang isang-direksyong pag-uugali gamit ang isang test client at isang test VM, palitan ang uri ayon sa aprubadong iskedyul, at pagkatapos ay ulitin ang parehong mga pagsubok sa direksyon. Kung mananatili ang pag-uugali pagkatapos ng pagpalit, ang uri ng tunnel ay hindi ang dahilan at napaliit mo ang problema nang hindi hinahawakan ang produksyon.

Mito: ang pagtuklas sa broadcast ay tumatawid sa gilid ng VNet

Ang ikalawang palagay ay nabigo dahil sa walang kaugnayang dahilan. Hindi nagdadala ng broadcast traffic ang virtual network ng Azure, kaya hindi makakatanggap ang VM ng broadcast frame mula sa lokal na network sa pamamagitan ng site-to-site o point-to-site na koneksyon. Ang mga aplikasyong naghahanap ng kapares sa broadcast, tulad ng lumang pagba-browse ng file o ilang protocol ng pagtuklas ng device, ay hindi kailanman makikita ang malayong panig, gaano man isulat ang mga ruta.

Palitan ang pagtuklas sa broadcast ng mga pangalang DNS, serbisyo ng direktoryo o tahasang listahan ng kapares. Kung walang unicast na alternatibo ang aplikasyon, kailangan ng disenyo ng ibang mekanismo ng pagtuklas, hindi mas malawak na tunnel.

Ano ang babaguhin, at paano patunayan

Kung nabigo ang pagsubok sa direksyon sa IKEv2 lamang, itala ang uri ng tunnel ng gateway, pool ng address ng client at ang eksaktong pagsubok sa ICMP o TCP, pagkatapos ay suriin ang aprubadong profile ng OpenVPN para sa mga apektadong client. Kung nabigo ito sa bawat uri ng tunnel, trabahuin ang landas ng pagbabalik: dapat naruruta ang address ng client mula sa subnet ng VM, dapat tumuro ang anumang rutang tinukoy ng user sa wastong susunod na hop, at dapat tanggapin ng firewall ng client ang papasok na daloy. Ikabit ang ebidensya ng NSG at ruta sa ticket.

I-verify gamit ang aplikasyon, hindi gamit ang ping. Ang matagumpay na pagpapalitan ng ICMP pagkatapos ng pagbabago ay walang sinasabi tungkol sa port ng serbisyo, authentication nito o resolution ng pangalan. Ulitin ang pagsubok pagkatapos ng muling pagkonekta, dahil ang client na makakatanggap ng ibang address mula sa pool ay maaaring magbago ng resulta. Pagkatapos ay ulitin ito muli pagkatapos matulog at magising ang client, dahil sa naipagpatuloy na session madalas muling lumitaw ang isang-direksyong pag-uugali.