Azure P2S VPN weromferkear wurket mar ien kant op

It tunnelpictogram is grien, de NSG liket tastien, de effektive rûtes lykje goed, en dochs kin de VM gjin ferbining werom nei de ferbûne klient iepenje. De gewoane oanname is dat in wurkjende point-to-site-tunnel symmetrysk is: as de klient de VM berikke kin, kin de VM de klient berikke. Dy oanname is de flater yn it riddenearjen, net yn de konfiguraasje. In tunnel kin ien rjochting fan in net-frege stream drage en de oare falle litte, en de oplossing hinget ôf fan hokker laach it falle lit.

Myt: in ferbûne tunnel is in twarjochtingtunnel

In VPN-tunnel is in beliedswei, gjin tried. Eltse rjochting wurdt ferlike mei selektors, rûtes en filters, en elk fan dy kin ien rjochting tastean wylst it de oare blokket.

Yn de praktyk is de asymmetry sa gewoan dat de rjochting by de earste test heart, net by de lêste. De klient begjint, de poarte folget de stream, en it antwurd folget de tastân dy't makke is. In VM dy't in nije stream begjint, hat sa'n tastân net, dus it hinget ôf fan in weromwei dy't eksplisyt rûteber en tastien is. As dy wei ûntbrekt, stjert de ferbiningspoging foardat hokker applikaasje dan ek it sjocht.

Testearje de rjochting foardat jo berikberens testearje

Kies ien klientadres, ien VM-adres en ien protokol. Ferbine jo fan de klient en notearje it resultaat; start dan deselde test fan de VM en notearje dy ek. As de earste slagget en de twadde mislearret, wurkje de klientpool, de poarte-assosjaasje en de wei fan klient nei VNet allegear.

De folgjende stap is bewiis, net mear regels. Kontrolearje de NSG op it VM-subnet yn beide rjochtingen, lês de effektive rûtes op de NIC fan de VM, en fange pakketten op de VM wylst de klient ferkear stjoert. In oanfraach dy't oankomt sûnder antwurd is in filter- of weromrûteprobleem; in oanfraach dy't nea oankomt is in weiprobleem. Sjoch in mislearre ping net as bewiis dat de VM net berikber is, want ICMP-belied kin it antwurd falle litte wylst TCP wurket.

De IKEv2 point-to-site weromwei is de gewoane fertochte

Yn it Azure-rapport efter dit artikel koe in klient VM's berikke oer IKEv2, mar ynkommende ICMP fan de VM nei de klient mislearre oant it tunneltype fan de poarte omskeakele waard nei OpenVPN. De rapportskriuwer stelt dat Microsoft in beheining yn de IKEv2 point-to-site-wei befêstige hat, wêrby't weromferkear fan in VM nei de klient net symmetrysk rûte wurdt, útsein as de klient de sesje begûn is. IKEv2 fertrout op ferkearsselektors, en de poarte hat yn dat gefal de weromrjochting net eare.

Dat makket OpenVPN net yn it algemien it bettere tunneltype. It makket tunneltype in fariabele yn de testmatrix foar dizze wurklêst.

It wikseljen fan tunneltype is in tsjinstferoaring, gjin skeakel. Eltse klient hat in kompatibel profyl nedich, en de poarte kin in oar sertifikaat of in oare autentikaasje-opset nedich hawwe. Reproduzearje it ienrjochtinggedrach mei ien testklient en ien test-VM, feroarje it type neffens in goedkarde planning, en werhelje dêrnei deselde rjochtingstests. As it gedrach de wiksel oerlibbet, wie it tunneltype net de oarsaak en hawwe jo it probleem beheind sûnder produksje oan te reitsjen.

Myt: broadcast-ûntdekking krúst de VNet-râne

In twadde oanname mislearret om in net-relatearre reden. In Azure-firtuele netwurk ferfiert gjin broadcast-ferkear, dus in VM kin gjin broadcast-frames fan in lokaal netwurk ûntfange fia in site-to-site- of point-to-site-ferbining. Applikaasjes dy't peers fia broadcast fine, lykas âlder bestânssneupen of guon apparaat-ûntdekkingsprotokollen, sille de fiere kant nea sjen, hoe't de rûtes ek skreaun binne.

Ferfange broadcast-ûntdekking troch DNS-nammen, in gidsstsjinst of in eksplisite peer-list. As de applikaasje gjin unicast-alternatyf hat, hat it ûntwerp in oar ûntdekkingsmeganisme nedich, net in bredere tunnel.

Wat te feroarjen, en hoe't jo it bewize

As de rjochtingstest allinnich op IKEv2 mislearret, notearje dan it tunneltype fan de poarte, de klientadrespool en de krekte ICMP- of TCP-test, en beoardielje dan in goedkard OpenVPN-profyl foar de troffen klanten. As it op elk tunneltype mislearret, wurkje dan de weromwei: it klientadres moat fan it VM-subnet ôf rûteber wêze, elke troch de brûker definiearre rûte moat nei in jildige folgjende hop wize, en de firewall fan de klient moat de ynkommende stream akseptearje. Heakje it NSG- en rûtebewiis oan it ticket.

Ferifiearje mei de applikaasje, net mei ping. In suksesfolle ICMP-útwikseling nei in feroaring seit neat oer de tsjinstpoarte, syn autentikaasje of syn namme-oplossing. Werhelje de test nei in werferbining, want in klient dy't in oar pooladres krijt, kin it resultaat feroarje. Werhelje it dan noch ien kear nei't de klient sliept en wekker wurden is, want it is yn in ferfette sesje dat ienrjochtinggedrach faak wer ferskynt.