Nginx stream-relay til OpenVPN UDP: hvad den ændrer

UDP hører ikke til i et HTTP-location. Flyt det til stream-laget, tilpas sessionens timeout til en VPN, og regn med proxyen som kilde.

Din klient er sat til UDP, Nginx-serveren har en location-blok, der peger på VPN-porten, og der kommer intet frem. Det er forventeligt: et HTTP-location kan ikke bære en UDP-datagram, uanset hvad frontenden kaldes. Nginx har brug for en stream-lytter til dette, og når du flytter konfigurationen derhen, afgør et andet sæt detaljer, om en session overlever.

Proxy-laget kommer før adressen

Nginx' stream-modul proxyer TCP og UDP uden at parse HTTP. Dets HTTP-modul forventer en request-linje, headere og et svar, og intet af det findes i en native OpenVPN-datagram. At vælge laget er derfor den første beslutning, og den er uafhængig af, om lytteren er IPv4 eller IPv6.

En konfiguration, der ser ud til at virke med TCP OpenVPN, siger intet om UDP-tilfældet. Transporten er her en del af protokollen, ikke en detalje i udrulningen.

Lytteren og backenden

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

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

Bekræft, at buildet indeholder stream-modulet, før du redigerer noget; en distributionspakke kan dele det ud i et separat modul, og et manglende modul giver en konfigurationsfejl frem for en tunnel. Læg blokken i den primære konfigurationskontekst, ikke inde i http, og erstat dokumentationsadressen med den rigtige backend.

Både ruterne og begge firewalls skal tillade datagrammerne: vejen til lytteren og vejen fra proxyen til backenden. En IPv6-lytter skaber heller ikke en IPv4-vej, så hvis nogle klienter stadig bruger IPv4, er den lytter en separat post med sin egen test. Kontroller backendens egen firewall fra proxyens adresse, ikke fra din laptop.

Session-timeouts er ikke request-timeouts

Stream-proxyen holder tilstand for en UDP-session og kasserer den efter sine timeout- og svarsindstillinger. En kort timeout kopieret fra en DNS-relay passer dårligt til en VPN, der forventer at udveksle datagrammer i timer, og fejlen viser sig som en forbindelse, der dør stille, frem for en, der nægter at starte.

Læs udrulningens effektive proxy_timeout og enhver indstilling for antal svar, og sammenlign dem derefter med den keepalive-adfærd, VPN'en faktisk bruger. To tal skrevet i forskellige filer af forskellige mennesker er den normale tilstand for et system, der virker. To tal, der aldrig er blevet sammenlignet, er den normale tilstand for et system, der er periodisk ustabilt. Skriv begge ind i serviceregistret, så sammenligningen sker én gang, i dagslys.

Hvad relayen ændrer, og hvad den ikke ændrer

Stream-proxyen afslutter ikke OpenVPN's TLS-kontrolkanal og konverterer den ikke til HTTPS. Backenden forbliver VPN-tjenesten, og certifikatforholdet forbliver mellem klienten og den tjeneste. At bevare den tilsigtede backend-identitet er stadig klientens og serverens opgave.

Almindelig proxyning ændrer også den kildeadresse, backenden ser. Logs vil vise proxyen, og enhver IP-baseret adgangsregel på VPN-serveren vil vurdere den adresse i stedet for klientens. Transparent bevarelse af kilden er et separat routing- og privilegiedesign, ikke noget der følger af at tilføje udp til en lytter. Planlæg det, før en politik, der afhænger af klientadressen, skrives.

Verificer fra klienten, ikke fra porten

En lokal kontrol af, at UDP-porten er åben, beviser, at lytteren findes. Den beviser ikke, at en klient kan godkende gennem den eller blive ved med at udveksle trafik. Gennemfør en rigtig forbindelse fra en godkendt klient, og bekræft derefter, at sessionen holder længe nok til at betyde noget.

Når nogen rapporterer, at Nginx ikke kan UDP, fordi et simpelt relay-værktøj virkede i stedet, er de to fakta uden forbindelse. Værktøjet beviste, at backenden svarer; det sagde intet om, hvad frontenden understøtter. Begge kan være sande, og kun den ene er en konfiguration til denne udrulning.

Relaterede artikler