Uw client staat op UDP, de Nginx-server heeft een location-blok dat naar de VPN-poort wijst, en er komt niets aan. Dat is te verwachten: een HTTP-location kan geen UDP-datagram vervoeren, hoe de frontend ook heet. Nginx heeft hiervoor een stream-listener nodig, en zodra u de configuratie daarheen verplaatst, bepaalt een tweede set details of een sessie overleeft.

De proxy-laag komt vóór het adres

De stream-module van Nginx proxy't TCP en UDP zonder HTTP te parsen. De HTTP-module verwacht een requestregel, headers en een response, en niets daarvan zit in een native OpenVPN-datagram. De laag kiezen is dus de eerste beslissing, en die staat los van of de listener IPv4 of IPv6 is.

Een configuratie die met TCP OpenVPN te werken lijkt, zegt niets over het UDP-geval. Het transport is hier onderdeel van het protocol, geen detail van de uitrol.

De listener en de backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

Controleer of de build de stream-module bevat voordat u iets aanpast; een distributiepakket kan hem in een aparte module splitsen, en een ontbrekende module levert een configuratiefout op in plaats van een tunnel. Zet het blok in de hoofdconfiguratiecontext, niet binnen http, en vervang het documentatieadres door de echte backend.

Zowel de routes als beide firewalls moeten de datagrammen doorlaten: het pad naar de listener en het pad van de proxy naar de backend. Een IPv6-listener maakt ook geen IPv4-pad, dus als sommige clients nog IPv4 gebruiken, is die listener een aparte vermelding met eigen tests. Controleer de firewall van de backend vanaf het adres van de proxy, niet vanaf uw laptop.

Sessietime-outs zijn geen requesttime-outs

De stream-proxy houdt status bij voor een UDP-sessie en gooit die weg volgens zijn time-out en response-instellingen. Een korte time-out die van een DNS-relay is gekopieerd, past slecht bij een VPN die urenlang datagrammen wil uitwisselen, en de fout verschijnt als een verbinding die stilletjes sterft in plaats van een die weigert te starten.

Lees de effectieve proxy_timeout van de uitrol en elke instelling voor het aantal responses, en vergelijk ze met het keepalive-gedrag dat de VPN werkelijk gebruikt. Twee getallen die verschillende mensen in verschillende bestanden hebben geschreven is de normale toestand van een werkend systeem. Twee getallen die nooit zijn vergeleken is de normale toestand van een systeem dat af en toe hapert. Schrijf beide in het servicerecord, zodat de vergelijking één keer plaatsvindt, in daglicht.

Wat de relay verandert, en wat niet

De stream-proxy beëindigt het TLS-controlekanaal van OpenVPN niet en zet het niet om in HTTPS. De backend blijft de VPN-dienst, en de certificaatrelatie blijft tussen de client en die dienst. Het bewaren van de bedoelde backend-identiteit blijft werk voor de client en de server.

Gewoon proxyen verandert ook het bronadres dat de backend ziet. Logs tonen de proxy, en elke op IP gebaseerde toegangsregel op de VPN-server beoordeelt dat adres in plaats van dat van de client. Transparant behoud van de bron is een apart routerings- en privilegieontwerp, niet iets dat volgt uit het toevoegen van udp aan een listener. Plan het voordat een beleid wordt geschreven dat van het clientadres afhangt.

Controleer vanaf de client, niet vanaf de poort

Een lokale controle dat de UDP-poort open is, bewijst dat de listener bestaat. Het bewijst niet dat een client erdoor kan authenticeren of verkeer kan blijven uitwisselen. Voltooi een echte verbinding vanaf een goedgekeurde client en bevestig dan dat de sessie lang genoeg blijft staan om ertoe te doen.

Wanneer iemand meldt dat Nginx geen UDP kan omdat een eenvoudig relay-hulpprogramma in plaats daarvan werkte, hebben die twee feiten niets met elkaar te maken. Het hulpprogramma bewees dat de backend antwoordt; het zei niets over wat de frontend ondersteunt. Beide kunnen waar zijn, en slechts één ervan is een configuratie voor deze uitrol.

Gerelateerde artikelen