Sinasabi ng IP flow verify ng Azure na pinapayagan, pero nabigo pa rin ang VPN

Konektado ang site-to-site tunnel, malusog ang VM, pero wala natatanggap ang on-premises client. Bubuksan mo ang Network Watcher, patakbuhin ang IP flow verify, at sasabihin nitong Access allowed, kaya isasara ang ticket bilang problema sa VPN. Hindi ibig sabihin ng resultang iyon ang nakikita, dahil sinusuri ng IP flow verify ang mga panuntunan sa seguridad para sa flow na inilarawan mo at hindi kailanman sinusubukan kung may ruta ang Azure patungo sa iyong on-premises prefix.

Hiwalay ang tanong sa pag-filter at ang tanong sa routing, at sinasagot ito ng Network Watcher gamit ang magkaibang tool. Ang malaman kung alin ang itinanong mo ang malaking bahagi ng diagnosis.

Ano ang aktuwal na pinagpapasyahan ng IP flow verify

Kinukuha ng IP flow verify ang isang VM, isang network interface, isang direksyon, mga halaga ng five-tuple at isang protocol, pagkatapos ay iniuulat ang desisyon ng NSG at security-admin na panuntunan para sa flow na iyon. Gumagana ito sa TCP at UDP, kaya hindi ito tester ng ICMP na panuntunan at walang napatutunayan ang na-block na ping tungkol sa iyong serbisyo. Bigyan ito ng tunay na flow sa halip na hula. Ang papasok na koneksyon mula sa on-premises patungo sa port ng database ay ibang paglalarawan kaysa sa palabas na koneksyon na sinisimulan ng VM.

Kung nagsasalin ng address ang gateway, gamitin ang source address na umaabot sa hangganang sinusuri mo, hindi ang nasa config ng client. Basahin din ang resulta kung ano ito. Ang Access allowed ay nangangahulugang papayagan ng filter layer ang packet kung darating ito, at wala nang iba.

Ang hindi nito masasabi ay ang rutang pinili ng Azure, kung pinapayagan ng guest firewall ang port, o kung may nakikinig. Nabubuhay iyon sa ibang layer.

Ano ang idinadagdag ng susunod na hop at mabisang ruta

Sinasagot ng susunod na hop ang tanong sa forwarding: para sa destinasyong ito, aling uri ng susunod na hop ang pipiliin ng Azure, sa aling address, mula sa aling route table. Inililista ng mabisang ruta kung ano talaga ang nasa NIC. Patakbuhin ang dalawa at makukuha mo ang landas sa panig ng Azure na iniiwang blangko ng berdeng IP flow verify.

Ang pangkalahatang-tanaw ng IP flow verify ng Microsoft ay direktang nagsasaad ng saklaw ng pag-filter, habang ang mga pahina ng susunod na hop at diagnosis ng ruta ay sumasaklaw sa panig ng forwarding. Sipiin ang tamang pahina kapag isinusulat ang natuklasan.

Sapat na maikli ang mga command para patakbuhin mula sa shell. az network nic show-effective-route-table inililista ang mga rutang inilapat sa interface. az network watcher show-next-hop kasama ang source at destinasyon ay ibinabalik ang napiling hop. Ihambing ang prefix na mahalaga sa iyo sa talahanayang iyon, pagkatapos ay tiyakin kung aling entry ang nananalo.

Lakarin ang pabalik na landas mula sa NIC ng VM

Gawin ito mula sa NIC ng target na VM, para sa on-premises client prefix, hindi para sa internet. Ang pabalik na landas ang pinagtataguan ng mga sira sa site-to-site, dahil ang pagsusuri ng estado ng tunnel ay nag-uulat lamang na nakataas ang mga security association.

Kung wala ang inaasahang ruta, suriin ang malalayong prefix na ibinibigay ng config ng gateway, ang disenyo ng VNet connectivity at anumang setting ng route propagation. Inilalarawan ng object ng local network gateway ang on-premises na panig; hindi nito pinatutunayan na ang bawat kailangang prefix ay naroroon at ginusto sa NIC. Magkaibang katotohanan iyon, at isa lang sa kanila ang lumalabas sa buod ng portal.

Basahin ang uri ng susunod na hop sa halip na kopyahin ang halimbawa

Ang landas sa managed VPN gateway ay karaniwang nagpapakita ng VirtualNetworkGateway bilang uri ng susunod na hop. VirtualAppliance naglalarawan ng ibang disenyo ng forwarding, kadalasan firewall o virtual network appliance.

Huwag gumawa ng appliance route patungo sa hinulaang VPN endpoint dahil ginamit ng lumang sagot sa forum ang uring iyon. Kung pinapalitan ng user-defined route ang nilalayong landas, hanapin ang may-ari at layunin nito bago ito baguhin. Maaari ring baguhin ng pangalawang NIC kung aling interface ang ginagamit ng guest, at ang pagtanggal nito ay maaaring makasira ng ibang serbisyo sa halip na ayusin ang rutang ito.

Lumipat sa hangganang nabibigo pa rin

Kapag tumutugma ang filtering at routing sa disenyo, nasa ibang lugar ang sira. Suriin ang sariling route table ng guest, ang firewall nito at kung nakatali ang listener sa inaasahang address. Pagkatapos suriin ang protected traffic selectors ng VPN at ang on-premises na landas ng tugon. Bawat isa sa kanila ay hiwalay na pagsubok na may hiwalay na resulta.

Tapusin sa pinapayagang kahilingan ng application at mga obserbasyon mula sa dalawang dulo. Ang resultang allow at tamang susunod na hop ay dalawang piraso ng ebidensya, hindi patunay na nagtagumpay ang koneksyon.