Azure P2S VPN-terugverkeer werkt maar één kant op

Het tunnelpictogram is groen, de NSG lijkt toestemmend, de effectieve routes zien er goed uit, en toch kan de VM geen verbinding terug naar de verbonden client openen. De gebruikelijke aanname is dat een werkende point-to-site-tunnel symmetrisch is: als de client de VM bereikt, bereikt de VM de client. Die aanname is de fout in de redenering, niet in de configuratie. Een tunnel kan één richting van een ongevraagde stroom dragen en de andere laten vallen, en de oplossing hangt af van welke laag hem laat vallen.

Mythe: een verbonden tunnel is een tweerichtingstunnel

Een VPN-tunnel is een beleidspad, geen kabel. Elke richting wordt vergeleken met selectors, routes en filters, en elk daarvan kan de ene richting toestaan terwijl hij de andere blokkeert.

In de praktijk komt asymmetrie zo vaak voor dat de richting in de eerste test hoort, niet in de laatste. De client initieert, de gateway volgt de stroom, en het antwoord volgt de toestand die is gemaakt. Een VM die een nieuwe stroom start, heeft die toestand niet, dus is afhankelijk van een retourpad dat expliciet routeerbaar en toegestaan is. Ontbreekt dat pad, dan sterft de verbindingspoging voordat een applicatie hem ziet.

Test de richting voordat je de bereikbaarheid test

Kies één clientadres, één VM-adres en één protocol. Maak verbinding vanaf de client en noteer het resultaat; start daarna dezelfde test vanaf de VM en noteer die ook. Als de eerste slaagt en de tweede mislukt, werken de clientpool, de gateway-koppeling en het pad van client naar VNet allemaal.

De volgende stap is bewijs, niet meer regels. Controleer de NSG op het VM-subnet in beide richtingen, lees de effectieve routes op de NIC van de VM, en leg pakketten vast op de VM terwijl de client verkeer verstuurt. Een verzoek dat aankomt zonder antwoord is een filter- of retourrouteprobleem; een verzoek dat nooit aankomt is een padprobleem. Beschouw een mislukte ping niet als bewijs dat de VM onbereikbaar is, want een ICMP-beleid kan het antwoord laten vallen terwijl TCP werkt.

Het IKEv2 point-to-site-retourpad is de gebruikelijke verdachte

In het Azure-rapport achter dit artikel kon een client VM's bereiken via IKEv2, maar inkomende ICMP van de VM naar de client mislukte totdat het tunneltype van de gateway werd omgeschakeld naar OpenVPN. De rapporteur stelt dat Microsoft een beperking in het IKEv2 point-to-site-pad heeft bevestigd, waarbij retourverkeer van een VM naar de client niet symmetrisch wordt gerouteerd tenzij de client de sessie is begonnen. IKEv2 leunt op verkeersselectors, en de gateway respecteerde in dat geval de retourrichting niet.

Dat maakt OpenVPN niet algemeen het betere tunneltype. Het maakt tunneltype een variabele in de testmatrix voor deze werkbelasting.

Het wisselen van tunneltype is een dienstwijziging, geen schakelaar. Elke client heeft een compatibel profiel nodig, en de gateway heeft mogelijk een ander certificaat of een andere authenticatie-instelling nodig. Reproduceer het eenrichtingsgedrag met één testclient en één test-VM, wijzig het type volgens een goedgekeurde planning, en herhaal daarna dezelfde richtingstests. Overleeft het gedrag de wissel, dan was het tunneltype niet de oorzaak en heb je het probleem ingeperkt zonder de productie aan te raken.

Mythe: broadcast-ontdekking overschrijdt de VNet-grens

Een tweede aanname faalt om een niet-verwante reden. Een virtueel Azure-netwerk transporteert geen broadcastverkeer, dus een VM kan geen broadcast-frames van een lokaal netwerk ontvangen via een site-to-site- of point-to-site-verbinding. Applicaties die peers via broadcast vinden, zoals oudere bestandsnavigatie of sommige apparaatdetectieprotocollen, zullen de externe kant nooit zien, hoe de routes ook zijn geschreven.

Vervang broadcast-ontdekking door DNS-namen, een adreslijstdienst of een expliciete peerlijst. Heeft de applicatie geen unicast-alternatief, dan heeft het ontwerp een ander ontdekkingsmechanisme nodig, geen bredere tunnel.

Wat te wijzigen, en hoe het te bewijzen

Als de richtingstest alleen op IKEv2 mislukt, noteer dan het tunneltype van de gateway, de clientadrespool en de exacte ICMP- of TCP-test, en beoordeel daarna een goedgekeurd OpenVPN-profiel voor de betrokken clients. Mislukt hij op elk tunneltype, werk dan het retourpad uit: het clientadres moet routeerbaar zijn vanaf het VM-subnet, elke door de gebruiker gedefinieerde route moet naar een geldige volgende hop wijzen, en de firewall van de client moet de inkomende stroom accepteren. Voeg het NSG- en routebewijs toe aan het ticket.

Verifieer met de applicatie, niet met ping. Een geslaagde ICMP-uitwisseling na een wijziging zegt niets over de servicepoort, de authenticatie of de naamresolutie. Herhaal de test na een herverbinding, omdat een client die een ander pooladres krijgt het resultaat kan veranderen. Herhaal hem daarna nog één keer nadat de client heeft geslapen en is gewekt, want juist in een hervatte sessie duikt eenrichtingsgedrag vaak weer op.