Azure P2S: isang Windows client ang nawalan ng mga ruta pagkatapos ng pagbabago sa VNet

Dalawang laptop ang nagpapatunay sa parehong Azure point-to-site gateway, at isa lang ang nakakaabot sa bagong konektadong VNet. Pareho silang nagpapakita ng Connected, kaya ang pagpapatunay ay hindi ang pagkakaiba; ang mga destinasyong ruta na hawak nila ang pagkakaiba. Magsimula sa client na nabigo, ihambing ang isang destinasyon, at pagkatapos lang magpasya kung ang gateway package o ang lokal na talahanayan ng ruta ang may-ari ng puwang.

Magsimula sa client na nabigo, hindi sa gateway

Kumpirmahin ang topolohiya bago sisihin ang laptop. Tingnan kung aling mga VNet ang konektado sa VNet ng gateway at kung ang bagong network ay direktang peer o naabot sa pamamagitan ng hiwalay na site-to-site tunnel. Kung ang bagong VNet ay hindi konektado sa VNet ng gateway, walang packet ng client ang makakapag-ruta doon, at ang gumaganang laptop ang anomalyang dapat ipaliwanag. Isulat ang sagot, dahil ito ang nagtatakda kung client o gateway ang ini-debug mo.

Kapag tama na ang topolohiya, ilagay ang dalawang laptop nang magkatabi. Parehong gateway, parehong pool ng address, parehong protocol at parehong build ng client ang paghahambing na gusto mo; anupamang iba ay pangalawang variable na kailangang alisin mamaya.

Ihambing ang isang destinasyon gamit ang route print

Pumili ng pinapayagang IP ng resource at ihambing ang dalawang laptop nang dalawang beses: nakadiskonekta, pagkatapos nakakonekta. Sa Windows, inililista ng route print -4 ang mga rutang IPv4 na may prefix ng destinasyon, interface, susunod na hop at metric. Itala ang row na talagang mananalo para sa destinasyong iyon sa halip na bilangin ang mga entry na naglalaman ng salitang VPN.

Ang pagpili ay pinakamahabang prefix muna, pagkatapos ang metric, kaya ang mas partikular na lokal na ruta ay maaaring talunin ang ruta ng tunnel nang hindi mukhang mali. Kung ang nilalayong destinasyon ay nasa loob ng 10.24.0.0/16, ang malusog na client ay nagpapakita ng tugmang ruta sa interface ng VPN, habang ang nabigong client ay nagpapadala ng parehong address sa default gateway nito.

Ang magkasalungat na lokal na prefix ay maaaring gumawa ng parehong sintomas. Bago magdagdag ng anuman, magpasya kung alin sa dalawang kaso ang mayroon ka: walang ruta ng tunnel, o rutang tunnel na natatalo ng mas partikular.

Ang TTL expired ay hindi bug sa pamamahagi ng ruta

Ang ping na nagbabalik ng TTL expired in transit ay nagsasabing naubos ng packet ang quota nito sa hop, na kadalasang nangangahulugang loop sa pagpapasa at hindi sirang VPN driver. Tumatanggap ang ping ng Windows ng TTL hanggang 255, at ang pagpapataas ng halaga ay hindi nag-aayos ng loop; pinapaliban lang nito ang parehong error. Ituring ang mensahe bilang sintomas ng landas, hindi bilang ebidensya tungkol sa pamamahagi ng ruta.

Gamitin ang tracert -4 10.24.1.10 upang makita kung saan inuulit ang landas. Kung ang parehong dalawang hop ay paulit-ulit na lumilitaw, maghanap ng rutang nagpapadala ng trapikong patungo sa tunnel pabalik sa tunnel o sa lokal na router na nagpapabalik nito.

Muling buuin ang package sa gateway na nagmamay-ari nito

Itinatala ng Microsoft na ang mga Windows client package ay dapat i-download at i-install muli pagkatapos ng nauugnay na pagbabago sa topolohiya. Kunin ang kasalukuyang package mula sa Azure gateway na nagsisilbi sa profile na ito, pagkatapos ay ilapat ito gamit ang sinusuportahang proseso para sa client na iyon. Ang pagpapalit ng executable ng walang kaugnayang VPN application ay hindi parehong operasyon ng muling pagbuo ng mga setting na partikular sa gateway. Mura ang muling pag-download ng package; hindi mura ang paghula sa mga lokal na ruta.

Kumonekta muli at muling basahin ang ruta para sa orihinal na destinasyon. Itago ang mga row bago at pagkatapos kasama ang talaan ng pagbabago upang ang resulta ay mas tumpak kaysa muling na-install ko ang client.

Ang mga senaryo ng pagruruta ng Azure P2S ay naghihiwalay ng direktang peer na VNet mula sa mga network na naaabot sa iba pang tunnel, at ang bagong package ay hindi maaaring gawing transitibo ang peering. Ang ilang senaryo ng Windows site-to-site o BGP ay nangangailangan din ng manu-manong naka-configure na malalayong ruta, kaya ang pag-refresh ng package ay hindi pangkalahatang mekanismo ng pamamahagi ng ruta.

Panatilihing pansamantala ang pansamantalang ruta

Ang manu-manong ruta ay makakapaghiwalay ng nawawalang ruta ng client, ngunit buuin ito mula sa tunay na disenyo: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, nang walang persistent flag, upang mawala ito sa reboot. Piliin ang index ng interface at susunod na hop mula sa konektadong VPN adapter, hindi mula sa hula.

Huwag iwanan ang eksperimental na ruta bilang permanenteng katunggaling may-ari. Ang mga update sa profile sa hinaharap ay maaaring magdagdag ng parehong prefix na may ibang metric, at pagkatapos ay tahimik na nagpapasya ang manu-manong entry kung aling landas ang mananalo. Itala ang hakbang sa pag-alis sa pagbabago.

Kapag aktibo na ang tamang ruta, subukan ang target na application sa halip na ping. Kung umabot ang mga packet sa Azure ngunit nabibigo pa rin ang serbisyo, tingnan ang network security group at ang pabalik na landas, dahil hiwalay ang mga ito sa kung natutunan ng laptop ang prefix.