Nginx stream-relay for OpenVPN UDP: kva det endrar

Klienten din er sett til UDP, Nginx-tenaren har ein location-blokk som peikar på VPN-porten, og ingenting kjem fram. Det er venta: eit HTTP-location kan ikkje bera ein UDP-datagram, kva frontenden no heiter. Nginx treng ein stream-lyttar for dette, og når du flyttar konfigurasjonen dit, avgjer eit andre sett detaljar om ei økt overlever.

Proxy-laget kjem før adressa

Stream-modulen til Nginx proxyar TCP og UDP utan å parse HTTP. HTTP-modulen ventar ei førespurnadslinje, headers og eit svar, og ingenting av det finst i ein native OpenVPN-datagram. Å velje laget er derfor den første avgjerda, og ho er uavhengig av om lyttaren er IPv4 eller IPv6.

Ein konfigurasjon som ser ut til å verke med TCP OpenVPN, seier ingenting om UDP-tilfellet. Transporten er her ein del av protokollen, ikkje ein detalj i utrullinga.

Lyttaren og backenden

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

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

Stadfest at bygget inneheld stream-modulen før du redigerer noko; ein distribusjonspakke kan dela han ut i ein eigen modul, og ein manglande modul gir ein konfigurasjonsfeil i staden for ein tunnel. Legg blokka i hovudkonteksten for konfigurasjon, ikkje inne i http, og byt ut dokumentasjonsadressa med den ekte backenden.

Både rutene og begge brannmurane må tillate datagramma: vegen til lyttaren og vegen frå proxyen til backenden. Ein IPv6-lyttar lagar heller ingen IPv4-veg, så om nokre klientar framleis brukar IPv4, er den lyttaren ein eigen oppføring med si eiga testing. Kontroller eigen brannmur på backenden frå adressa til proxyen, ikkje frå laptopen din.

Økt-tidsavbrot er ikkje førespurnadstidsavbrot

Stream-proxyen held tilstand for ei UDP-økt og kastar han etter tidsavbrotet og svarinnstillingane sine. Eit kort tidsavbrot kopiert frå ein DNS-relay passar dårleg til ein VPN som ventar å utveksle datagram i timar, og feilen viser seg som ei tilkopling som døyr stille, i staden for ei som nektar å starte.

Les den effektive proxy_timeout til utrullinga og kvar innstilling for talet på svar, og samanlikn dei deretter med keepalive-åtferda som VPN-en faktisk brukar. To tal skrivne i ulike filer av ulike menneske er den normale tilstanden til eit system som verkar. To tal som aldri vart samanlikna, er den normale tilstanden til eit system som sviktar av og til. Skriv begge inn i tenesteregisteret slik at samanlikninga skjer éin gong, i dagslys.

Kva reléet endrar, og kva det ikkje endrar

Stream-proxyen avsluttar ikkje TLS-kontrollkanalen til OpenVPN og gjer han ikkje om til HTTPS. Backenden blir verande VPN-tenesta, og sertifikatforholdet blir verande mellom klienten og den tenesta. Å ta vare på den tiltenkte backend-identiteten er framleis jobben til klienten og tenaren.

Vanleg proxy endrar òg kjeldeadressa backenden ser. Loggar vil vise proxyen, og kvar IP-basert tilgangsregel på VPN-tenaren vil vurdere den adressa i staden for klienta si. Gjennomsiktig bevaring av kjelda er eit eige ruting- og privilegiedesign, ikkje noko som følgjer av å leggje til udp på ein lyttar. Planlegg det før ein policy som avheng av klientadressa blir skriven.

Stadfest frå klienten, ikkje frå porten

Ein lokal sjekk på at UDP-porten er open beviser at lyttaren finst. Det beviser ikkje at ein klient kan autentisere gjennom han eller halde fram med å utveksle trafikk. Fullfør ei ekte tilkopling frå ein godkjend klient, og stadfest deretter at økta held lenge nok til å bety noko.

Når nokon rapporterer at Nginx ikkje kan UDP fordi eit enkelt reléverktøy verka i staden, er dei to fakta utan samanheng. Verktøyet beviste at backenden svarar; det sa ingenting om kva frontenden støttar. Begge kan vere sanne, og berre éin av dei er ein konfigurasjon for denne utrullinga.