O singură VM Azure are nevoie de tunel: client invitat sau gateway VPN?

O singură încărcare de lucru dintr-o VM Azure trebuie să ajungă la o rețea privată printr-un tunel. Întrebarea care decide proiectarea nu este care produs VPN este mai bun, ci dacă vreo altă mașină va avea vreodată nevoie de acea cale. Răspundeți întâi la asta și restul arhitecturii se alege de obicei singur. Dacă greșiți, moșteniți o VM care a devenit în liniște un router pe care nimeni nu l-a documentat.

Două sarcini care arată la fel

O VM poate fi punct final sau punct de tranzit, iar diferența nu este software-ul pe care îl instalați, ci cine consumă tunelul. Ca punct final, invitatul rulează un client pentru propriile procese. Ca punct de tranzit, redirecționează pachetele altor încărcări de lucru, ceea ce îl face parte din topologia rețelei.

Cele mai multe cereri pentru o singură VM sunt prima sarcină îmbrăcată în limbajul celei de-a doua. Cineva spune „VM-ul este VPN-ul nostru” când vrea să spună că o aplicație de pe ea trebuie să ajungă la o bază de date de cealaltă parte.

Condiția unu: mai are nevoie ceva de partea îndepărtată?

Dacă răspunsul este nu, instalați clientul în invitat și opriți proiectarea. Nimic din acea alegere nu cere gateway-ul administrat și nimic nu transformă VM-ul într-un gateway pentru vecinii săi. Adăugați o rută în interiorul unui singur sistem de operare.

Dacă răspunsul este da, sau probabil da în cursul unui an, tratați-l acum ca proiectare de rețea. Alte VM-uri ajung la un VM de tranzit doar când tabelul de rute al subrețelei le trimite acolo și NIC-ul acceptă traficul redirecționat, deci munca este tabele de rute și permisiuni de redirecționare, nu o altă instalare de client.

Condiția doi: puteți păstra calea de administrare?

Un client VPN care instalează o rută largă poate captura calea pe care administrați VM-ul. Dacă lista de destinații a tunelului se suprapune cu rețeaua de administrare, sesiunea SSH sau RDP cade în momentul în care clientul se conectează, iar corectarea trebuie aplicată prin consola serială sau printr-o reconstrucție.

Verificați înainte și după. În Linux, ip route get <management-ip> arată ce interfață și ce sursă ar folosi nucleul acum; comparați cu răspunsul cât timp tunelul este activ. Un tunel divizat cu o listă explicită de destinații este mai ușor de apărat decât o rută implicită, și de obicei este exact ce are nevoie încărcarea de lucru.

Condiția trei: cine îl patchuiește la miezul nopții?

Un client invitat înseamnă sistemul dumneavoastră de operare, versiunea clientului și certificatele. Este în regulă când deja operați VM-ul și ciclul său de patch-uri. Este o afacere proastă când VM-ul există doar ca să țină tunelul. Numărați orele de patch înainte de a numi clientul invitat mai ieftin. O actualizare de client care cere o repornire este o întrerupere pe care ați programat-o pentru o mașină care există ca să țină tunelul în funcțiune.

Gateway-ul administrat mută acea întreținere pe platformă. Rămâneți proprietarul identității, autorizării și căilor de rețea din spate, dar nu reporniți o mașină pentru a aplica o actualizare de client.

Ce nu face gateway-ul administrat

Azure VPN Gateway este un serviciu de conectivitate VNet cu propriile aranjamente site-la-site și punct-la-punct. Nu este o regulă care interzice software VPN în invitat și nu este un substitut direct pentru un client de care are nevoie o singură aplicație.

Ce oferă este o conexiune la nivelul rețelei, accesibilă multor încărcări prin rutare. Ce nu oferă este un tunel folosit doar de un proces pe un singur VM, limitat la identitatea acelui proces. Această limitare nu este un defect pentru care să vă scuzați; exact acesta este sensul proiectării cu client invitat. O aplicație, o rută, un set de acreditări, niciun efect asupra celorlalte VM-uri din subrețea.

Deci comparația nu este administrat contra software. Este conectivitate la scară de rețea contra conectivitate la scară de proces, iar a doua este legitimă când doar un proces are nevoie de ea.

Planificați calea de creștere înainte de a avea nevoie

Dacă cerința crește de la o VM la o subrețea, reconstruiți proiectarea în loc să lărgiți prefixele permise ale clientului. Reutilizarea unei sesiuni convenabile ca router nedocumentat leagă fiecare consumator de durata de viață a acelei VM, de acreditările ei și de fereastra ei de patch.

Punctul de plecare corect, odată ce conexiunea este la scară de rețea și nu de încărcare, este prezentarea generală a Azure VPN Gateway.

Înainte de a alege, scrieți trei rânduri: ce are nevoie de partea îndepărtată, cine administrează VM-ul și cine patchuiește tunelul. Dacă toate trei răspunsurile indică o singură încărcare, un client invitat este proiectarea onestă. Dacă oricare dintre ele indică o subrețea, proiectați acum stratul de rețea.