Două adrese VPN locale: doi parteneri Azure, nu unul

Diagrama are două legături de internet la sucursală și un gateway VPN Azure, așa că gateway-ul de rețea locală primește ambele adrese publice. Pare ordonat și nu funcționează așa cum sugerează diagrama. Fiecare dispozitiv VPN local este o relație de partener separată, iar proiectarea multi-dispozitiv a Microsoft oferă fiecăruia propriul său resource de gateway de rețea locală și propria conexiune. Adăugarea unei a doua adrese la o singură resursă nu creează un al doilea partener. Creează o resursă care nu descrie corect niciunul dintre cele două dispozitive.

Mitul: un gateway, două adrese

Un gateway de rețea locală este descrierea unui partener îndepărtat: un endpoint public și prefixele private din spatele lui. Nu există o modalitate acceptată de a face acea resursă să însemne «oricare dintre aceste două echipamente».

Aceeași confuzie apare în cealaltă direcție, unde două IP-uri publice Azure sunt citite ca dovadă că există două gateway-uri Azure.

Numărați obiectele, apoi tunelurile

Luați două dispozitive locale operate independent, fiecare cu propria adresă publică și acces la aceleași rețele private, plus un gateway Azure bazat pe rutare în modul activ-activ. Gateway-ul Azure are două instanțe active cu IP-uri publice separate. Fiecare dispozitiv local se conectează la ambele instanțe. Aceasta este plasa completă, iar numărul de obiecte decurge din ea, nu din diagramă.

Aritmetica este suficient de scurtă pentru a fi lipită în documentul de proiectare:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

O resursă de conexiune poate transporta mai mult de un tunel subiacent, deci patru tuneluri nu implică patru gateway-uri de rețea virtuală. Nici două IP-uri publice Azure nu sunt aceleași obiecte ca cele două gateway-uri de rețea locală care descriu site-ul îndepărtat.

Ce adaugă activ-activ pe partea Azure

Activ-activ schimbă gateway-ul Azure dintr-o instanță activă în două, fiecare cu propriul IP public, și acesta este ceea ce face posibilă o plasă completă. Nu dublează debitul unui singur flux. De asemenea, nu elimină nevoia ca partea locală să accepte multipath cu cost egal dacă ambele dispozitive transmit simultan. Confirmați modul gateway-ului, SKU-ul și capacitățile dispozitivului îndepărtat înainte de a proviziona ceva.

Un gateway în standby pasiv este un design perfect valid; pur și simplu produce un număr diferit de tuneluri.

BGP face ambele căi utilizabile

Pentru proiectarea cu mai multe dispozitive, ambele dispozitive locale rulează BGP. Dați fiecăruia o adresă de partener BGP unică și anunțați aceleași prefixe private dorite pe căile relevante. Prefixele private identifică rețelele protejate, în timp ce adresele publice identifică unde se termină conexiunile de transport criptate. Confundarea celor două produce un design în care fiecare tunel este activ și rutele sunt greșite.

Planificați rutarea de retur și orice inspecție cu stare care trebuie să tolereze oricare dintre cele două căi. O sesiune IKE sănătoasă pe fiecare endpoint nu dovedește că o sarcină de lucru poate folosi fiecare rută anunțată.

Selecția bazată pe flux nu este agregarea lățimii de bandă

Azure selectează o cale per flux folosind un hash peste adresarea și porturile fluxului. În stare stabilă, pachetele unui anumit flux TCP sau UDP iau de obicei același tunel, iar partea locală poate alege alt tunel pentru direcția de retur. Prin urmare, două dispozitive și patru tuneluri îmbunătățesc disponibilitatea, nu viteza unei singure transferuri. Când un slide al furnizorului promite agregare, descrie o altă funcție sau o neînțelegere.

Testați cu fluxuri paralele dacă vreți să vedeți căile răspândindu-se, și cu un singur flux dacă vreți să vedeți limita.

Ce redundanță ați eliminat de fapt

Două adrese WAN pe un singur dispozitiv îmbunătățesc opțiunile legăturii de acces, dar partajează alimentarea, software-ul și starea de defect a acelui dispozitiv. Nu sunt același lucru cu două dispozitive, iar nicio configurație de pe partea Azure nu schimbă asta. Urmați proiectarea dual-WAN sau cluster acceptată de furnizor, în loc să deduceți redundanța din numărul de adrese. Apoi testați: eliminați o cale pe rând și confirmați rutele rămase plus un schimb real de aplicație în ambele direcții.

Așteptați-vă la întârzieri de detectare și convergență și la faptul că unele sesiuni existente se vor termina.