Nginx stream-relay för OpenVPN UDP: vad det ändrar

UDP hör inte hemma i ett HTTP-location. Flytta det till stream-lagret, dimensionera sessionstidsgränsen för en VPN och räkna med att proxyn blir källan.

Din klient är inställd på UDP, Nginx-servern har ett location-block som pekar på VPN-porten, och ingenting kommer fram. Det är väntat: ett HTTP-location kan inte bära ett UDP-datagram, vad frontend än kallas. Nginx behöver en stream-lyssnare för detta, och när du flyttar konfigurationen dit avgör en andra uppsättning detaljer om en session överlever.

Proxy-lagret kommer före adressen

Nginx stream-modul proxar TCP och UDP utan att tolka HTTP. Dess HTTP-modul förväntar sig en begäranderad, rubriker och ett svar, och inget av det finns i ett inbyggt OpenVPN-datagram. Att välja lager är därför det första beslutet, och det är oberoende av om lyssnaren är IPv4 eller IPv6.

En konfiguration som ser ut att fungera med TCP OpenVPN säger ingenting om UDP-fallet. Transporten är här en del av protokollet, inte en detalj i utrullningen.

Lyssnaren och backend

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

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

Bekräfta att bygget innehåller stream-modulen innan du redigerar något; ett distributionspaket kan dela ut den i en separat modul, och en saknad modul ger ett konfigurationsfel i stället för en tunnel. Lägg blocket i huvudkontexten för konfiguration, inte inuti http, och ersätt dokumentationsadressen med den riktiga backenden.

Både rutterna och båda brandväggarna måste tillåta datagrammen: vägen till lyssnaren och vägen från proxyn till backenden. En IPv6-lyssnare skapar inte heller en IPv4-väg, så om vissa klienter fortfarande använder IPv4 är den lyssnaren en separat post med egen testning. Kontrollera backendens egen brandvägg från proxyns adress, inte från din laptop.

Sessionstidsgränser är inte begärandetidsgränser

Stream-proxyn håller tillstånd för en UDP-session och kastar det enligt sin tidsgräns och sina svarsinställningar. En kort tidsgräns kopierad från en DNS-relay passar dåligt för en VPN som förväntar sig att utbyta datagram i timmar, och felet visar sig som en anslutning som dör tyst i stället för en som vägrar starta.

Läs utrullningens effektiva proxy_timeout och alla inställningar för antal svar, och jämför dem sedan med det keepalive-beteende som VPN faktiskt använder. Två tal skrivna i olika filer av olika människor är det normala tillståndet för ett system som fungerar. Två tal som aldrig jämfördes är det normala tillståndet för ett system som fallerar ibland. Skriv in båda i tjänsteregistret så att jämförelsen sker en gång, i dagsljus.

Vad relayen ändrar och vad den inte ändrar

Stream-proxyn avslutar inte OpenVPNs TLS-kontrollkanal och gör inte om den till HTTPS. Backenden förblir VPN-tjänsten, och certifikatförhållandet stannar mellan klienten och den tjänsten. Att bevara den avsedda backend-identiteten är fortfarande klientens och serverns jobb.

Vanlig proxyning ändrar också den källadress som backenden ser. Loggar kommer att visa proxyn, och varje IP-baserad åtkomstregel på VPN-servern bedömer den adressen i stället för klientens. Transparent bevarande av källan är en separat design för routning och behörigheter, inte något som följer av att lägga till udp på en lyssnare. Planera det innan en policy som beror på klientadressen skrivs.

Verifiera från klienten, inte från porten

En lokal kontroll att UDP-porten är öppen bevisar att lyssnaren finns. Den bevisar inte att en klient kan autentisera sig genom den eller fortsätta utbyta trafik. Slutför en riktig anslutning från en godkänd klient och bekräfta sedan att sessionen håller tillräckligt länge för att betyda något.

När någon rapporterar att Nginx inte kan UDP eftersom ett enkelt relay-verktyg fungerade i stället, hänger de två fakta inte samman. Verktyget bevisade att backenden svarar; det sade ingenting om vad frontend stöder. Båda kan vara sanna, och bara en av dem är en konfiguration för den här utrullningen.

Relaterade artiklar