Statische IP im Azure P2S VPN: Warum sich die Client-Adresse ändert
Azure point-to-site vergibt bei jeder Verbindung die nächste freie Adresse aus dem Pool, eine feste Client-IP gibt es also nicht. Knüpfen Sie den Zugriff stattdessen an Bereiche oder an die Identität.
Jeder Azure point-to-site-Client erhält bei der Authentifizierung eine Adresse aus dem Pool und behält sie nur für die Dauer dieser Verbindung. Es gibt keine Reservierungstabelle, keine Zuordnung pro Benutzer und keine Gateway-Einstellung, die bedeutet „gib dieser Person immer 172.16.0.10“. Genau dieser eine Mechanismus erklärt beide Symptome, auf die man später stößt: eine NSG-Regel, die auf einen Benutzer nicht mehr passt, auf den sie früher passte, und eine Positivliste, die still eine Maschine hereinlässt, die niemand absichtlich hinzugefügt hat. Die Regel durch eine clevere IP-Regel zu ersetzen, behebt keines von beiden, weil das, was die Regel benennt, nach einem Zeitplan neu vergeben wird, den Sie nicht steuern.
Der Pool ist Kapazität, nicht Identität. Er existiert, damit gleichzeitige Tunnel eindeutige Adressen bekommen, und er recycelt sie in dem Moment, in dem ein Lease endet. Ist das klar, lautet die nützliche Frage nicht mehr „wie pinne ich diesen Client fest“, sondern „gegen was kann ich eine Regel schreiben, die das Gateway nicht recycelt“.
Was das Gateway tatsächlich tut, wenn sich ein Client verbindet
Das Gateway hält den konfigurierten Client-Adresspool und behandelt ihn als Lease-Tabelle. Beim Verbinden nimmt es die nächste freie Adresse, praktisch die niedrigste verfügbare, und weist sie dem Tunneladapter zu, bis der Client trennt oder das Lease abläuft. Die Reihenfolge entscheidet, nicht die Identität: Wer sich nach einer Ruhephase zuerst wieder verbindet, bekommt die niedrigste Adresse, die in diesem Moment zufällig frei ist.
Die Poolgröße verbirgt das Verhalten. Ein Laborpool, ein oder zwei Adressen größer als die Zahl der Tester, wirkt deterministisch, weil sich dasselbe Notebook jeden Morgen in derselben Reihenfolge wieder verbindet. Fügen Sie eine dritte Maschine hinzu, ändern Sie die Poolgröße oder lassen Sie eine Sitzung über Mittag verbunden, und das Muster bricht. Die Adresse war nie stabil; die Warteschlange war es.
Jede Änderung an der point-to-site-Konfiguration setzt auch den Lease-Bereich zurück. Ein anderer Authentifizierungstyp, ein anders dimensionierter Pool, ein neuer Poolbereich oder ein Gateway, das abgerissen und neu aufgebaut wird, schicken Clients zurück in einen Pool, der nicht mehr zu ihren alten Adressen passt. Nichts an dieser Änderung berührt Ihre NSG, deshalb wirkt der Bruch spontan.
Sie können es in etwa einer Minute beobachten. Verbinden, die Tunneladresse in den Verbindungsdetails des Clients notieren, trennen, eine zweite Maschine verbinden, dann die erste wieder verbinden. Die Adresse, die Sie zurückbekommen, hängt davon ab, was die zweite Maschine hält, und keine Portaleinstellung stellt die frühere auf Anforderung wieder her.
Eine NSG auf Basis der Client-IP ist in Wahrheit eine Regel über die Verbindungsreihenfolge
Die Regel, die man zuerst schreibt, ist die naheliegende: eine eingehende Regel auf der NIC der Verwaltungs-VM oder auf deren Subnetz, mit der internen Adresse des VPN-Clients als Quelle. Sie ist kurz, sie besteht den Test am Tag des Schreibens und sie versagt, sobald der Pool mehr als eine freie Adresse hat.
Daraus folgen zwei Fehlerbilder, und nur eines sieht wie ein Fehler aus. Ein legitimer Benutzer wird abgewiesen, weil gerade jemand anderes die Adresse hält, die die Regel benennt, was als lästiges Support-Ticket eintrifft. Oder ein unbeabsichtigter Benutzer wird durchgelassen, weil er eine Adresse geerbt hat, der die Regel noch vertraut, was gar nicht eintrifft, bis jemand den Zugriff prüft.
Weil die Regel dem Lease folgt, lautet die effektive Richtlinie „wer sich zuerst verbindet, bekommt Verwaltungszugriff“. Das ist eine Beschreibung der Verbindungsreihenfolge, verkleidet als Absicht, und keine Regelhygiene macht daraus einen Ausdruck von Absicht.
Das Client-Lease und die Gateway-Adresse sind verschiedene Objekte
Der meiste Wirrwarr kommt von einem Wort. Das Gateway hat eine öffentliche IP, die verhältnismäßig stabil ist; Clients haben private Adressen aus dem Pool, die es nicht sind. Bei einem nicht zonenredundanten VPN-Gateway wird die öffentliche IP dynamisch zugewiesen, aber sie übersteht eine Größenänderung, einen Reset und Routinewartung — sie ändert sich, wenn das Gateway selbst gelöscht und neu erstellt wird. Zonenredundante und zonale Gateway-SKUs verwenden eine öffentliche IP der Standard-SKU, und diese Zuweisung muss statisch sein.
Diese Stabilität braucht ein lokaler Peer in seiner Konfiguration, und sie sagt nichts über die Identifizierung eines einzelnen Clients. Wenn ein Partner fragt, welche Adresse er sehen wird, lautet die Antwort die öffentliche IP des Gateways bei site-to-site oder ein gemeinsamer NAT-Bereich — nie das Tunnel-Lease eines Notebooks.
Gruppenpools geben Ihnen einen Bereich, gegen den sich Regeln schreiben lassen
Virtual WAN point-to-site unterstützt Benutzergruppen, und jeder Gruppe kann ein eigener Client-Adresspool zugewiesen werden. Die Mitgliedschaft entscheidet sich über die Identität, also wird der Bereich, in den ein Client fällt, vorhersagbar: Betrieb in einem Bereich, Auftragnehmer in einem anderen, und der Bereich ist etwas, das eine Firewall- oder NSG-Regel ohne Raten benennen kann.
Das resultierende Regelwerk hat eine Form, die Sie prüfen können:
- ein Pool pro Zielgruppe, dimensioniert für Spitzen gleichzeitiger Sitzungen statt für Kopfzahl;
- Gruppenmitgliedschaft über Identität geregelt, nicht durch Bearbeiten von Regeln bei jedem Beitritt;
- NSG- oder Azure-Firewall-Regeln gegen Poolbereiche geschrieben, nie gegen einzelne Leases;
- ein separater Hub oder ein separates Gateway für Zielgruppen, die niemals einen Bereich teilen dürfen.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
Einen ganzen Pool auf die Positivliste zu setzen ist ehrlich, aber grob: jeder verbundene Client in diesem Bereich erhält denselben Zugriff. Das ist eine Richtlinienentscheidung, die man besser laut ausspricht, als sie in einer Prüfung zu entdecken. Alles, was noch eine Antwort pro Person braucht, gehört an die Ressource, über Rollenzuweisungen, nicht an den Paketfilter.
Wenn die Bereitstellung nicht zu Virtual WAN wechseln kann
Viele Gateways bleiben einfache VPN-Gateways, und der Wechsel zu Virtual WAN ist keine beiläufige Änderung. Die praktische Antwort ist, die Entscheidung pro Benutzer vom Paketfilter weg zu etwas zu verlagern, das bereits weiß, wer der Benutzer ist.
Identität auf Ressourcenebene ist die billigste Variante. Storage, SQL und Key Vault unterstützen alle Entra ID-Authentifizierung mit Rollenzuweisungen pro Benutzer oder pro Gruppe, sodass das VPN nur Netzwerkerreichbarkeit nachweisen muss. Ein Sprunghost mit benannten Konten leistet dasselbe für administrative Arbeit, weil der Host den Menschen protokolliert und der Tunnel nur Pakete trägt. Clients in DNS zu registrieren und den Namen statt der Nummer auf die Positivliste zu setzen, hebt die Regel eine Ebene höher. Identität auf Anwendungsebene — ein Zertifikatssubjekt, ein Token-Claim, eine Gruppenmitgliedschaft — funktioniert, wenn nicht das Netzwerk, sondern die Anwendung entscheiden soll.
Für einen Partner, der auf einer festen Quelladresse besteht, lautet die Antwort site-to-site oder ExpressRoute mit einem definierten Peer-Präfix. Sie setzen das Peer-Präfix auf die Positivliste, die Adresse, die auf ihrer Seite erscheint, gehört dem Gateway, und sie ändert sich nicht, wenn jemand ein Notebook neu startet.
Prüfen Sie den Pool, bevor Sie eine weitere Positivliste bearbeiten
Zwei Pool-Eigenschaften verursachen den größten Teil des Verhaltens, das man dem Client anlastet. Ein zu kleiner Pool recycelt Leases schnell, sodass Adressen ständig zu wandern scheinen und jede adressbasierte Regel von Natur aus unzuverlässig wirkt. Ein Pool, der die lokalen Bereiche oder den Adressraum des virtuellen Netzwerks überlappt, erzeugt Routing-Unklarheit, die keine Firewall-Regel repariert.
Bringen Sie drei Dinge auf eine Seite, bevor Sie eine Regel anfassen: den point-to-site-Pool, den Adressraum des virtuellen Netzwerks und die lokalen Bereiche. Sie dürfen sich nicht überlappen, und der Pool braucht Platz für jeden gleichzeitigen Client plus einen Puffer für Wiederverbindungen.
Schließen Sie dann den Kreis in dieser Reihenfolge:
- Verbinden Sie sich von zwei Maschinen in beiden Reihenfolgen und vergleichen Sie die Adressen; wenn sie tauschen können, ist keine adressbasierte Regel sicher.
- Prüfen Sie, ob das Gateway Virtual WAN ist; wenn ja, verwenden Sie Gruppenpools statt Regeln pro Adresse.
- Fragen Sie, was passiert, wenn eine Regel die falsche Person trifft; wenn die Antwort ein Zugriffsvorfall ist, verlagern Sie die Kontrolle auf Identität.
- Halten Sie fest, welcher Bereich zu welcher Gruppe gehört, im selben Repository wie die NSG-Definitionen.
- Testen Sie nach jeder Änderung an Pool, Authentifizierung oder Gateway erneut, weil diese Änderungen die Zuordnung umschreiben, ohne es anzukündigen.