Apple VPN profilindeki Proxy alanı gerçekte ne yapar
Bir proxy alanını doldurmak VPN'i HTTP'ye çevirmez. İki bağlantı söz konusudur ve alan yalnızca birine ulaşır.
Apple VPN yapılandırmasındaki Proxy alanını doldurmak, tüneli bir web bağlantı noktasından yönlendirecekmiş gibi hissettirir. Yönlendirmez. Alan, uyumlu bir uygulamanın oraya göndermeye karar verdiği trafik için uygulama düzeyinde bir aracı seçer. VPN istemcisinin kendi ağ geçidine olan bağlantısını ise yapılandırdığınız protokol, dinleyici ve taşıma belirler ve bunlar ayrı kararlardır.
İki bağlantı, iki sahip
Bu tür her kurulum, istemciden ağ geçidine bir bağlantı ve uygulamadan hedefe bir bağlantı içerir. Proxy bölümü ikincisinden söz eder, her ne kadar birincisiyle aynı profilde olsa da.
| 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 ayarları başvurusu HTTP, HTTPS, SOCKS ve otomatik proxy yapılandırmasını listeler; bu, uygulamaların proxy seçimlerini açıklar. Bu girdilerin hiçbiri bir IPsec veya WireGuard paketinin ağ geçidine nasıl ulaştığını söylemez.
Konuyu kesin olarak çözen hızlı bir kontrol var. VPN istemcisinin günlüğünde bildirdiği bağlantı noktasını ve protokolü söyleyin. O satır hâlâ UDP 500 veya UDP 51820 diyorsa, proxy alanı orada hiçbir şeyi değiştirmemiştir.
Alan ne zaman doğru araçtır
Proxy'nin tünelin önünde durduğu gerçek bir durum vardır, ancak bu profil alanı değil, istemci özelliğidir. OpenVPN kılavuzu, HTTP CONNECT proxy üzerinden taşınan TCP bağlantıları için --http-proxy seçeneğini belgeler. Bunu kullanmak için eşleşen istemci seçeneği, o yoldan erişilebilen bir ağ geçidi ve kullanılan bağlantı noktasına CONNECT izni veren bir proxy gerekir.
İstemciniz bu seçeneği sunuyorsa ve ağ bağlantı noktasına CONNECT izni veriyorsa çalışabilir. İstemci sunmuyorsa, sistem proxy'sini doldurmanın tünel üzerinde hiçbir etkisi yoktur.
Ne zaman hiçbir şeyi değiştirmez
Bir IKEv2 veya IPsec profili, proxy alanı dolu olduğu için HTTP tüneli olmaz. Yapılandırma biçiminde proxy kavramı bulunmayan WireGuard da olmaz. Ağ geçidi bağlantı noktasını değiştirmek de protokolünü değiştirmez. Ve sıradan HTTPS'e yanıt veren bir uç nokta otomatik olarak VPN dinleyicisi değildir.
Aynı tuzak, eski iPad rehberlerinden PPTP dönemi profillerini kopyalayanları da yakalar. Seçenekler arayüzde hâlâ var; arkalarındaki hizmet artık o protokolü konuşmuyor.
Hangi katmanın düzeltileceğine karar vermek
Bir şeyi değiştirmeden önce hangi katmanın başarısız olduğunu sorun. İstemci oturum kuramıyorsa sorun taşımadadır ve proxy alanı konu dışıdır. Tünel ayaktaysa ama bir uygulama sunucusuna ulaşamıyorsa uygulama proxy'sine bakmaya değer. Tünel ayaktaysa ve tüm uygulamalar başarısız oluyorsa şüpheliler tünel içindeki yönlendirme ve DNS'tir.
İlk durum için işletmeciye hangi onaylı alternatif taşımayı veya ağı desteklediğini sorun. OpenVPN'in TCP 443 üzerinden olması, bazı ağların yalnızca buna izin vermesindendir ve yine de sunucunun bunu dinlemesini gerektirir.
Engellenen bir UDP bağlantı noktasını doğaçlama izni olarak görmeyin. El sıkışmanın uyması için ağ geçidinin sertifika veya kimlik denetimlerini kapatmak yerine olduğu gibi koruyun.
İki katmanı tek tek doğrulayın
Önce tüneli doğrulayın: istemcinin durum sayfasında kurulmuş bir oturum ve sıfırdan farklı bayt sayısı olup olmadığına bakın. Ardından proxy ayarını doğrudan okuyun, etkin yapılandırma için scutil --proxy veya saklanan değer için networksetup -getwebproxy Wi-Fi kullanarak. Sonra sistem proxy'sine uyan bir uygulamayı ve onu yok sayan bir başkasını deneyin, çünkü birçok yerel uygulama onu yok sayar.
Üç sonuç, üç farklı düzeltme.
İki katman da başarı bildiriyorsa ve uygulama hâlâ başarısız oluyorsa bölünmüş tünellemeye, DNS'e ve uygulamanın kendi ağ ayarlarına bakın. Bu üçüncü bir katmandır ve o da proxy alanı değildir.