Nginx se stream-aflos vir OpenVPN UDP: wat dit verander

Jou kliënt is op UDP gestel, die Nginx-bediener het 'n location-blok wat na die VPN-poort wys, en niks kom aan nie. Dit is te verwagte: 'n HTTP-location kan nie 'n UDP-datagram dra nie, hoe die voorkant ook al genoem word. Nginx het 'n stream-luisteraar hiervoor nodig, en sodra jy die konfigurasie daarheen skuif, besluit 'n tweede stel besonderhede of 'n sessie oorleef.

Die proxy-laag kom voor die adres

Nginx se stream-module gee TCP en UDP deur sonder om HTTP te ontleed. Die HTTP-module verwag 'n versoekreël, kopvelde en 'n antwoord, waarvan 'n oorspronklike OpenVPN-datagram niks bevat nie. Om die laag te kies is dus die eerste besluit, en dit staan los van of die luisteraar IPv4 of IPv6 is.

'n Konfigurasie wat met TCP OpenVPN blyk te werk, sê niks oor die UDP-geval nie. Die vervoerlaag is hier deel van die protokol, nie 'n besonderheid van die ontplooiing nie.

Die luisteraar en die backend

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

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

Bevestig dat die bou die stream-module insluit voordat jy iets wysig; 'n verspreidingspakket kan dit in 'n aparte module verdeel, en 'n ontbrekende module lewer 'n konfigurasiefout eerder as 'n tonnel. Plaas die blok in die hoofkonfigurasiekonteks, nie binne http nie, en vervang die dokumentasieadres met die werklike backend.

Beide roetes en beide vuurmure moet die datagramme toelaat: die pad na die luisteraar en die pad van die proxy na die backend. 'n IPv6-luisteraar skep ook nie 'n IPv4-pad nie, so as sommige kliënte steeds IPv4 gebruik, is daardie luisteraar 'n aparte inskrywing met sy eie toetsing. Kontroleer die backend se eie vuurmuur vanaf die proxy se adres, nie vanaf jou skootrekenaar nie.

Sessie-tydsperkings is nie versoek-tydsperkings nie

Die stream-proxy hou toestand vir 'n UDP-sessie en gooi dit weg volgens sy tydsperking en responsinstellings. 'n Kort tydsperking wat van 'n DNS-aflos gekopieer is, pas swak by 'n VPN wat verwag om datagramme vir ure uit te ruil, en die fout wys as 'n verbinding wat stil sterf eerder as een wat weier om te begin.

Lees die ontplooiing se effektiewe proxy_timeout en enige respons-telling-instelling, en vergelyk dit dan met die keepalive-gedrag wat die VPN werklik gebruik. Twee getalle wat deur verskillende mense in verskillende lêers geskryf is, is die normale toestand van 'n werkende stelsel. Twee getalle wat nooit vergelyk is nie, is die normale toestand van 'n stelsel wat wisselvallig werk. Skryf albei in die diensrekord sodat die vergelyking een keer plaasvind, in daglig.

Wat die aflos verander, en wat nie

Die stream-proxy beëindig nie OpenVPN se TLS-beheerkanaal nie en skakel dit ook nie na HTTPS om nie. Die backend bly die VPN-diens, en die sertifikaatverhouding bly tussen die kliënt en daardie diens. Om die bedoelde backend-identiteit te bewaar, bly steeds die kliënt en die bediener se taak.

Gewone proxy-werk verander ook die bronadres wat die backend sien. Logs sal die proxy wys, en enige IP-gebaseerde toegangsreël op die VPN-bediener sal daardie adres beoordeel eerder as die kliënt s'n. Deursigtige bronbehoud is 'n aparte roete- en regte-ontwerp, nie iets wat volg uit die byvoeg van udp by 'n luisteraar nie. Beplan daarvoor voordat 'n beleid geskryf word wat van die kliëntadres afhang.

Verifieer vanaf die kliënt, nie vanaf die poort nie

'n Plaaslike kontrole dat die UDP-poort oop is, bewys dat die luisteraar bestaan. Dit bewys nie dat 'n kliënt daardeur kan verifieer of aanhou verkeer uitruil nie. Voltooi 'n werklike verbinding vanaf 'n goedgekeurde kliënt en bevestig dan dat die sessie lank genoeg bly staan om saak te maak.

Wanneer iemand rapporteer dat Nginx nie UDP kan doen nie omdat 'n eenvoudige aflosnutmiddel eerder gewerk het, is die twee feite nie verwant nie. Die nutmiddel het bewys dat die backend antwoord; dit het niks gesê oor wat die voorkant ondersteun nie. Albei kan waar wees, en net een van hulle is 'n konfigurasie vir hierdie ontplooiing.