Warum eine Azure-VM mit VPN-Appliance den Rückweg verliert
Eine VPN-Appliance in einer Azure-VM braucht eine abgestimmte UDR, das Weiterleitungsflag der NIC und die Gastrichtlinie. Verfolgen Sie eine einzelne Filialanfrage durch alle drei.
Eine Azure-VM mit einer VPN-Appliance steht in zwei unabhängigen Entscheidungssystemen. Azure entscheidet, wo ein Paket ein Subnetz verlässt, über Routentabellen und die Weiterleitungseinstellung der NIC. Das Betriebssystem der Appliance entscheidet, ob es das entschlüsselte Paket weiterleitet. Ein Tunnel, der einwandfrei hochkommt, kann am zweiten System immer noch scheitern, und dort enden die meisten dieser Bereitstellungen.
Drei Eigentümer eines Pfades
Nehmen Sie ein Filialnetz von 192.168.50.0/24 und ein Workload-Subnetz von 10.0.10.0/24, mit der Appliance unter 10.0.0.4 im eigenen Subnetz. Eine einzige Anfrage berührt drei separate Konfigurationen.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Jede Zeile gehört in den meisten Organisationen einem anderen Team, weshalb dieser Fehler meist als drei Tickets statt als eines ankommt.
Die Route, die auf die Appliance zeigt
Verknüpfen Sie eine Routentabelle mit dem Workload-Subnetz und geben Sie dem Filialpräfix einen nächsten Hop vom Typ Virtual appliance mit 10.0.0.4 als Adresse. Verwenden Sie die erreichbare private Adresse der Appliance, niemals ihren öffentlichen VPN-Einstiegspunkt. Der nächste Hop muss eine Adresse sein, die das Workload-Subnetz bereits erreichen kann. Lassen Sie das übrige Routing des Workloads unangetastet, es sei denn, Sie haben bewusst beschlossen, die Standardroute zu ersetzen.
Halten Sie die Appliance in ihrem eigenen Subnetz und stellen Sie sicher, dass die Route, die Filialverkehr zur Appliance schickt, nicht auch den eigenen ausgehenden Pfad der Appliance einfängt. Eine solche Schleife sieht aus wie ein gesunder Tunnel ohne Antworten, und das ist um 2 Uhr nachts sehr unangenehm zu debuggen.
Das NIC-Flag, das alle vergessen
Azure hat eine IP-Weiterleitungseinstellung pro NIC, und sie ist standardmäßig aus. Sie existiert, weil eine weiterleitende NIC Pakete empfängt, die an etwas anderes adressiert sind, und sie stillschweigend zu verwerfen ist die sichere Voreinstellung für alle anderen.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true schaltet sie für eine Schnittstelle ein. Microsofts Anleitung zur Weiterleitung auf der NIC verlangt die Einstellung auf jeder angeschlossenen NIC, die Verkehr weiterleitet, also braucht eine Appliance mit nur einer NIC sie trotzdem auf dieser NIC.
Das Flag ist keine Route und keine Firewallregel. Es einzuschalten erteilt Erlaubnis und sonst nichts.
Was der Gast mit dem entschlüsselten Paket macht
Wenn der Tunnel endet, trifft der eigene Stack der Appliance die nächste Entscheidung. Auf einem Linux-Gast ist IPv4-Weiterleitung eine Laufzeiteinstellung, und sysctl -w net.ipv4.ip_forward=1 gilt bis zum nächsten Start. Speichern Sie sie stattdessen in einer Datei unter /etc/sysctl.d/ dauerhaft. Eine Appliance eines Herstellers hat ihr eigenes Äquivalent, und Linux-Anweisungen, die in eine Herstellerplattform eingefügt werden, bewirken meist gar nichts.
Die Firewallrichtlinie des Gasts ist wieder separat, ebenso die Netzwerksicherheitsgruppe des Workloads. UDP 500 und 4500 zur öffentlichen Adresse der VM zuzulassen schützt den Tunnel; es sagt nichts darüber, ob eine entschlüsselte Filialanfrage einen Workload-Port erreichen darf.
Verfolgen Sie eine Anfrage und ihre Antwort
Wählen Sie einen erlaubten Flow und verfolgen Sie ihn von Ende zu Ende. Die Filiale braucht eine Route für 10.0.10.0/24 über die Standortverbindung, die Appliance braucht einen Zustellpfad zum Workload-Subnetz, und das Workload-Subnetz braucht eine Rückroute zur Filiale.
Entscheiden Sie früh, ob das Design die Quelladresse der Filiale bewahrt oder übersetzt. NAT verändert, was der Workload sieht, daher sollten seine Zugriffsregeln das Modell beschreiben, das Sie tatsächlich gewählt haben, und nicht eine geratene Gateway-Adresse.
Ein erfolgreicher Handshake beweist ein Glied dieser Kette. Der Pfad ist vollständig, wenn die Antwort durch dieselbe Appliance zurückkommt und die eigene Richtlinie des Workloads es zulässt.