Jedan Azure VM treba tunel: klijent u gostu ili VPN gateway?
Tri uslova odlučuju da li jedan Azure VM treba da pokreće sopstveni VPN klijent ili veza pripada mrežnom sloju.
Jedno radno opterećenje u jednom Azure VM mora doći do privatne mreže kroz tunel. Pitanje koje odlučuje o dizajnu nije koji je VPN proizvod bolji, nego hoće li ikada nekoj drugoj mašini trebati taj put. Odgovorite prvo na to i ostatak arhitekture se obično sam izabere. Pogrešite li, nasledićete VM koja je tiho postala ruter koji niko nije dokumentovao.
Dva posla koja izgledaju isto
VM može biti krajnja tačka ili tranzitna tačka, a razlika nije u softveru koji instalirate nego u tome ko koristi tunel. Kao krajnja tačka, gost pokreće klijent za sopstvene procese. Kao tranzitna tačka, prosleđuje pakete drugih radnih opterećenja, što ga čini delom vaše mrežne topologije.
| Zadatak | Šta VM radi | Ko poseduje rutiranje |
|---|---|---|
| Krajnja tačka opterećenja | Pokreće podržani klijent za sopstvene procese | Rute gosta biraju odobrene destinacije |
| Tranzitni uređaj | Prosleđuje druga opterećenja u vezu sa lokacijom | Tabele ruta podmreže, prosleđivanje NIC-a, politika gosta i povratni putevi |
Većina zahteva za jedan VM je prvi posao u jeziku drugog. Neko kaže „VM je naš VPN“, a misli da jedna aplikacija na njemu mora doći do baze podataka na drugoj strani.
Uslov prvi: treba li još nečemu druga strana?
Ako je odgovor ne, instalirajte klijent u gosta i prestanite da projektujete. Ništa u tom izboru ne zahteva upravljani gateway i ništa u njemu ne čini VM gatewayem za njegove susede. Dodajete rutu unutar jednog operativnog sistema.
Ako je odgovor da, ili verovatno da u roku od godine, tretirajte to sada kao mrežni dizajn. Drugi VM-ovi dolaze do tranzitnog VM-a samo kada ih tabela ruta podmreže pošalje tamo i NIC prihvati prosleđeni saobraćaj, pa je posao tabele ruta i dozvole za prosleđivanje, a ne još jedna instalacija klijenta.
Uslov drugi: možete li da zadržite administrativni put?
VPN klijent koji instalira široku rutu može preuzeti put kojim administrirate VM. Ako se lista destinacija tunela preklapa sa upravljačkom mrežom, vaša SSH ili RDP sesija pada u trenutku kada se klijent poveže, a ispravka mora da se primeni preko serijske konzole ili ponovne izgradnje.
Proverite pre i posle. Na Linuxu ip route get <management-ip> pokazuje koji bi interfejs i izvor kernel sada koristio; uporedite to sa odgovorom dok je tunel aktivan. Podeljeni tunel sa eksplicitnom listom destinacija lakše je braniti od podrazumevane rute i obično je ono što opterećenju zaista treba.
Uslov treći: ko ga peče u ponoć?
Klijent u gostu je vaš operativni sistem, vaša verzija klijenta i vaši sertifikati. To je u redu kada već upravljate VM-om i njegovim ciklusom peča. To je loša trgovina kada VM postoji samo da drži tunel. Prebrojte sate pečovanja pre nego što klijent u gostu proglasite jeftinijim. Nadogradnja klijenta koja zahteva restart je prekid koji ste zakazali za mašinu koja postoji da bi tunel ostao aktivan.
Upravljani gateway premešta to održavanje na platformu. I dalje posedujete identitet, autorizaciju i mrežne puteve iza njega, ali ne restartujete mašinu da biste primenili ažuriranje klijenta.
Šta upravljani gateway ne radi
Azure VPN Gateway je usluga povezivanja VNet-a sa sopstvenim aranžmanima lokacija-lokacija i tačka-lokacija. To nije pravilo koje zabranjuje VPN softver u gostu i nije direktna zamena za klijent koji jednoj aplikaciji treba.
Ono što daje jeste veza na mrežnom sloju, dostupna mnogim opterećenjima kroz rutiranje. Ono što ne daje jeste tunel koji koristi samo jedan proces na jednom VM-u i koji je ograničen na identitet tog procesa. To ograničenje nije nedostatak zbog kojeg treba da se izvinjavamo; upravo je to smisao dizajna sa klijentom u gostu. Jedna aplikacija, jedna ruta, jedan set akreditiva, bez uticaja na druge VM-ove u podmreži.
Dakle, poređenje nije upravljano protiv softvera. To je povezanost u obimu mreže protiv povezanosti u obimu procesa, a druga je legitimna kada je treba samo jedan proces.
Isplanirajte put rasta pre nego što vam zatreba
Ako zahtev naraste sa jednog VM-a na podmrežu, ponovo izgradite dizajn umesto da širite dozvoljene prefikse klijenta. Ponovno korišćenje zgodne sesije kao nedokumentovanog rutera vezuje svakog korisnika za životni vek tog VM-a, njegove akreditive i njegov prozor pečovanja.
Ispravna početna tačka, kada veza postane mrežnog a ne opterećenjskog obima, jeste pregled Azure VPN Gateway.
Pre nego što izaberete, napišite tri reda: šta treba drugu stranu, ko administrira VM i ko pečuje tunel. Ako sva tri odgovora pokazuju na jedno opterećenje, klijent u gostu je iskren dizajn. Ako bilo koji od njih pokazuje na podmrežu, projektujte mrežni sloj sada.