Apple VPN profilindəki Proxy sahəsi əslində nə edir
Proxy sahəsini doldurmaq VPN-i HTTP-yə çevirmir. İki əlaqə var və sahə yalnız birinə çatır.
Apple VPN konfiqurasiyasında Proxy sahəsini doldurmaq tuneli veb portdan yönləndirəcək kimi görünür. Amma etmir. Sahə uyğun tətbiqin ora göndərməyi seçdiyi trafik üçün tətbiq səviyyəsində vasitəçi seçir. VPN müştərisinin öz şlüzü ilə əlaqəsini isə konfiqurasiya etdiyiniz protokol, dinləyici və daşıyıcı idarə edir və bunlar ayrı qərarlardır.
İki əlaqə, iki sahib
Bu kimi hər hansı qurğu müştəridən şlüzə və tətbiqdən təyinat nöqtəsinə əlaqələri əhatə edir. Proxy bölməsi ikincisindən bəhs edir, hərçənd birincisi ilə eyni profildə oturur.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apple-ın proxy parametrləri arayışı HTTP, HTTPS, SOCKS və avtomatik proxy konfiqurasiyasını sadalayır ki, bu da tətbiq proxy seçimlərinin təsviridir. Bu bəndlərdən heç biri IPsec və ya WireGuard paketinin şlüzə necə çatdığı barədə heç nə demir.
Bunu həll edən qısa bir yoxlama var. VPN müştərisinin jurnalında bildirdiyi portu və protokolu göstərin. Əgər həmin sətir hələ də UDP 500 və ya UDP 51820 deyirsə, proxy sahəsi ona heç nə etməyib.
Sahə nə vaxt düzgün vasitədir
Tunelin qarşısında proxy olan real hal var, lakin bu profil sahəsi deyil, müştəri funksiyasıdır. OpenVPN təlimatı HTTP CONNECT proxy vasitəsilə ötürülən TCP əlaqələri üçün --http-proxy seçimini sənədləşdirir. Bundan istifadə üçün uyğun müştəri seçimi, bu yolla əlçatan şlüz və istifadə olunan porta CONNECT icazəsi verən proxy lazımdır.
Müştəriniz bu seçimi təqdim edirsə və şəbəkə porta CONNECT icazəsi verirsə, işləyə bilər. Müştəriniz onu təqdim etmirsə, sistem proxy-sinin doldurulması tunelə heç bir təsir etmir.
Nə vaxt heç nə dəyişmir
IKEv2 və ya IPsec profili proxy sahəsi doldurulduğu üçün HTTP tunelinə çevrilmir. WireGuard da çevrilmir, onun konfiqurasiya formatında proxy anlayışı yoxdur. Şlüz portunu dəyişmək onun protokolunu da dəyişmir. Və adi HTTPS-ə cavab verən son nöqtə avtomatik olaraq VPN dinləyicisi deyil.
Eyni tələ köhnə iPad bələdçilərindən PPTP dövrü profillərini köçürənləri də tutur. Seçimlər interfeysdə hələ də var; arxalarındakı xidmət artıq o protokolu danışmır.
Hansı qatı düzəltməyi seçmək
Nəyisə dəyişməzdən əvvəl hansı qatın uğursuz olduğunu soruşun. Müştəri sessiya qura bilmirsə, problem daşıyıcıdadır və proxy sahəsi əlaqəsizdir. Tunel işləyir, amma bir tətbiq öz serverinə çata bilmirsə, tətbiq proxy-sinə baxmağa dəyər. Tunel işləyir və bütün tətbiqlər uğursuz olursa, şübhəlilər tunel daxilində marşrutlaşdırma və DNS-dir.
Birinci hal üçün operatora hansı təsdiqlənmiş alternativ daşıyıcı və ya şəbəkənin dəstəkləndiyini soruşun. OpenVPN-in TCP 443 üzərindən olması ona görə var ki, bəzi şəbəkələr yalnız buna icazə verir və bu, yenə də serverin onu dinləməsini tələb edir.
Bloklanmış UDP portunu improvizasiya icazəsi kimi qəbul etməyin. Şlüz sertifikatı və ya kimlik yoxlamalarını handshake uyğun olsun deyə söndürmək əvəzinə olduğu kimi saxlayın.
İki qatı bir-bir təsdiqləyin
Əvvəlcə tuneli təsdiqləyin: müştərinin status səhifəsində qurulmuş sessiya və sıfırdan fərqli bayt sayı olub-olmadığını yoxlayın. Sonra proxy parametrini birbaşa oxuyun, faktiki konfiqurasiya üçün scutil --proxy və ya saxlanılan dəyər üçün networksetup -getwebproxy Wi-Fi ilə. Sonra sistem proxy-sinə hörmət edən bir tətbiqi və onu nəzərə almayan birini sınayın, çünki çoxlu yerli tətbiq onu nəzərə almır.
Üç nəticə, üç fərqli düzəliş.
Hər iki qat uğur bildirirsə və tətbiq hələ də uğursuz olursa, bölünmüş tunelləşdirməyə, DNS-ə və tətbiqin öz şəbəkə parametrlərinə baxın. Bu üçüncü qatdır və o da proxy sahəsi deyil.