Relay ya stream ya Nginx kwa UDP ya OpenVPN: nini kinabadilika

Mteja wako umewekwa kwenye UDP, seva ya Nginx ina kizuizi cha location kinachoelekeza kwenye lango la VPN, na hakuna kinachofika. Hiyo inatarajiwa: location ya HTTP haiwezi kubeba datagram ya UDP, itaitwa jina gani sehemu ya mbele. Nginx inahitaji msikilizaji wa stream kwa hili, na baada ya kuhamisha usanidi huko, seti ya pili ya maelezo huamua kama kikao kitaendelea kuishi.

Tabaka la proksi huja kabla ya anwani

Moduli ya stream ya Nginx hufanya proksi ya TCP na UDP bila kuchanganua HTTP. Moduli yake ya HTTP inatarajia mstari wa ombi, vichwa na jibu, na hakuna kimojawapo katika OpenVPN datagram asilia. Kuchagua tabaka ndiyo uamuzi wa kwanza, na hautegemei kama msikilizaji ni IPv4 au IPv6.

Usanidi unaoonekana kufanya kazi na OpenVPN ya TCP hausemi chochote kuhusu kisa cha UDP. Usafirishaji hapa ni sehemu ya itifaki, si maelezo ya uenezaji.

Msikilizaji na backend

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

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

Hakikisha build ina moduli ya stream kabla ya kuhariri chochote; kifurushi cha usambazaji kinaweza kuigawanya kwenye moduli tofauti, na moduli inayokosekana hutoa hitilafu ya usanidi badala ya handaki. Weka kizuizi katika muktadha mkuu wa usanidi, si ndani ya http, na badilisha anwani ya nyaraka na backend halisi.

Njia zote mbili na ngome zote mbili za moto lazima ziruhusu datagram: njia ya kuelekea msikilizaji na njia kutoka proksi hadi backend. Msikilizaji wa IPv6 pia hauzalishi njia ya IPv4, kwa hiyo ikiwa baadhi ya wateja bado wanatumia IPv4, msikilizaji huyo ni kiingilio tofauti na majaribio yake mwenyewe. Angalia ngome ya moto ya backend yenyewe kutoka anwani ya proksi, si kutoka kwa kompyuta yako ya mkononi.

Muda wa kikao si muda wa ombi

Proksi ya stream huhifadhi hali ya kikao cha UDP na kuiondoa kulingana na muda wake na mipangilio ya jibu. Muda mfupi ulionakiliwa kutoka relay ya DNS haufai kwa VPN inayotarajia kubadilishana datagram kwa masaa, na hitilafu huonekana kama muunganisho unaokufa kimya badala ya ule unaokataa kuanza.

Soma proxy_timeout halisi ya uenezaji na mpangilio wowote wa kuhesabu majibu, kisha ulinganishe na tabia ya keepalive ambayo VPN hutumia kwa kweli. Nambari mbili zilizoandikwa katika faili tofauti na watu tofauti ni hali ya kawaida ya mfumo unaofanya kazi. Nambari mbili ambazo hazijawahi kulinganishwa ni hali ya kawaida ya mfumo unaokwama mara kwa mara. Andika zote mbili kwenye rekodi ya huduma ili ulinganisho ufanyike mara moja, mchana.

Relay inabadilisha nini, na haibadilishi nini

Proksi ya stream haimalizi chaneli ya udhibiti ya TLS ya OpenVPN na haibadilishi kuwa HTTPS. Backend inabaki kuwa huduma ya VPN, na uhusiano wa cheti unabaki kati ya mteja na huduma hiyo. Kuhifadhi utambulisho wa backend uliokusudiwa bado ni kazi ya mteja na seva.

Uwakilishaji wa kawaida pia hubadilisha anwani ya chanzo ambayo backend inaona. Kumbukumbu zitaonyesha proksi, na sheria yoyote ya ufikiaji inayotegemea IP kwenye seva ya VPN itatathmini anwani hiyo badala ya ile ya mteja. Kuhifadhi chanzo kwa uwazi ni muundo tofauti wa uelekezaji na ruhusa, si kitu kinachotokana na kuongeza udp kwenye msikilizaji. Panga hilo kabla ya kuandikwa sera inayotegemea anwani ya mteja.

Thibitisha kutoka kwa mteja, si kutoka kwa lango

Ukaguzi wa ndani kwamba lango la UDP limefunguliwa huthibitisha kuwa msikilizaji yupo. Hauthibitishi kwamba mteja anaweza kuthibitisha kupitia hilo au kuendelea kubadilishana trafiki. Kamilisha muunganisho halisi kutoka kwa mteja aliyekubaliwa, kisha thibitisha kuwa kikao kinabaki kwa muda wa kutosha kuwa na maana.

Mtu anaporipoti kuwa Nginx haiwezi UDP kwa sababu kifaa rahisi cha relay kilifanya kazi badala yake, ukweli huo mbili hazihusiani. Kifaa kilithibitisha kuwa backend inajibu; hakikusema chochote kuhusu kile sehemu ya mbele inasaidia. Zote mbili zinaweza kuwa kweli, na moja tu kati yao ni usanidi wa uenezaji huu.