De ce conexiunea punct-la-site are nevoie de un gateway Azure VPN bazat pe rute

Un gateway bazat pe politici construiește un tunel IPsec selectat de selectorii de trafic și nu are interfață căreia să îi predea rutele clienților. Conexiunea punct-la-site este o funcție de rutare: gateway-ul deține un pool de adrese de client și instalează rute către acei clienți în rețeaua virtuală. Această discrepanță este motivul pentru care portalul nu afișează nicio opțiune de a o adăuga. Nimic din gateway-ul existent nu poate fi comutat pentru a produce interfața, așa că schimbarea este o înlocuire, nu o editare a configurației.

Ordinea contează mai mult decât pașii individuali. Dacă secvența este greșită, întreruperea dintre site-uri depășește fereastra de mentenanță.

Ce face de fapt un gateway bazat pe politici

Un gateway bazat pe politici potrivește pachetele cu selectorii de trafic configurați pe conexiune și trimite potrivirile într-un singur tunel. Nu există interfață de tunel cu adresă și nicăieri în rețeaua virtuală nu apare o rută per client. Tabelul de rutare primește doar prefixele locale care indică gateway-ul. Acel model este suficient pentru o conexiune site-la-site între două spații de adrese fixe.

Un gateway bazat pe rute funcționează invers: prezintă o interfață de tunel, iar rutele decid ce intră în ea. Conexiunea punct-la-site, și orice design al cărui set de parteneri se schimbă, depind de existența acelei interfețe.

De ce pool-ul de clienți are nevoie de acea interfață

Când un laptop se conectează, gateway-ul îi atribuie o adresă din pool-ul punct-la-site. Rețeaua virtuală are atunci nevoie de o rută care să spună că această adresă este accesibilă prin gateway. Fără o interfață de tunel nu există nimic de care să fie atașată acea rută.

Pool-ul provine dintr-un interval pe care îl stabiliți, iar gateway-ul alocă din el. Dacă intervalul se suprapune cu rețeaua locală sau cu o rețea virtuală conectată prin peering, conflictul apare abia după ce un client se conectează, ceea ce este un moment prost pentru a-l descoperi. Rezervați pool-ul înainte de începerea migrării.

Nici tipul nu este o setare per conexiune. Un gateway are un singur tip, iar fiecare conexiune pe care o ține se comportă în consecință, așa că un design mixt are nevoie de un al doilea gateway, nu de o a doua conexiune.

Tipul este fixat la creare

Microsoft afirmă că un gateway de rețea virtuală nu poate fi schimbat între bazat pe politici și bazat pe rute după implementare. Nu există comandă de conversie și nici comutator în portal. Crearea unui al doilea gateway în aceeași subrețea nu este nici ea o soluție ocolitoare, deoarece Azure permite un gateway per rețea virtuală. Migrarea este, prin urmare, eliminare, reconstruire și reconectare.

Asta include și decizia de SKU în aceeași construcție. Trecerea la un SKU mai mare mai târziu este o altă înlocuire de gateway cu o altă întrerupere.

Un gateway, o GatewaySubnet

Gateway-ul locuiește într-o subrețea numită GatewaySubnet, iar doar un gateway o ocupă. Dimensionarea acelei subrețele face parte din pregătire, deoarece un SKU mai mare are nevoie de mai multe adrese, iar o subrețea nu poate fi micșorată ulterior. Notați setările actuale site-la-site, cheia partajată, gateway-ul de rețea locală și rutele efective înainte de a atinge ceva. Apoi tratați fereastra ca o întrerupere, deoarece tunelul site-la-site rămâne jos până când noua conexiune este configurată.

O ordine de reconstruire care limitează întreruperea: creați gateway-ul bazat pe rute, recreați conexiunea site-la-site către același gateway de rețea locală, confirmați tunelul și o cerere de la gazdă la gazdă, și abia apoi adăugați punct-la-site și generați un pachet de client nou.

Ce nu repară înlocuirea

O a doua limitare aparține partenerului, nu Azure. Un dispozitiv local bazat pe politici poate ajunge doar la rețeaua virtuală de care se conectează și nu poate tranzita către alte rețele locale sau alte rețele virtuale prin același gateway. Înlocuirea părții Azure nu schimbă ce poate selecta partenerul.

Dacă cerința este într-adevăr tranzit între site-uri, răspunsul este un dispozitiv partener bazat pe rute sau o topologie în care fiecare destinație se termină separat. Decideți asta înainte de a promite o dată, deoarece înlocuirea gateway-ului singură nu o va livra.

Ordinea operațiunilor și a verificărilor

Verificați fiecare capabilitate separat. Mai întâi starea tunelului site-la-site și o cerere de la gazdă la gazdă, apoi o conexiune punct-la-site și o resursă privată, apoi orice cale de tranzit pe care designul o susține. O stare verde a gateway-ului dovedește doar că asocierea de securitate a urcat, și nimic mai mult. Țineți verificările în acea ordine, astfel încât o defecțiune să indice etapa care a introdus-o.

Regenerați pachetele de client după orice schimbare de topologie și țineți pool-ul departe de fiecare interval local și conectat prin peering. Constrângerile și diferențele dintre SKU sunt adunate în referința setărilor Azure VPN Gateway.