Çfarë bën në të vërtetë fusha Proxy në një profil VPN të Apple

Plotësimi i fushës Proxy në një konfigurim VPN të Apple jep përshtypjen se duhet ta ridrejtojë tunelin përmes një porte web. Nuk e bën. Fusha zgjedh një ndërmjetës në nivel aplikacioni për trafikun që një aplikacion i përputhshëm vendos ta dërgojë atje. Ndërsa lidhja e vetë klientit VPN me portën e tij drejtohet nga protokolli, dëgjuesi dhe transporti që keni konfiguruar, dhe këto janë vendime të ndara.

Dy lidhje, dy pronarë

Çdo konfigurim i tillë përfshin një lidhje nga klienti te porta dhe një nga aplikacioni te destinacioni. Seksioni Proxy flet për të dytën, edhe pse ndodhet në të njëjtin profil si e para.

Referenca e cilësimeve të proxy e Apple liston HTTP, HTTPS, SOCKS dhe konfigurimin automatik të proxy, që përshkruan zgjedhjet e proxy të aplikacioneve. Asnjë prej këtyre zërave nuk thotë si një paketë IPsec ose WireGuard arrin te një portë.

Këtu është një kontroll i shpejtë që e zgjidh çështjen. Përmendni portën dhe protokollin që klienti VPN raporton në regjistrin e tij. Nëse ai rresht vazhdon të thotë UDP 500 ose UDP 51820, fusha proxy nuk ka ndryshuar asgjë në të.

Kur fusha është mjeti i duhur

Ka një rast të vërtetë ku një proxy qëndron përpara tunelit, por kjo është veçori e klientit dhe jo fushë e profilit. Manuali i OpenVPN dokumenton --http-proxy për lidhjet TCP që transportohen përmes një proxy HTTP CONNECT. Përdorimi i tij kërkon opsionin përkatës të klientit, një portë të arritshme në atë mënyrë dhe një proxy që lejon CONNECT në portën e përdorur.

Nëse klienti juaj e ofron atë opsion dhe rrjeti lejon CONNECT në portë, mund të funksionojë. Nëse klienti nuk e ofron, plotësimi i një proxy sistemi nuk ka asnjë efekt mbi tunelin.

Kur nuk ndryshon asgjë

Një profil IKEv2 ose IPsec nuk bëhet tunel HTTP sepse fusha proxy është e plotësuar. As WireGuard, formati i konfigurimit të të cilit nuk njeh konceptin e proxy. Ndryshimi i portës së portës nuk e ndryshon as protokollin e saj. Dhe një pikë fundore që përgjigjet ndaj HTTPS të zakonshëm nuk është automatikisht një dëgjues VPN.

E njëjta kurth kap edhe ata që kopjojnë profile të epokës PPTP nga udhëzues të vjetër për iPad. Opsionet ekzistojnë ende në ndërfaqe; shërbimi pas tyre nuk flet më atë protokoll.

Të vendosësh cilën shtresë të rregullosh

Pyesni cila shtresë dështoi përpara se të ndryshoni diçka. Nëse klienti nuk mund të vendosë një sesion, problemi është transporti dhe fusha proxy është e parëndësishme. Nëse tuneli është lart, por një aplikacion nuk arrin serverin e tij, ia vlen të shqyrtohet proxy i aplikacionit. Nëse tuneli është lart dhe të gjitha aplikacionet dështojnë, të dyshuarit janë drejtimi dhe DNS brenda tunelit.

Për rastin e parë, pyesni operatorin cilin transport ose rrjet alternativ të miratuar mbështet. OpenVPN mbi TCP 443 ekziston sepse disa rrjete lejojnë vetëm atë, dhe ai kërkon ende që serveri të dëgjojë atë.

Mos e konsideroni një portë UDP të bllokuar si leje për improvizim. Mbani të paprekura kontrollet e certifikatës ose identitetit të portës, në vend që t’i çaktivizoni për ta bërë shtrëngimin e duarve të përshtatet.

Konfirmoni të dyja shtresat njërën nga një

Konfirmoni së pari tunelin: shikoni faqen e statusit të klientit për një sesion të vendosur dhe një numër bajtësh që nuk është zero. Më pas lexoni cilësimin e proxy drejtpërdrejt, me scutil --proxy për konfigurimin efektiv ose networksetup -getwebproxy Wi-Fi për vlerën e ruajtur. Më pas provoni një aplikacion që respekton proxy e sistemit dhe një që e injoron atë, sepse shumë aplikacione vendase e injorojnë.

Tre rezultate, tre rregullime të ndryshme.

Nëse të dyja shtresat raportojnë sukses dhe aplikacioni ende dështon, shikoni tunelimin e ndarë, DNS dhe cilësimet e rrjetit të vetë aplikacionit. Kjo është një shtresë e tretë, dhe as ajo nuk është fusha proxy.