Azure Punkt-zu-Standort verbindet, aber keine private Ressource antwortet
Verbunden heißt nur, dass der Tunnel steht. Prüfen Sie, was das Gateway übertragen kann, vergleichen Sie die Adressräume, und lösen Sie dann einen Namen auf und testen Sie den Dienst selbst.
Verbunden ist ein Zustand des Tunnels, keine Aussage über Erreichbarkeit. Ein Punkt-zu-Standort-Client kann IKE abschließen, eine Adresse erhalten und trotzdem nichts erreichen, weil das Gateway nur Datenverkehr für Netzwerke weiterleitet, die das VNet bereits kennt. Arbeiten Sie diese fünf Prüfungen der Reihe nach ab und stoppen Sie beim ersten Fehlschlag. Vorzugreifen ist der Weg, auf dem ein DNS-Problem eine Stunde lang als Firewall-Problem behandelt wird.
Die Reihenfolge ist wichtiger als die Liste.
Prüfung 1: entscheiden Sie, was der Tunnel übertragen soll
Azure VPN Gateway beendet den Tunnel und leitet Datenverkehr weiter, der zum VNet gehört; es istkein allgemeiner Internetausgang. Wenn Benutzer erwarten, dass ihr Surfen über Azure verlässt, ist das Design falsch, bevor irgendeine Clienteinstellung ins Spiel kommt. Aktivieren Sie Split Tunneling, damit das lokale Internet den lokalen Weg weiter nutzt, und verwenden Sie eine NAT-Instanz oder einen Standort-zu-Standort-Tunnel, wenn eine feste Ausgangsadresse wirklich erforderlich ist.
Schreiben Sie auf, was der Client erreichen soll, bevor Sie irgendetwas testen. Ohne diese Liste sieht jedes Teilergebnis wie Fortschritt aus.
Prüfung 2: vergleichen Sie die Adressräume vor den Zertifikaten
Überschneidungen werden an den größeren Bereichen beurteilt, daher kollidieren zwei Netzwerke, die auf Subnetzebene unterschiedlich aussehen, dennoch, wenn ihre übergeordneten Blöcke überlappen. Das Gateway-Subnetz muss dediziert und groß genug für die SKU sein, und der Client-Adresspool darf weder mit dem VNet noch mit etwas kollidieren, das über ein Peering erreichbar ist. Ändern Sie den Plan und stellen Sie neu bereit, denn zusätzliche Routen als Ausgleich erzeugen einen Tunnel, der für manche Ziele funktioniert und für andere unerklärlicherweise nicht. Die Bereitstellung schlägt hier laut fehl, was der gute Fall ist.
Authentifizierung ist das nächste Tor. Zertifikat-, RADIUS- und Entra ID-Profile sind nicht austauschbar, und das Clientpaket unterscheidet sich für jedes.
Prüfung 3: lösen Sie einen privaten Namen von innen auf
Der Client behält seinen eigenen Resolver, es sei denn, das heruntergeladene Profil enthält die DNS-Server des VNet, und diese Liste wird beim Herunterladen eingebettet. Fügen Sie einen Forwarder im VNet hinzu, setzen Sie ihn als DNS-Server des VNet und laden Sie das Clientpaket erneut herunter und importieren Sie es. Die Wiederverwendung des alten Pakets testet nur die alte Resolverliste.
Testen Sie zuerst eine Adresse, denn das trennt Routing von Namensauflösung in einem Schritt: Test-NetConnection 10.20.1.4 -Port 3389.
Antwortet die Adresse und der Name nicht, fragen Sie den Resolver direkt mit Resolve-DnsName files.corp.example -Server 10.20.0.4. Wenn beides fehlschlägt, liegt der Fehler nicht bei DNS, und Sie sollten aufhören, DNS-Einstellungen zu ändern. Das Azure-Plattform-DNS unter 168.63.129.16 antwortet nur von innerhalb des VNet, ein Client außerhalb kann diese Adresse also nicht als Resolver nutzen.
Prüfung 4: testen Sie den Dienst hinter dem Tunnel
Ein gesunder Tunnel und ein geschlossener Port sehen vom Client aus identisch aus. Prüfen Sie die Gast-Firewall, dann die Netzwerksicherheitsgruppe am Subnetz oder NIC, dann ob der Dienst auf der privaten Adresse statt nur auf Loopback lauscht. Erlauben Sie den Client-Pool als Quelle, statt eine Regel ins Internet zu öffnen, und denken Sie daran, dass SMB zu Azure Files den Pfad des privaten Endpunkts durch den Tunnel benötigt. Wenn eine Ressource per IP, aber nicht per Name antwortet, gehen Sie zurück zu Prüfung 3, statt das Gateway anzufassen.
Eine Tabelle hält die Schichten beim Arbeiten auseinander:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
Prüfung 5: halten Sie das Profil fest, bevor Sie eskalieren
Schreiben Sie Gateway-Typ, Tunnel-Typ, Authentifizierungsmethode und Client-Betriebssystem ins Ticket. Ein Zertifikat-IKEv2-Profil und ein RADIUS-Profil scheitern aus unterschiedlichen Gründen, und ein Client, der für einen anderen Tunnel-Typ gebaut wurde, verbindet sich nur, wenn das Gateway ein kompatibles Protokoll anbietet.
Für ein kleines Team ist das dauerhafte Design ein VNet, ein DNS-Forwarder und ein dokumentierter Split-Tunnel-Client. Wenn die Anforderung ein fester öffentlicher Ausgang ist, beenden Sie einen Standort-zu-Standort-Tunnel an einer Firewall, die Sie kontrollieren, und leiten Sie den Internetverkehr dorthin, statt vom Punkt-zu-Standort-Gateway etwas zu verlangen, wofür es nie gebaut wurde.