IP static în Azure P2S VPN: de ce se schimbă adresa clientului

Fiecare client Azure point-to-site primește o adresă din pool când se autentifică și o păstrează doar cât durează acea conexiune. Nu există tabel de rezervări, nicio mapare pe utilizator și nicio setare a gateway-ului care să însemne „dă-i mereu acestei persoane 172.16.0.10”. Tocmai acest singur mecanism explică ambele simptome pe care oamenii le întâlnesc mai târziu: o regulă NSG care nu mai corespunde unui utilizator căruia îi corespundea înainte, și o listă de permisiuni care admite în tăcere o mașină pe care nimeni nu a adăugat-o intenționat. Înlocuirea regulii cu o regulă IP mai isteață nu repară niciuna dintre ele, pentru că ceea ce numește regula este realocat după un program pe care nu îl controlați.

Pool-ul este capacitate, nu identitate. Există pentru ca tunelurile simultane să primească adrese unice și le reciclează în momentul în care un contract de închiriere se termină. Odată ce acest lucru este clar, întrebarea utilă încetează să fie „cum fixez acest client” și devine „împotriva a ce pot scrie o regulă pe care gateway-ul nu o va recicla”.

Ce face de fapt gateway-ul când un client se conectează

Gateway-ul păstrează pool-ul de adrese de client configurat și îl tratează ca pe un tabel de închirieri. La conectare ia următoarea adresă liberă, în practică cea mai mică disponibilă, și o atribuie adaptorului de tunel până când clientul se deconectează sau închirierea expiră. Ordinea decide, nu identitatea: cine se reconectează primul după o perioadă liniștită primește cea mai mică adresă care se întâmplă să fie liberă în acel moment.

Dimensiunea pool-ului ascunde comportamentul. Un pool de laborator cu una sau două adrese mai mare decât numărul de testeri pare determinist, pentru că același laptop tinde să se reconecteze în aceeași ordine în fiecare dimineață. Adaugă o a treia mașină, redimensionează pool-ul sau lasă o sesiune conectată peste prânz, și modelul se rupe. Adresa nu a fost niciodată stabilă; coada era.

Orice modificare a configurației point-to-site resetează și spațiul de închirieri. Un alt tip de autentificare, un pool redimensionat, un interval nou de pool sau un gateway demolat și reconstruit trimit toți clienții înapoi într-un pool care nu mai corespunde adreselor lor vechi. Nimic din acea modificare nu atinge NSG-ul dvs., de aceea defecțiunea pare spontană.

Puteți vedea acest lucru în circa un minut. Conectați-vă, notați adresa tunelului în detaliile conexiunii clientului, deconectați-vă, conectați o a doua mașină, apoi reconectați prima. Adresa pe care o primiți înapoi depinde de ce ține a doua mașină, iar nicio setare din portal nu o va restabili pe cea anterioară la cerere.

Un NSG bazat pe IP-ul clientului este de fapt o regulă despre ordinea conexiunilor

Regula pe care oamenii o scriu prima este cea evidentă: o regulă de intrare pe placa de rețea a VM-ului de administrare sau pe subrețeaua acestuia, cu adresa internă a clientului VPN ca sursă. Este scurtă, trece testul în ziua în care este scrisă și eșuează de îndată ce pool-ul are mai mult de o adresă liberă.

Din aceasta decurg două moduri de eșec, și doar unul arată ca un defect. Un utilizator legitim este refuzat pentru că altcineva deține în acel moment adresa pe care o numește regula, iar asta ajunge ca un tichet de suport enervant. Sau un utilizator neintenționat este admis pentru că a moștenit o adresă în care regula încă are încredere, iar asta nu ajunge ca nimic până când cineva nu auditează accesul.

Deoarece regula urmează închirierea, politica efectivă sună astfel: „prima persoană care se conectează primește acces de administrare”. Aceasta este o descriere a ordinii conexiunilor îmbrăcată în intenție, și nicio igienă a regulilor nu o transformă în expresie a intenției.

Închirierea clientului și adresa gateway-ului sunt obiecte diferite

Cea mai mare parte a confuziei vine dintr-un singur cuvânt. Gateway-ul are o IP publică relativ stabilă; clienții au adrese private din pool care nu sunt stabile. Pentru un gateway VPN care nu este redundant pe zone, IP-ul public este alocat dinamic, dar supraviețuiește unei redimensionări, unei resetări și întreținerii de rutină — se schimbă când gateway-ul însuși este șters și recreat. SKU-urile de gateway redundante pe zone și zonale folosesc o IP publică de SKU Standard, iar acea alocare trebuie să fie statică.

Această stabilitate este ceea ce are nevoie un partener local în configurația sa și nu spune nimic despre identificarea unui client individual. Când un partener întreabă ce adresă va vedea, răspunsul este IP-ul public al gateway-ului în site-to-site, sau un interval NAT partajat — niciodată închirierea tunelului unui laptop.

Pool-urile de grup vă oferă un interval împotriva căruia merită să scrieți reguli

Virtual WAN point-to-site acceptă grupuri de utilizatori, iar fiecărui grup i se poate atribui propriul pool de adrese de client. Apartenența este decisă de identitate, așa că intervalul în care ajunge un client devine previzibil: operațiunile într-un interval, contractanții în altul, iar intervalul este ceva ce o regulă de firewall sau NSG poate numi fără să ghicească.

Setul de reguli rezultat are o formă pe care o puteți revizui:

• un pool pentru fiecare public, dimensionat pentru vârfurile de sesiuni simultane, nu pentru numărul de persoane;
• apartenența la grup gestionată prin identitate, nu prin editarea regulilor de fiecare dată când cineva se alătură;
• reguli NSG sau Azure Firewall scrise împotriva intervalelor de pool, niciodată împotriva închirierilor individuale;
• un hub sau un gateway separat pentru publicurile care nu trebuie să partajeze niciodată un interval.

Punerea unui întreg pool pe lista de permisiuni este onestă, dar grosolană: fiecare client conectat în acel interval primește același acces. Este o decizie de politică ce merită spusă cu voce tare în loc să fie descoperită în timpul unei revizuiri. Orice încă are nevoie de un răspuns pe persoană aparține resursei, prin atribuiri de rol, nu filtrului de pachete.

Când implementarea nu poate trece la Virtual WAN

Multe gateway-uri rămân gateway-uri VPN simple, iar trecerea la Virtual WAN nu este o schimbare lipsită de importanță. Răspunsul practic este să mutați decizia pe utilizator din filtrul de pachete în ceva care știe deja cine este utilizatorul.

Identitatea la nivel de resursă este cea mai ieftină versiune. Storage, SQL și Key Vault acceptă toate autentificarea Entra ID cu atribuiri de rol pe utilizator sau pe grup, așa că VPN-ul trebuie doar să demonstreze accesibilitatea în rețea. Un host de salt cu conturi numite face aceeași muncă pentru activitatea administrativă, pentru că hostul înregistrează persoana, iar tunelul doar transportă pachete. Înregistrarea clienților în DNS și permiterea numelui în locul numărului ridică regula cu un nivel. Identitatea la nivel de aplicație — un subiect de certificat, o afirmație de token, o apartenență la grup — funcționează atunci când aplicația, nu rețeaua, este cea care trebuie să decidă.

Pentru un partener care insistă pe o adresă de sursă fixă, răspunsul este site-to-site sau ExpressRoute cu un prefix de peer definit. Ei permit prefixul de peer, adresa care apare de partea lor aparține gateway-ului și nu se schimbă când cineva repornește un laptop.

Verificați pool-ul înainte de a edita încă o listă de permisiuni

Două proprietăți ale pool-ului cauzează cea mai mare parte a comportamentului pe care oamenii îl pun pe seama clientului. Un pool prea mic reciclează închirierile repede, așa că adresele par să se miște continuu și orice regulă bazată pe adresă pare instabilă prin construcție. Un pool care se suprapune peste intervalele locale sau peste spațiul de adrese al rețelei virtuale creează o ambiguitate de rutare pe care nicio regulă de firewall nu o repară.

Puneți trei lucruri pe o pagină înainte de a atinge o regulă: pool-ul point-to-site, spațiul de adrese al rețelei virtuale și intervalele locale. Nu trebuie să se suprapună, iar pool-ul are nevoie de loc pentru fiecare client simultan plus o marjă pentru reconectări.

Apoi închideți bucla în această ordine:

• Conectați-vă de pe două mașini în ambele ordini și comparați adresele; dacă pot fi schimbate, nicio regulă bazată pe adresă nu este sigură.
• Verificați dacă gateway-ul este Virtual WAN; dacă da, folosiți pool-uri de grup în locul regulilor pe adresă.
• Întrebați ce se întâmplă când o regulă nimerește persoana greșită; dacă răspunsul este un incident de acces, mutați controlul pe identitate.
• Înregistrați ce interval aparține cărei grupe, în același depozit ca definițiile NSG.
• Retestați după orice modificare a pool-ului, a autentificării sau a gateway-ului, pentru că acele modificări rescriu maparea fără să o anunțe.