Nginx stream-relay for OpenVPN UDP: hva det endrer

Klienten din er satt til UDP, Nginx-serveren har en location-blokk som peker på VPN-porten, og ingenting kommer frem. Det er forventet: et HTTP-location kan ikke bære en UDP-datagram, uansett hva frontenden kalles. Nginx trenger en stream-lytter for dette, og når du flytter konfigurasjonen dit, avgjør et andre sett detaljer om en økt overlever.

Proxy-laget kommer før adressen

Nginx' stream-modul proxyer TCP og UDP uten å parse HTTP. HTTP-modulen forventer en forespørselslinje, headere og et svar, og ingenting av det finnes i en native OpenVPN-datagram. Å velge laget er derfor den første beslutningen, og den er uavhengig av om lytteren er IPv4 eller IPv6.

En konfigurasjon som ser ut til å virke med TCP OpenVPN, sier ingenting om UDP-tilfellet. Transporten er her en del av protokollen, ikke en detalj i utrullingen.

Lytteren og backenden

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

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

Bekreft at bygget inneholder stream-modulen før du redigerer noe; en distribusjonspakke kan dele den ut i en egen modul, og en manglende modul gir en konfigurasjonsfeil i stedet for en tunnel. Legg blokken i hovedkonteksten for konfigurasjon, ikke inne i http, og erstatt dokumentasjonsadressen med den ekte backenden.

Både rutene og begge brannmurene må tillate datagrammene: veien til lytteren og veien fra proxyen til backenden. En IPv6-lytter lager heller ikke en IPv4-vei, så hvis noen klienter fortsatt bruker IPv4, er den lytteren en egen oppføring med sin egen testing. Kontroller backendens egen brannmur fra proxyens adresse, ikke fra laptopen din.

Økt-tidsavbrudd er ikke forespørselstidsavbrudd

Stream-proxyen holder tilstand for en UDP-økt og kaster den etter tidsavbruddet og svarinnstillingene sine. Et kort tidsavbrudd kopiert fra en DNS-relay passer dårlig til en VPN som forventer å utveksle datagrammer i timer, og feilen viser seg som en forbindelse som dør stille, i stedet for en som nekter å starte.

Les utrullingens effektive proxy_timeout og enhver innstilling for antall svar, og sammenlign dem deretter med keepalive-atferden som VPN-en faktisk bruker. To tall skrevet i forskjellige filer av forskjellige mennesker er den normale tilstanden til et system som virker. To tall som aldri ble sammenlignet, er den normale tilstanden til et system som svikter av og til. Skriv begge inn i tjenesteregisteret slik at sammenligningen skjer én gang, i dagslys.

Hva reléet endrer, og hva det ikke endrer

Stream-proxyen avslutter ikke OpenVPNs TLS-kontrollkanal og gjør den ikke om til HTTPS. Backenden forblir VPN-tjenesten, og sertifikatforholdet forblir mellom klienten og den tjenesten. Å bevare den tiltenkte backend-identiteten er fortsatt klientens og serverens jobb.

Vanlig proxy endrer også kildeadressen backenden ser. Logger vil vise proxyen, og enhver IP-basert tilgangsregel på VPN-serveren vil vurdere den adressen i stedet for klientens. Transparent bevaring av kilden er et eget ruting- og privilegiedesign, ikke noe som følger av å legge til udp på en lytter. Planlegg det før en policy som avhenger av klientadressen skrives.

Verifiser fra klienten, ikke fra porten

En lokal sjekk på at UDP-porten er åpen beviser at lytteren finnes. Den beviser ikke at en klient kan autentisere gjennom den eller fortsette å utveksle trafikk. Fullfør en ekte tilkobling fra en godkjent klient, og bekreft deretter at økten holder lenge nok til å bety noe.

Når noen rapporterer at Nginx ikke kan UDP fordi et enkelt reléverktøy virket i stedet, er de to fakta uten sammenheng. Verktøyet beviste at backenden svarer; det sa ingenting om hva frontenden støtter. Begge kan være sanne, og bare én av dem er en konfigurasjon for denne utrullingen.