Nginx stream-relay foar OpenVPN UDP: wat it feroaret

Jo klient is op UDP ynsteld, de Nginx-tsjinner hat in location-blok dat nei de VPN-poarte wiist, en der komt neat oan. Dat is ferwachte: in HTTP-location kin gjin UDP-datagram drage, hoe't de foarkant ek neamd wurdt. Nginx hat hjirfoar in stream-luisterder nedich, en as jo de konfiguraasje dêrhinne ferpleatse, beslút in twadde set details oft in sesje oerlibbet.

De proxy-laag komt foar it adres

De stream-module fan Nginx proxyet TCP en UDP sûnder HTTP te ûntlijen. De HTTP-module ferwachtet in oanfraachrigel, koppen en in antwurd, en dêrfan sit neat yn in OpenVPN-datagram. De laach kieze is dus it earste beslút, en it is ûnôfhinklik fan oft de luisterder IPv4 of IPv6 is.

In konfiguraasje dy't mei TCP OpenVPN te wurkjen liket, seit neat oer it UDP-gefal. De ferfier is hjir diel fan it protokol, net in detail fan de útfiering.

De luisterder en de backend

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

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

Befêstigje dat de bou de stream-module befettet foardat jo wat bewurkje; in distribúsjepakket kin it yn in aparte module splitsje, en in ûntbrekkende module jout in konfiguraasjeflater ynstee fan in tunnel. Set it blok yn 'e haadkonfiguraasjekontekst, net binnen http, en ferfang it dokumintaasjeadres troch de echte backend.

Sawol beide rûtes as beide firewalls moatte de datagrammen tastean: it paad nei de luisterder en it paad fan 'e proxy nei de backend. In IPv6-luisterder makket ek gjin IPv4-paad, dus as guon klanten noch IPv4 brûke, is dy luisterder in aparte ynfier mei syn eigen testen. Kontrolearje de eigen firewall fan 'e backend fan it adres fan 'e proxy, net fan jo laptop.

Sesje-timeouts binne gjin oanfraach-timeouts

De stream-proxy hâldt steat foar in UDP-sesje en smyt dy fuort neffens syn timeout- en antwurdynstellingen. In koarte timeout kopiearre fan in DNS-relay past min by in VPN dy't ferwachtet oeren datagrammen út te wikseljen, en de flater docht him foar as in ferbining dy't stil stjert, net as ien dy't wegert te starten.

Lês de effektive proxy_timeout fan 'e útfiering en elke ynstelling foar it tellen fan antwurden, en fergelykje se dan mei it keepalive-gedrach dat de VPN echt brûkt. Twa getallen skreaun yn ferskate bestannen troch ferskate minsken is de normale steat fan in systeem dat wurket. Twa getallen dy't nea fergelike binne, is de normale steat fan in systeem dat no en dan útfalt. Skriuw beide yn 'e tsjinstregistraasje, sadat de fergeliking ien kear bart, by deiljocht.

Wat de relay feroaret, en wat net

De stream-proxy beëiniget it TLS-kontrôlekanaal fan OpenVPN net en konvertearret it net nei HTTPS. De backend bliuwt de VPN-tsjinst, en de sertifikaatrelaasje bliuwt tusken de klient en dy tsjinst. It bewarjen fan 'e bedoelde backend-identiteit bliuwt wurk foar de klient en de tsjinner.

Gewoane proxy-wurk feroaret ek it boarneadres dat de backend sjocht. Lokaasjes sille de proxy sjen litte, en elke IP-basearre tagongsregel op 'e VPN-tsjinner sil dat adres beoardielje ynstee fan dat fan 'e klient. Transparant boarnebehâld is in apart ûntwerp foar rûtes en privileges, net eat dat folget út it tafoegjen fan udp oan in luisterder. Plan it foardat in belied skreaun wurdt dat fan it klientadres ôfhinget.

Ferifiearje fan 'e klient, net fan 'e poarte

In pleatslike kontrôle dat de UDP-poarte iepen is, bewiist dat de luisterder bestiet. It bewiist net dat in klient der troch ferifiearje kin of trochgiet mei ferkear útwikselje. Meitsje in echte ferbining fan in goedkarde klient en befêstigje dan dat de sesje lang genôch oanhâldt om fan betsjutting te wêzen.

As immen rapportearret dat Nginx gjin UDP kin om't in ienfâldich relay-ark ynstee wurke, binne de beide feiten ûnferbûn. It ark bewiisde dat de backend antwurdet; it sei neat oer wat de foarkant stipet. Beide kinne wier wêze, en mar ien fan har is in konfiguraasje foar dizze útfiering.