Kile ambacho sehemu ya Proxy katika wasifu wa VPN wa Apple hufanya kwa kweli

Kujaza sehemu ya Proxy katika usanidi wa VPN wa Apple huhisi kana kwamba inapaswa kuelekeza handaki kupitia bandari ya wavuti. Haifanyi hivyo. Sehemu hiyo huchagua mpatanishi wa kiwango cha programu kwa trafiki ambayo programu inayoendana huamua kuituma huko. Lakini muunganisho wa mteja wa VPN mwenyewe kwa lango lake huongozwa na itifaki, kisikilizaji na usafirishaji uliyosanidi, na hayo ni maamuzi tofauti.

Miunganisho miwili, wamiliki wawili

Usanidi wowote kama huu unahusisha muunganisho kutoka mteja hadi lango na mmoja kutoka programu hadi lengwa. Sehemu ya Proxy inazungumza kuhusu ule wa pili, ingawa iko katika wasifu mmoja na ule wa kwanza.

Marejeo ya mipangilio ya proksi ya Apple yanaorodhesha HTTP, HTTPS, SOCKS na usanidi wa kiotomatiki wa proksi, ambayo inaelezea chaguo za proksi za programu. Hakuna ingizo lolote kati ya hayo linalosema jinsi pakiti ya IPsec au WireGuard inafikia lango.

Hapa kuna ukaguzi wa haraka unaomaliza suala hilo. Taja bandari na itifaki ambazo mteja wa VPN huripoti katika kumbukumbu yake. Ikiwa mstari huo bado unasema UDP 500 au UDP 51820, sehemu ya proksi haikubadilisha chochote.

Wakati sehemu hiyo ndiyo chombo sahihi

Kuna kisa halisi ambapo proksi husimama mbele ya handaki, lakini hilo ni kipengele cha mteja na si sehemu ya wasifu. Mwongozo wa OpenVPN unaandika --http-proxy kwa miunganisho ya TCP inayobebwa kupitia proksi ya HTTP CONNECT. Kuitumia kunahitaji chaguo sambamba la mteja, lango linalofikika kwa njia hiyo, na proksi inayoruhusu CONNECT kwenye bandari inayotumika.

Ikiwa mteja wako anatoa chaguo hilo na mtandao unaruhusu CONNECT kwenye bandari, inaweza kufanya kazi. Ikiwa mteja haitoi, kujaza proksi ya mfumo hakuna athari yoyote kwa handaki.

Wakati hakibadilishi chochote

Wasifu wa IKEv2 au IPsec haufanyiki kuwa handaki la HTTP kwa sababu sehemu ya proksi imejazwa. Wala WireGuard, ambayo muundo wake wa usanidi hauna dhana ya proksi. Kubadilisha bandari ya lango pia hakubadilishi itifaki yake. Na kituo cha mwisho kinachojibu HTTPS ya kawaida si kisikilizaji cha VPN kiotomatiki.

Mtego huo huo huwakamata wale wanaonakili wasifu wa enzi ya PPTP kutoka miongozo ya zamani ya iPad. Chaguo bado zipo kwenye kiolesura; huduma iliyo nyuma yao haizungumzi itifaki hiyo tena.

Kuamua tabaka gani la kurekebisha

Uliza tabaka gani limeshindwa kabla ya kubadilisha chochote. Ikiwa mteja hawezi kuanzisha kikao, tatizo ni usafirishaji na sehemu ya proksi haina umuhimu. Ikiwa handaki liko juu lakini programu moja haifikii seva yake, inafaa kuchunguza proksi ya programu. Ikiwa handaki liko juu na programu zote zinashindwa, washukiwa ni uelekezaji na DNS ndani ya handaki.

Kwa kisa cha kwanza, muulize mwendeshaji ni usafirishaji au mtandao gani mbadala ulioidhinishwa anaotumia. OpenVPN juu ya TCP 443 ipo kwa sababu baadhi ya mitandao huruhusu hiyo pekee, na bado inahitaji seva kuisikiliza.

Usichukue bandari ya UDP iliyozuiwa kama ruhusa ya kubuni njia. Hifadhi ukaguzi wa cheti au utambulisho wa lango bila kubadilika badala ya kuzima ili makubaliano ya mkono yalingane.

Thibitisha tabaka zote mbili moja baada ya nyingine

Thibitisha kwanza handaki: angalia ukurasa wa hali ya mteja kwa kikao kilichoanzishwa na hesabu ya baiti isiyo sifuri. Kisha soma mpangilio wa proksi moja kwa moja, kwa scutil --proxy kwa usanidi unaotumika au networksetup -getwebproxy Wi-Fi kwa thamani iliyohifadhiwa. Kisha jaribu programu moja inayoheshimu proksi ya mfumo na nyingine inayoipuuza, kwa sababu programu nyingi asilia huipuuza.

Matokeo matatu, marekebisho matatu tofauti.

Ikiwa tabaka zote mbili zinaripoti mafanikio na programu bado inashindwa, angalia handaki lililogawanywa, DNS na mipangilio ya mtandao ya programu yenyewe. Hilo ni tabaka la tatu, na hilo pia si sehemu ya proksi.