Jedan Azure VM treba tunel: klijent u gostu ili VPN pristupnik?
Tri uvjeta odlučuju treba li jedan Azure VM pokretati vlastiti VPN klijent ili veza pripada mrežnom sloju.
Jedno radno opterećenje u jednom Azure VM-u 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 nekom drugom stroju trebati taj put. Odgovorite prvo na to i ostatak arhitekture obično se sam izabere. Pogriješite li, naslijedit ćete VM koji je tiho postao usmjerivač koji nitko nije dokumentirao.
Dva posla koja izgledaju isto
VM može biti krajnja točka ili tranzitna točka, a razlika nije u softveru koji instalirate nego u tome tko koristi tunel. Kao krajnja točka, gost pokreće klijent za vlastite procese. Kao tranzitna točka, prosljeđuje pakete drugih radnih opterećenja, što ga čini dijelom vaše mrežne topologije.
| Zadatak | Što VM radi | Tko posjeduje usmjeravanje |
|---|---|---|
| Krajnja točka opterećenja | Pokreće podržani klijent za vlastite procese | Rute gosta biraju odobrena odredišta |
| Tranzitni uređaj | Prosljeđuje druga opterećenja u vezu sa lokacijom | Tablice ruta podmreže, prosljeđivanje NIC-a, pravila gosta i povratni putovi |
Većina zahtjeva za jedan VM prvi je posao u jeziku drugoga. Netko kaže „VM je naš VPN“, a misli da jedna aplikacija na njemu mora doći do baze podataka na drugoj strani.
Uvjet prvi: treba li još nečemu druga strana?
Ako je odgovor ne, instalirajte klijent u gosta i prestanite projektirati. Ništa u tom izboru ne zahtijeva upravljani pristupnik i ništa ga ne čini pristupnikom za njegove susjede. Dodajete rutu unutar jednog operacijskog sustava.
Ako je odgovor da, ili vjerojatno da u roku od godine, tretirajte to sada kao mrežni dizajn. Drugi VM-ovi dolaze do tranzitnog VM-a samo kad ih tablica ruta podmreže pošalje tamo i NIC prihvati proslijeđeni promet, pa je posao tablice ruta i dopuštenja za prosljeđivanje, a ne još jedna instalacija klijenta.
Uvjet drugi: možete li zadržati administrativni put?
VPN klijent koji instalira široku rutu može preuzeti put kojim administrirate VM. Ako se popis odredišta tunela preklapa s upravljačkom mrežom, vaša SSH ili RDP sesija pada u trenutku kad se klijent poveže, a ispravak se mora primijeniti preko serijske konzole ili ponovne izgradnje.
Provjerite prije i poslije. Na Linuxu ip route get <management-ip> pokazuje koje bi sučelje i izvor jezgra sada upotrijebila; usporedite to s odgovorom dok je tunel aktivan. Podijeljeni tunel s eksplicitnim popisom odredišta lakše je braniti od zadane rute i obično je ono što opterećenju stvarno treba.
Uvjet treći: tko ga krpa u ponoć?
Klijent u gostu vaš je operacijski sustav, vaša verzija klijenta i vaši certifikati. To je u redu kad već vodite VM i njegov ciklus krpanja. To je loša trgovina kad VM postoji samo da drži tunel. Prebrojite sate krpanja prije nego klijent u gostu proglasite jeftinijim. Nadogradnja klijenta koja zahtijeva ponovno pokretanje prekid je koji ste zakazali za stroj koji postoji da bi tunel ostao podignut.
Upravljani pristupnik premješta to održavanje na platformu. I dalje posjedujete identitet, autorizaciju i mrežne putove iza njega, ali ne ponovno pokrećete stroj da biste primijenili ažuriranje klijenta.
Što upravljani pristupnik ne radi
Azure VPN Gateway usluga je povezivanja VNet-a s vlastitim aranžmanima lokacija-lokacija i točka-lokacija. Nije pravilo koje zabranjuje VPN softver u gostu i nije izravna zamjena za klijent koji jednoj aplikaciji treba.
Ono što daje jest veza na mrežnom sloju, dostupna mnogim opterećenjima kroz usmjeravanje. Ono što ne daje jest 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 se treba ispričavati; upravo je to smisao dizajna s klijentom u gostu. Jedna aplikacija, jedna ruta, jedan skup vjerodajnica, bez utjecaja na ostale VM-ove u podmreži.
Dakle, usporedba nije upravljano protiv softvera. To je povezanost u opsegu mreže protiv povezanosti u opsegu procesa, a druga je legitimna kad je treba samo jedan proces.
Isplanirajte put rasta prije nego vam zatreba
Ako zahtjev naraste s jednog VM-a na podmrežu, ponovno izgradite dizajn umjesto da proširujete dopuštene prefikse klijenta. Ponovno korištenje prikladne sesije kao nedokumentiranog usmjerivača veže svakog korisnika za životni vijek tog VM-a, njegove vjerodajnice i njegov prozor krpanja.
Ispravna početna točka, kad veza postane mrežnog, a ne opterećenjskog opsega, jest pregled Azure VPN Gateway.
Prije nego što odaberete, napišite tri retka: što treba drugu stranu, tko administrira VM i tko krpa tunel. Ako sva tri odgovora pokazuju na jedno opterećenje, klijent u gostu iskren je dizajn. Ako bilo koji od njih pokazuje na podmrežu, projektirajte mrežni sloj sada.