Staattinen IP Azure P2S VPN:ssä: miksi asiakkaan osoite vaihtuu

Jokainen Azure point-to-site -asiakas saa osoitteen altaasta tunnistautuessaan ja pitää sitä vain kyseisen yhteyden ajan. Ei ole varataulua, ei käyttäjäkohtaista mappausta eikä yhdyskäytävän asetusta, joka tarkoittaisi „anna tälle henkilölle aina 172.16.0.10“. Juuri tämä yksi mekanismi selittää molemmat oireet, joihin ihmiset myöhemmin törmäävät: NSG-sääntö, joka lakkaa täsmäämästä käyttäjään, johon se ennen täsmäsi, ja sallittujen luettelo, joka päästää hiljaa sisään koneen, jota kukaan ei tarkoituksella lisännyt. Säännön korvaaminen älykkäämmällä IP-säännöllä ei korjaa kumpaakaan, koska se, minkä sääntö nimeää, jaetaan uudelleen aikataululla, jota et hallitse.

Allas on kapasiteettia, ei identiteettiä. Se on olemassa, jotta samanaikaiset tunnelit saavat ainutlaatuiset osoitteet, ja se kierrättää ne heti, kun vuokra päättyy. Kun tämä on selvää, hyödyllinen kysymys lakkaa olemasta „miten naulitsen tämän asiakkaan“ ja muuttuu muotoon „mitä vastaan voin kirjoittaa säännön, jota yhdyskäytävä ei kierrätä“.

Mitä yhdyskäytävä todella tekee, kun asiakas yhdistää

Yhdyskäytävä pitää määritettyä asiakasosoiteallasta ja kohtelee sitä vuokratauluna. Yhdistettäessä se ottaa seuraavan vapaan osoitteen, käytännössä alimman saatavilla olevan, ja antaa sen tunnelisovittimelle, kunnes asiakas katkaisee tai vuokra päättyy. Järjestys ratkaisee, ei identiteetti: se, joka yhdistää uudelleen ensimmäisenä rauhallisen jakson jälkeen, saa alimman osoitteen, joka sattuu sillä hetkellä olemaan vapaa.

Altaan koko peittää käyttäytymisen. Laboratorioallas, joka on yhden tai kahden osoitteen suurempi kuin testaajien määrä, näyttää deterministiseltä, koska sama kannettava yleensä yhdistää uudelleen samassa järjestyksessä joka aamu. Lisää kolmas kone, muuta altaan kokoa tai jätä istunto yhdistetyksi lounaan ajaksi, ja kuvio rikkoutuu. Osoite ei ollut koskaan vakaa; jono oli.

Mikä tahansa point-to-site-määrityksen muutos nollaa myös vuokra-alueen. Erilainen todennustyyppi, kooltaan muutettu allas, uusi allasalue tai yhdyskäytävä, joka puretaan ja rakennetaan uudelleen, lähettävät asiakkaat takaisin altaaseen, joka ei enää vastaa heidän vanhoja osoitteitaan. Mikään siinä muutoksessa ei kosketa NSG:täsi, siksi rikkoutuminen näyttää spontaanilta.

Voit nähdä sen noin minuutissa. Yhdistä, kirjaa tunneliosoite asiakkaan yhteystiedoista, katkaise, yhdistä toinen kone ja yhdistä sitten ensimmäinen uudelleen. Takaisin saamasi osoite riippuu siitä, mitä toinen kone pitää hallussaan, eikä mikään portaaliasetus palauta aiempaa pyynnöstä.

Asiakkaan IP:hen sidottu NSG on itse asiassa sääntö yhteysjärjestyksestä

Sääntö, jonka ihmiset kirjoittavat ensin, on ilmeinen: saapuva sääntö hallintavirtuaalikoneen NIC:iin tai sen aliverkkoon, lähteenä VPN-asiakkaan sisäinen osoite. Se on lyhyt, se läpäisee testin kirjoituspäivänä ja epäonnistuu heti, kun altaassa on enemmän kuin yksi vapaa osoite.

Tästä seuraa kaksi vikatilaa, ja vain toinen näyttää bugilta. Laillinen käyttäjä hylätään, koska jollakulla toisella on juuri nyt se osoite, jonka sääntö nimeää, ja se saapuu ärsyttävänä tukipyyntönä. Tai tahaton käyttäjä päästetään sisään, koska hän on perinyt osoitteen, johon sääntö yhä luottaa, eikä se saavu lainkaan ennen kuin joku auditoi käyttöoikeudet.

Koska sääntö seuraa vuokraa, tehollinen käytäntö kuuluu „ensimmäinen yhdistäjä saa hallintakäyttöoikeuden“. Tämä on yhteysjärjestyksen kuvaus tarkoitukseksi puettuna, eikä mikään sääntöhygienia tee siitä tarkoituksen ilmaisua.

Asiakkaan vuokra ja yhdyskäytävän osoite ovat eri objekteja

Suurin osa sekaannuksesta tulee yhdestä sanasta. Yhdyskäytävällä on julkinen IP, joka on suhteellisen vakaa; asiakkailla on altaasta yksityisiä osoitteita, jotka eivät ole. Vyöhykkeellisesti redundantille VPN-yhdyskäytävälle julkinen IP jaetaan dynaamisesti, mutta se kestää koon muutoksen, nollauksen ja rutiinihuollon — se muuttuu, kun yhdyskäytävä itse poistetaan ja luodaan uudelleen. Vyöhykeredundantit ja vyöhykkeelliset yhdyskäytävä-SKU:t käyttävät Standard SKU:n julkista IP:tä, ja sen jaon on oltava staattinen.

Juuri tätä vakautta paikallinen vastapuoli tarvitsee määrityksessään, eikä se kerro mitään yksittäisen asiakkaan tunnistamisesta. Kun kumppani kysyy, minkä osoitteen hän näkee, vastaus on yhdyskäytävän julkinen IP site-to-site-yhteydessä tai jaettu NAT-alue — ei koskaan kannettavan tunnelivuokra.

Ryhmäaltaat antavat alueen, jonka vasten kannattaa kirjoittaa sääntöjä

Virtual WAN point-to-site tukee käyttäjäryhmiä, ja jokaiselle ryhmälle voidaan antaa oma asiakasosoiteallas. Jäsenyys ratkaistaan identiteetillä, joten alue, johon asiakas osuu, muuttuu ennustettavaksi: operaatiot yhdellä alueella, urakoitsijat toisella, ja alue on jotain, jonka palomuuri- tai NSG-sääntö voi nimetä arvaamatta.

Tuloksena olevalla sääntöjoukolla on muoto, jonka voit tarkistaa:

• yksi allas kohderyhmää kohden, mitoitettu samanaikaisten istuntojen huippuun eikä henkilömäärään;
• ryhmäjäsenyys hoidetaan identiteetillä, ei muokkaamalla sääntöjä aina kun joku liittyy;
• NSG- tai Azure Firewall -säännöt kirjoitetaan allasalueita vasten, ei koskaan yksittäisiä vuokria vasten;
• erillinen keskus tai yhdyskäytävä kohderyhmille, joiden ei koskaan pidä jakaa aluetta.

Koko altaan lisääminen sallittujen luetteloon on rehellistä mutta karkeaa: jokainen yhdistetty asiakas sillä alueella saa saman käyttöoikeuden. Se on käytäntöpäätös, joka kannattaa sanoa ääneen sen sijaan, että se löydetään katselmoinnissa. Kaikki, mikä vielä tarvitsee vastauksen henkilöä kohden, kuuluu resurssiin roolimääritysten kautta, ei pakettisuodattimeen.

Kun käyttöönotto ei voi siirtyä Virtual WANiin

Monet yhdyskäytävät pysyvät tavallisina VPN-yhdyskäytävinä, eikä Virtual WANiin siirtyminen ole satunnainen muutos. Käytännön vastaus on siirtää käyttäjäkohtainen päätös pakettisuodattimesta johonkin, joka jo tietää, kuka käyttäjä on.

Resurssitason identiteetti on halvin versio. Storage, SQL ja Key Vault tukevat kaikki Entra ID -todennusta käyttäjä- tai ryhmäkohtaisilla roolimäärityksillä, joten VPN:n tarvitsee vain todistaa verkon tavoitettavuus. Hyppypalvelin nimetyillä tileillä tekee saman työn hallinnolliselle työlle, koska palvelin kirjaa ihmisen ja tunneli kuljettaa vain paketteja. Asiakkaiden rekisteröinti DNS:ään ja nimen salliminen numeron sijaan nostaa säännön yhden kerroksen ylöspäin. Sovelluskerroksen identiteetti — varmenteen subjekti, tokenin väite, ryhmäjäsenyys — toimii, kun päätöksen tekijäksi pyydetään sovellusta, ei verkkoa.

Kumppanille, joka vaatii kiinteää lähdeosoitetta, vastaus on site-to-site tai ExpressRoute määritetyllä vastapuolen etuliitteellä. He sallivat vastapuolen etuliitteen, heidän puolellaan näkyvä osoite kuuluu yhdyskäytävälle, eikä se muutu, kun joku käynnistää kannettavan uudelleen.

Tarkista allas ennen kuin muokkaat seuraavaa sallittujen luetteloa

Kaksi altaan ominaisuutta aiheuttaa suurimman osan käyttäytymisestä, josta ihmiset syyttävät asiakasta. Liian pieni allas kierrättää vuokria nopeasti, joten osoitteet näyttävät liikkuvan jatkuvasti ja mikä tahansa osoitepohjainen sääntö näyttää suunnittelultaan epävakaalta. Allas, joka menee päällekkäin paikallisten alueiden tai virtuaaliverkon osoiteavaruuden kanssa, luo reitityksen epäselvyyttä, jota mikään palomuurisääntö ei korjaa.

Laita kolme asiaa yhdelle sivulle ennen kuin kosket sääntöön: point-to-site-allas, virtuaaliverkon osoiteavaruus ja paikalliset alueet. Ne eivät saa mennä päällekkäin, ja allas tarvitsee tilaa jokaiselle samanaikaiselle asiakkaalle sekä marginaalin uudelleenyhdistämisille.

Sulje sitten silmukka tässä järjestyksessä:

• Yhdistä kahdesta koneesta molemmissa järjestyksissä ja vertaa osoitteita; jos ne voivat vaihtua, mikään osoitepohjainen sääntö ei ole turvallinen.
• Tarkista, onko yhdyskäytävä Virtual WAN; jos on, käytä ryhmäaltaita osoitekohtaisten sääntöjen sijaan.
• Kysy, mitä tapahtuu, kun sääntö osuu väärään henkilöön; jos vastaus on käyttöoikeuspoikkeama, siirrä valvonta identiteettiin.
• Kirjaa, mikä alue kuuluu millekin ryhmälle, samaan tietovarastoon kuin NSG-määritykset.
• Testaa uudelleen jokaisen allas-, todennus- tai yhdyskäytävämuutoksen jälkeen, koska ne muutokset kirjoittavat mappauksen uudelleen ilmoittamatta siitä.