Statiska IP Azure P2S VPN: kāpēc mainās klienta adrese

Katrs Azure point-to-site klients autentifikācijas laikā saņem adresi no kopas un patur to tikai tik ilgi, cik ilgi pastāv šis savienojums. Nav ne rezervāciju tabulas, ne kartējuma pa lietotājiem, ne tāda vārtejas iestatījuma, kas nozīmētu „vienmēr dod šim cilvēkam 172.16.0.10“. Tieši šis vienīgais mehānisms izskaidro abus simptomus, ar kuriem cilvēki saskaras vēlāk: NSG noteikumu, kas pārstāj atbilst lietotājam, kuram tas iepriekš atbilda, un atļauto sarakstu, kas klusi ielaiž mašīnu, kuru neviens apzināti nav pievienojis. Noteikuma aizstāšana ar gudrāku IP noteikumu nelabo nevienu, jo tas, ko noteikums nosauc, tiek piešķirts no jauna pēc grafika, kuru jūs nekontrolējat.

Kopa ir kapacitāte, nevis identitāte. Tā pastāv, lai vienlaicīgi tuneļi iegūtu unikālas adreses, un tā pārstrādā tās tajā brīdī, kad beidzas noma. Kad tas ir skaidrs, lietderīgais jautājums pārstāj būt „kā man piespraust šo klientu“ un kļūst „pret ko es varu uzrakstīt noteikumu, ko vārteja nepārstrādās“.

Ko vārteja faktiski dara, kad klients pieslēdzas

Vārteja tur konfigurēto klientu adrešu kopu un izturas pret to kā nomu tabulu. Pieslēdzoties tā paņem nākamo brīvo adresi, praksē zemāko pieejamo, un piešķir to tuneļa adapterim, līdz klients atvienojas vai līdz noma beidzas. Izšķir secība, nevis identitāte: kas pēc miera perioda pieslēdzas pirmais, iegūst zemāko adresi, kas tajā brīdī nejauši ir brīva.

Kopas lielums slēpj uzvedību. Laboratorijas kopa, kas ir par vienu vai divām adresēm lielāka nekā testētāju skaits, šķiet deterministiska, jo tas pats klēpjdators parasti katru rītu pieslēdzas tajā pašā secībā. Pievienojiet trešo mašīnu, mainiet kopas lielumu vai atstājiet sesiju pieslēgtu pusdienu laikā, un modelis sabrūk. Adrese nekad nav bijusi stabila; stabila bija rinda.

Jebkura point-to-site konfigurācijas izmaiņa arī atiestata nomu telpu. Cits autentifikācijas veids, mainīta lieluma kopa, jauns kopas diapazons vai vārteja, kas tiek nojaukta un uzcelta no jauna, visi sūta klientus atpakaļ kopā, kas vairs neatbilst viņu vecajām adresēm. Nekas no šīs izmaiņas neaizskar jūsu NSG, tāpēc bojājums izskatās spontāns.

To var novērot apmēram minūtes laikā. Pieslēdzieties, pierakstiet tuneļa adresi klienta savienojuma informācijā, atvienojieties, pieslēdziet otru mašīnu un pēc tam atkal pieslēdziet pirmo. Adrese, ko saņemat atpakaļ, ir atkarīga no tā, ko tur otrā mašīna, un neviens portāla iestatījums neatjaunos iepriekšējo pēc pieprasījuma.

NSG, kas balstīts uz klienta IP, faktiski ir noteikums par savienojuma secību

Noteikums, ko cilvēki raksta vispirms, ir acīmredzamais: ienākošais noteikums uz pārvaldības VM tīkla kartes vai tās apakštīkla, ar VPN klienta iekšējo adresi kā avotu. Tas ir īss, iztur testu tajā dienā, kad tiek uzrakstīts, un neizdodas, tiklīdz kopā ir vairāk nekā viena brīva adrese.

No tā izriet divi atteices veidi, un tikai viens izskatās kā kļūda. Likumīgam lietotājam tiek liegts, jo kāds cits tajā brīdī tur adresi, ko nosauc noteikums, un tas nāk kā kaitinošs atbalsta pieteikums. Vai arī nevēlamam lietotājam tiek ļauts, jo viņš ir mantojis adresi, kurai noteikums vēl uzticas, un tas nenāk kā nekas, līdz kāds neauditē piekļuvi.

Tā kā noteikums seko nomai, faktiskā politika skan „pirmais pieslēgušais cilvēks iegūst pārvaldības piekļuvi“. Tas ir savienojuma secības apraksts, kas ietērpts nodomā, un nekāda noteikumu higiēna to nepadara par nodoma izteiksmi.

Klienta noma un vārtejas adrese ir dažādi objekti

Lielākā daļa apjukuma nāk no viena vārda. Vārtejai ir samērā stabila publiskā IP; klientiem ir privātas adreses no kopas, kas nav stabilas. Vārtejai VPN bez zonu dublēšanas publiskā IP tiek piešķirta dinamiski, taču tā pārdzīvo lieluma maiņu, atiestatīšanu un ikdienas apkopi — tā mainās, kad pati vārteja tiek dzēsta un izveidota no jauna. Zonu dublējošās un zonālās vārtejas SKU izmanto Standard SKU publisko IP, un šim piešķīrumam jābūt statiskam.

Tieši šī stabilitāte ir tas, kas vajadzīgs uz vietas esošajam partnerim tā konfigurācijā, un tā neko nepasaka par atsevišķa klienta identificēšanu. Kad partneris jautā, kādu adresi viņš redzēs, atbilde ir vārtejas publiskā IP site-to-site gadījumā vai kopīgs NAT diapazons — nekad klēpjdatora tuneļa noma.

Grupu kopas dod diapazonu, pret ko ir vērts rakstīt noteikumus

Virtual WAN point-to-site atbalsta lietotāju grupas, un katrai grupai var piešķirt savu klientu adrešu kopu. Dalība tiek noteikta pēc identitātes, tāpēc diapazons, kurā klientam jānonāk, kļūst paredzams: operācijas vienā diapazonā, darbuzņēmēji citā, un diapazons ir kaut kas tāds, ko ugunsmūra vai NSG noteikums var nosaukt bez minēšanas.

Iegūtajai noteikumu kopai ir forma, ko varat pārskatīt:

• viena kopa vienai auditorijai, izmērīta pēc vienlaicīgo sesiju maksimuma, nevis pēc cilvēku skaita;
• grupas dalība tiek pārvaldīta pēc identitātes, nevis rediģējot noteikumus ikreiz, kad kāds pievienojas;
• NSG vai Azure Firewall noteikumi rakstīti pret kopas diapazoniem, nekad pret atsevišķām nomām;
• atsevišķs centrs vai vārteja auditorijām, kurām nekad nav jādala diapazons.

Visas kopas iekļaušana atļauto sarakstā ir godīga, bet rupja: katrs pievienotais klients šajā diapazonā iegūst tādu pašu piekļuvi. Tas ir politikas lēmums, ko ir vērts pateikt skaļi, nevis atklāt pārskatīšanas laikā. Viss, kam vēl vajadzīga atbilde katram cilvēkam, pieder resursam, izmantojot lomu piešķīrumus, nevis pakešu filtram.

Kad izvietojums nevar pāriet uz Virtual WAN

Daudzas vārtejas paliek parastas VPN vārtejas, un pāreja uz Virtual WAN nav nejauša izmaiņa. Praktiskā atbilde ir pārcelt lēmumu par katru lietotāju no pakešu filtra uz kaut ko, kas jau zina, kas ir lietotājs.

Identitāte resursa līmenī ir lētākā versija. Storage, SQL un Key Vault visi atbalsta Entra ID autentifikāciju ar lomu piešķīrumiem lietotājam vai grupai, tāpēc VPN ir tikai jāpierāda tīkla sasniedzamība. Lēciena resursdators ar nosauktiem kontiem dara to pašu administrēšanas darbam, jo resursdators reģistrē cilvēku, un tunelis tikai pārvadā paketes. Klientu reģistrēšana DNS un vārda, nevis numura, atļaušana paceļ noteikumu par vienu slāni augstāk. Lietotnes līmeņa identitāte — sertifikāta subjekts, marķiera apgalvojums, dalība grupā — darbojas, kad izlemt tiek lūgta lietotne, nevis tīkls.

Partnerim, kurš uzstāj uz fiksētu avota adresi, atbilde ir site-to-site vai ExpressRoute ar noteiktu partnera prefiksu. Viņi atļauj partnera prefiksu, adrese, kas parādās viņu pusē, pieder vārtejai, un tā nemainās, kad kāds pārstartē klēpjdatoru.

Pārbaudiet kopu, pirms rediģējat vēl vienu atļauto sarakstu

Divas kopas īpašības izraisa lielāko daļu uzvedības, ko cilvēki piedēvē klientam. Pārāk maza kopa ātri pārstrādā nomas, tāpēc adreses izskatās nemitīgi kustamies, un jebkurš uz adresi balstīts noteikums šķiet neuzticams pēc konstrukcijas. Kopa, kas pārklājas ar vietējiem diapazoniem vai virtuālā tīkla adrešu telpu, rada maršrutēšanas neskaidrību, ko neviena ugunsmūra noteikums nelabo.

Pirms aizskarat noteikumu, lieciet trīs lietas vienā lapā: point-to-site kopu, virtuālā tīkla adrešu telpu un vietējos diapazonus. Tiem nav jāpārklājas, un kopai vajag vietu katram vienlaicīgajam klientam plus rezervi atkārtotiem savienojumiem.

Pēc tam aizveriet ciklu šādā secībā:

• Pieslēdzieties no divām mašīnām abās secībās un salīdziniet adreses; ja tās var apmainīties, neviens uz adresi balstīts noteikums nav drošs.
• Pārbaudiet, vai vārteja ir Virtual WAN; ja tā ir, izmantojiet grupu kopas, nevis noteikumus katram adresei.
• Jautājiet, kas notiek, kad noteikums trāpa nepareizajam cilvēkam; ja atbilde ir piekļuves incidents, pārvietojiet kontroli uz identitāti.
• Pierakstiet, kurš diapazons pieder kurai grupai, tajā pašā krātuvē, kur atrodas NSG definīcijas.
• Pārbaudiet vēlreiz pēc jebkuras kopas, autentifikācijas vai vārtejas izmaiņas, jo šīs izmaiņas pārraksta kartējumu, to nepaziņojot.