Statični IP u Azure P2S VPN-u: zašto se adresa klijenta mijenja

Svaki Azure point-to-site klijent dobije adresu iz skupa kada se autentificira i zadrži je samo dok traje ta veza. Nema tablice rezervacija, nema mapiranja po korisniku i nema postavke pristupnika koja znači „uvijek daj ovoj osobi 172.16.0.10”. Taj jedan mehanizam objašnjava oba simptoma na koja ljudi kasnije nailaze: NSG pravilo koje prestane odgovarati korisniku kojem je prije odgovaralo, i popis dopuštenih koji tiho propušta računalo koje nitko nije namjerno dodao. Zamjena pravila pametnijim IP pravilom ne popravlja nijedno, jer se ono što pravilo imenuje dodjeljuje prema rasporedu koji ne kontrolirate.

Skup je kapacitet, ne identitet. Postoji zato da paralelni tuneli dobiju jedinstvene adrese i reciklira ih u trenutku kada najam završi. Kad je to jasno, korisno pitanje prestaje biti „kako da prikujem ovog klijenta” i postaje „prema čemu mogu napisati pravilo koje pristupnik neće reciklirati”.

Što pristupnik zapravo radi kada se klijent spoji

Pristupnik drži konfigurirani skup adresa klijenata i tretira ga kao tablicu najma. Pri spajanju uzima sljedeću slobodnu adresu, u praksi najnižu dostupnu, i dodjeljuje je adapteru tunela dok se klijent ne odspoji ili dok najam ne istekne. Odlučuje redoslijed, ne identitet: tko se prvi ponovno spoji nakon mirnog razdoblja, dobiva najnižu adresu koja je u tom trenutku slučajno slobodna.

Veličina skupa skriva ponašanje. Laboratorijski skup jednu ili dvije adrese veći od broja testera izgleda determinirano, jer se isto prijenosno računalo obično ponovno spaja istim redoslijedom svako jutro. Dodajte treće računalo, promijenite veličinu skupa ili ostavite sesiju spojenom tijekom ručka i obrazac se raspada. Adresa nikada nije bila stabilna; stabilan je bio red.

Svaka promjena point-to-site konfiguracije također resetira prostor najma. Drugi tip autentifikacije, promijenjena veličina skupa, novi raspon skupa ili pristupnik koji se ruši i ponovno gradi — sve to vraća klijente u skup koji više ne odgovara njihovim starim adresama. Ništa u toj promjeni ne dira vaš NSG, zato kvar izgleda spontano.

To možete promatrati za otprilike minutu. Spojite se, zabilježite adresu tunela u pojedinostima veze klijenta, odspojite se, spojite drugo računalo pa ponovno spojite prvo. Adresa koju dobijete zavisi od toga što drugo računalo drži, i nijedna postavka portala neće na zahtjev vratiti prethodnu.

NSG vezan uz IP klijenta zapravo je pravilo o redoslijedu spajanja

Pravilo koje ljudi prvo napišu je očito: ulazno pravilo na NIC upravljačke VM ili na njezinu podmrežu, s unutarnjom adresom VPN klijenta kao izvorom. Kratko je, prolazi test na dan kada je napisano i prestaje raditi čim skup ima više od jedne slobodne adrese.

Iz toga slijede dva načina kvara, a samo jedan izgleda kao greška. Legitimni korisnik biva odbijen jer netko drugi trenutačno drži adresu koju pravilo imenuje, što dolazi kao neugodan zahtjev podršci. Ili nepredviđeni korisnik biva propušten jer je naslijedio adresu kojoj pravilo još vjeruje, što ne dolazi nikako dok netko ne revidira pristup.

Budući da pravilo slijedi najam, stvarna politika glasi „prva osoba koja se spoji dobiva upravljački pristup”. To je opis redoslijeda spajanja prerušen u namjeru, i nikakva higijena pravila ne čini ga izrazom namjere.

Najam klijenta i adresa pristupnika različiti su objekti

Većina zabune dolazi od jedne riječi. Pristupnik ima javnu IP adresu koja je razmjerno stabilna; klijenti imaju privatne adrese iz skupa koje to nisu. Za VPN pristupnik koji nije zonski redundantan javna se IP adresa dodjeljuje dinamički, ali preživljava promjenu veličine, reset i rutinsko održavanje — mijenja se kada se sam pristupnik izbriše i ponovno stvori. Zonski redundantne i zonalne SKU pristupnika koriste javnu IP adresu Standard SKU, a ta dodjela mora biti statična.

Ta je stabilnost ono što lokalni partner treba u svojoj konfiguraciji i ne govori ništa o identificiranju pojedinačnog klijenta. Kada partner pita koju će adresu vidjeti, odgovor je javna IP adresa pristupnika pod site-to-site ili zajednički NAT raspon — nikada najam tunela prijenosnog računala.

Grupni skupovi daju raspon prema kojem vrijedi pisati pravila

Virtual WAN point-to-site podržava korisničke grupe, a svakoj se grupi može dodijeliti vlastiti skup adresa klijenata. Članstvo se određuje identitetom, pa raspon u koji klijent upadne postaje predvidiv: operacije u jednom rasponu, izvođači u drugom, a raspon je nešto što vatrozid ili NSG pravilo može imenovati bez nagađanja.

Dobiveni skup pravila ima oblik koji možete pregledati:

• jedan skup po publici, dimenzioniran za vršne paralelne sesije, a ne prema broju ljudi;
• članstvo u grupi vodi se identitetom, a ne uređivanjem pravila kad se netko pridruži;
• NSG ili Azure Firewall pravila napisana prema rasponima skupa, nikada prema pojedinačnim najmovima;
• odvojeno središte ili pristupnik za publike koje nikada ne smiju dijeliti raspon.

Stavljanje cijelog skupa na popis dopuštenih iskreno je ali grubo: svaki spojeni klijent u tom rasponu dobiva isti pristup. To je politička odluka koju vrijedi izgovoriti naglas umjesto otkriti tijekom pregleda. Sve što još treba odgovor po osobi pripada resursu, kroz dodjele uloga, a ne filtru paketa.

Kada se implementacija ne može preseliti na Virtual WAN

Mnogi pristupnici ostaju obični VPN pristupnici, a prelazak na Virtual WAN nije beznačajna promjena. Praktičan odgovor je odluku po korisniku premjestiti s filtra paketa na nešto što već zna tko je korisnik.

Identitet na razini resursa najjeftinija je verzija. Storage, SQL i Key Vault svi podržavaju Entra ID autentifikaciju s dodjelama uloga po korisniku ili po grupi, pa VPN samo mora dokazati mrežnu dostupnost. Skokoviti poslužitelj s imenovanim računima radi isti posao za administrativne zadatke, jer poslužitelj bilježi osobu, a tunel samo prenosi pakete. Registriranje klijenata u DNS-u i stavljanje imena umjesto broja na popis dopuštenih pomiče pravilo razinu više. Identitet na razini aplikacije — subjekt certifikata, tvrdnja u tokenu, članstvo u grupi — radi kada se za odluku pita aplikaciju, a ne mrežu.

Partneru koji inzistira na fiksnoj izvornoj adresi odgovor je site-to-site ili ExpressRoute s definiranim prefiksom partnera. Oni stave prefiks partnera na popis dopuštenih, adresa koja se pojavljuje na njihovoj strani pripada pristupniku i ne mijenja se kad netko ponovno pokrene prijenosno računalo.

Provjerite skup prije nego uredite još jedan popis dopuštenih

Dva svojstva skupa uzrokuju većinu ponašanja koje ljudi pripisuju klijentu. Premali skup brzo reciklira najmove, pa se adrese čine stalno pokretnima i svako pravilo temeljeno na adresi izgleda nepouzdano po dizajnu. Skup koji se preklapa s lokalnim rasponima ili s prostorom virtualne mreže stvara dvosmislenost usmjeravanja koju nijedno vatrozidno pravilo ne popravlja.

Stavite tri stvari na jednu stranicu prije nego dotaknete pravilo: point-to-site skup, adresni prostor virtualne mreže i lokalne raspone. Ne smiju se preklapati, a skup treba mjesta za svakog istovremenog klijenta plus rezervu za ponovna spajanja.

Zatim zatvorite petlju ovim redoslijedom:

• Spojite se s dva računala u oba redoslijeda i usporedite adrese; ako se mogu zamijeniti, nijedno pravilo temeljeno na adresi nije sigurno.
• Provjerite je li pristupnik Virtual WAN; ako jest, koristite grupne skupove umjesto pravila po adresi.
• Pitajte što se događa kada pravilo pogodi pogrešnu osobu; ako je odgovor sigurnosni incident, premjestite kontrolu na identitet.
• Zabilježite koji raspon pripada kojoj grupi u istom repozitoriju kao definicije NSG-a.
• Ponovno testirajte nakon svake promjene skupa, autentifikacije ili pristupnika, jer te promjene prepisuju mapiranje bez najave.