OpenVPN na HTTPS kwenye lango 443: msikilizaji ni wa nani?

Huduma mbili zinaweza zote kujibu kwenye lango 443 bila kushindana kamwe, kwa sababu msikilizaji huamuliwa na usafirishaji, anwani na lango kwa pamoja, si kwa nambari pekee. Weka seva ya wavuti na OpenVPN kwenye mashine moja, na swali pekee linalostahili jibu kwanza ni soketi ipi kila mchakato unaomba kutoka kwa kerneli. Andika orodha hiyo kabla ya kuhariri usanidi, na makosa mengi ya «anwani tayari inatumika» hujieleza yenyewe. Kila kitu baada ya orodha ni chaguo kati ya msikilizaji wa UDP, soketi ya TCP inayoshirikiwa au sehemu ya mbele inayoelekeza kwa itifaki.

Anza na soketi ambayo kila mchakato unaomba

Bind hufaulu au kushindwa kwa utatu huo, kwa hivyo daemoni mbili hugongana tu pale sehemu zote tatu zinapolingana. Ndiyo sababu tovuti kwenye TCP 443 huishi pamoja bila kikomo na msikilizaji wa OpenVPN kwenye UDP 443, na ndiyo sababu kuhamisha mmoja wao kwenda anwani ya pili ya ndani kwenye mwenyeji huyo huyo pia humaliza mjadala. Soma wanaosikiliza walio hai, si faili ambazo zilipaswa kuwatengeneza, kwa sababu include lililopitwa na wakati au faili ya unit iliyosahaulika huishi muda mrefu kuliko uhariri unaoukumbuka.

Endesha ss -lntup kama root na soma kila mstari unaotaja 443, ikiwa ni pamoja na maingizo ya IPv6. Kwa kawaida msikilizaji wa v6 wa wildcard hukubali pia trafiki ya v4, na hivyo ndivyo msikilizaji uliyemsahau huendelea kumiliki lango baada ya kubadilisha faili uliyodhani inahusika. Ikiwa jina la mchakato linakushangaza, punguza matokeo kwa ss -lntup 'sport = :443' kabla ya kugusa chochote.

Badilisha handaki kwenda UDP wakati mtandao unaruhusu

Msikilizaji wa UDP huepuka mgongano kabisa na kwa kawaida ni ukarabati mfupi zaidi, kwa sababu hakuna soketi inayoshirikiwa na hakuna bidhaa ya ziada inayoingia kwenye njia. Lakini si bure. Mitandao mingine ya wateja huacha UDP 443 bila kutuma reset, kwa hivyo handaki huacha kujianzisha badala ya kushindwa kwenye bind, na mtumiaji huripoti kuwa VPN imezimwa bila kosa la kusoma. Msikilizaji wa UDP pia hustahimili kuanzishwa upya kwa tabaka la wavuti, jambo ambalo ni muhimu kwenye mashine ambayo tovuti yake hupelekwa upya mara kwa mara. Jaribu kutoka mtandao ambao watumiaji wameketi, kwa sababu shell kwenye seva inathibitisha tu kwamba seva inajifikia yenyewe.

Badilisha usafirishaji katika usanidi wa seva na katika wasifu wa mteja pamoja. Wasifu unaoendelea kuomba TCP utazunguka katika mizunguko ya kuunganisha upya dhidi ya msikilizaji wa UDP pekee, na hiyo inaonekana kama hitilafu ya mtandao hadi ulinganishe faili mbili.

Acha mchakato wa VPN umiliki TCP 443 na upeleke mengine mbele

Community OpenVPN katika hali ya seva ya TCP husoma baiti za kwanza za muunganisho unaoingia na kupeleka kila kitu ambacho si itifaki yake mwenyewe kwa backend ya HTTPS, na port-share ndiyo maagizo yake. Backend ni seva ya kawaida ya wavuti yenye TLS imewezeshwa, inayotajwa kwa mwenyeji na lango katika agizo hilo, si kwa URL.

port-share 10.0.0.5 8080

Kwenye mashine ambayo tovuti ina anwani ya pili ya kibinafsi, mstari huo hupeleka trafiki isiyo ya VPN kwenda 10.0.0.5:8080, kwa hivyo mwenyeji pepe wa HTTPS lazima afungwe hapo na ngome ya moto lazima iruhusu kuruka kwa ndani. Seva ya wavuti lazima ikamilishe TLS yenyewe, kwa sababu baiti zinazofika ni handshake asilia ya kivinjari na hakuna chochote katikati kimezifungua. Elekeza agizo kwa msikilizaji wa kawaida wa HTTP na kivinjari kitapata kosa la mbinu batili, ambalo husomwa kama tovuti iliyovunjika badala ya backend iliyowekwa vibaya. Agizo linapatikana tu katika hali ya seva ya TCP, na msikilizaji wa UDP hana mkondo wa kukagua.

Kwa kuwa mchakato wa VPN unakubali kila muunganisho, programu ya wavuti huona ombi lililopelekwa likija kutoka moja ya anwani za mwenyeji mwenyewe badala ya kutoka kwa mgeni. Kila kitu kinachohitaji anwani halisi ya mteja kinategemea msaada wa itifaki ya PROXY kwenye backend au sehemu ya mbele inayoiongeza. Kuhamisha backend kwenda anwani nyingine ya ndani hakurudishi anwani ya mgeni; kunabadilisha tu ni anwani zipi za mwenyeji ambazo tovuti hurekodi. Andika kikwazo hicho katika maelezo ya usambazaji kabla ripoti ya uchanganuzi haijafungua swali.

Proksi ya nyuma ni chombo kisichofaa; kipanga njia cha tabaka la nne sivyo

Proksi ya nyuma ya HTTP hukamilisha TLS ili iweze kusoma maombi, kumaanisha haiwezi kupitisha mkondo wa OpenVPN bila kuguswa. Kipanga njia cha tabaka la nne kinachopeleka kwa SNI au kwa ukaguzi wa pakiti ya kwanza kinaweza kusimama mbele ya vyote viwili, mradi hakimalizi kipindi ambacho VPN inategemea. Vifaa viwili vinaonekana sawa kwenye mchoro na hujiendesha tofauti kabisa kwenye soketi.

Access Server ya kibiashara huja na mipangilio yake ya kushiriki lango, na hiyo hailingani moja-kwa-moja na agizo la jamii. Tambua bidhaa na toleo kabla ya kubadilisha mwongozo ulioandikwa kwa lingine. Mpangilio ulionakiliwa na kupuuzwa kwa kimya ni mbaya kuliko kutokuwa na mpangilio, kwa sababu orodha ya wanaosikiliza bado inaonekana kuaminika baada ya hapo.

Jaribu tovuti na handaki kama njia mbili tofauti

Pakia tovuti na unganisha handaki, kisha soma orodha ya wanaosikiliza tena ili kuona ni mchakato upi unamiliki 443 sasa. Ukurasa unaopakiwa hauthibitishi chochote kuhusu VPN, na handaki inayounganishwa haithibitishi chochote kuhusu tovuti, ingawa zote zinatumia nambari moja. Amri tatu hapa chini hukagua soketi inayoshirikiwa, njia ya wavuti na huduma ya VPN kwa mpangilio huo.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Linganisha anwani ya mteja katika kumbukumbu ya ufikiaji ya backend na ile iliyo kwenye kumbukumbu ya VPN kwa wakati huo huo. Ikiwa tovuti inarekodi kila mgeni kama mwenyeji mwenyewe, upelekaji unafanya kazi na utunzaji wa anwani haufanyi kazi. Ikiwa kumbukumbu zote mbili ziko kimya, sehemu ya mbele haikuwahi kukabidhi muunganisho. Vyovyote vile, orodha ya wanaosikiliza huamua nani anakubali soketi, na hiyo ndiyo hoja inayopaswa kuthibitishwa kabla ya kubadilisha faili lingine.

Acha ramani hiyo ya wanaosikiliza kando ya usanidi ili mtu anayefuata kugusa 443 ajue ni mchakato upi unakubali na itifaki nyingine ilienda wapi. Thibitisha umiliki baada ya mabadiliko badala ya kuamini kile ambacho uhariri ulikusudia kufanya.