Mac VPN ve PAC proxy: iki karar, tek bir ayar değil

Mac'iniz bir ilke betiği indirir ve sonra bu betiğe bir isteğin hangi aracıyı kullanması gerektiğini sorar, tünel ise yalnızca seçilen atlama noktasına nasıl ulaşılacağına karar verir. İki yanıt da aynı sokete düşer, bu yüzden ikisi de başarılı olduktan sonra başarısız olan bir istek iki tane varken tek bir arıza gibi görünür. İndirmeyi seçimden, seçimi de rotadan ayırmak bu biletlerdeki işin büyük kısmıdır. Aşağıdaki sıra macOS'un gerçekte yaptığını izler ve her aşamayı görünür kılan kontrolleri içerir.

PAC adresi ile proxy'nin ayrıldığı yer

https://config.corp.example/proxy.pac gibi bir adres indirilecek bir belgeyi adlandırır ve bu belge trafiğin üzerinden gönderileceği sunucuyu adlandırır. URL'yi bir proxy ana makine alanına yapıştırmak, istemciden hiçbir zaman böyle bir bağlantı dinlemeyen bir dosya sunucusuna proxy bağlantısı açmasını ister. Dosyanın içinde istemcinin her istekte çağırdığı bir işlev vardır ve dönüş değeri o tek hedef için bir sonraki atlama noktasıdır. Bu dolaylılık, aynı ağ hizmetindeki iki makinenin ikisi de doğru URL'ye sahipken neden farklı davranabildiğini açıklar. Ayrıca bir ilke değişikliğinin kimse proxy'nin kendisine dokunmadan neden yürürlüğe girdiğini de açıklar.

Aşağı akışta herhangi bir şeyi yorumlamadan önce betiği okuyun, çünkü içindeki kurallar kuruluşun istisnalarını ve bunların uygulanma sırasını taşır. Erken geniş bir aralık daha sonraki bir iç son eki gölgeleyebilir ve proxy'yi açıkça atlaması gereken bir ana makine onu kullanmaya devam eder. Biri ilkenin yanlış olduğunda ısrar ettiğinde, bu iddianın çözüldüğü tek yer betiktir.

Betik herhangi bir şeye karar vermeden önce getirilmelidir

İlkeyi indirmek için çözülmüş bir ad ve dosyayı sunan şeye bir rota gerekir, bağlı bir tünel ikisini de garanti etmez. Ana makine yalnızca özel DNS üzerinden çözülüyorsa, o anda kullanılan çözümleyici indirmenin başlayıp başlayamayacağına karar verir. Ana makine özel bir aralıktaysa, rota bu makineden var olmalıdır, bir iş arkadaşının dizüstü bilgisayarından değil. Önceki bir oturumda önbelleğe alınmış bir kopya, önbellek süresi dolana veya makine yeniden başlayana kadar bunların hepsini gizler.

Aşağıdaki üç kontrolü sırayla çalıştırın ve ilk başarısızlıkta durun, çünkü aşamalar aynı nedeni paylaşmaz. Birlikte, ilkenin yapılandırılıp yapılandırılmadığını, erişilebilir olup olmadığını ve ne döndürdüğünü gösterirler.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

İlk komut etkin hizmet için proxy sözlüğünü yazdırır, sistemin tuttuğu herhangi bir otomatik yapılandırma URL'si dahil. İkincisi bir adlandırılmış hizmete bağlı URL'yi bildirir, bu Wi-Fi ile Ethernet arasında geçiş yapan bir dizüstünde önemlidir. Üçüncüsü dosyayı işlemeden getirir, böylece 404, zaman aşımı ve çözümleyici hatası ayırt edilebilir kalır. Son komut betiği döndürürken uygulamalar hâlâ başarısız oluyorsa, sorun getirmeyi çoktan geçmiştir.

DIRECT yanıtının gerçekte neyi atladığı

PAC belirtimi istemciye küçük bir sözlük verir ve DIRECT onun sözcüklerinden biridir. Bu sözcük istemciye o istek için proxy'yi atlamasını söyler ve soketin ardından hangi arabirimi kullanacağı hakkında hiçbir şey söylemez. Tam bir tünelde doğrudan bir soket yine de VPN üzerinden çıkar ve hedefe yine de tünelin çıkış adresini gösterir.

DIRECT'ü VPN'in dışında olarak okumak, insanları yanlış ayarlar paneline gönderen hatadır. Ayna görüntüsü de aynı ölçüde yaygındır, çünkü özel bir proxy'ye bölünmüş bir rota üzerinden ulaşılabilirken makinenin geri kalanı tünelin dışında kalır. Hedefin o sırada bildirdiği şey proxy'nin kendi çıkışına aittir ve bu başka bir ülkede olabilir. Bir iç ana makine ve bir genel ana makine için beklentiyi yazmak bunu hızla ortaya çıkarır, çünkü betik çoğu zaman ikisine farklı yanıt verir. Hangi atlama noktasının adresi ürettiğini bildiğinizde rapor gizemli olmaktan çıkar.

Tek bir hata sayfası olarak görünen üç arıza

İlke indirilemeyebilir, seçilen proxy'ye ulaşılamayabilir ve hizmete ulaşan bir istek orada yine de reddedilebilir. Üçü de zaman aşımı veya genel bir hata sayfası olarak gelir ve hiçbiri bozulan aşamayı adlandırmaz. Kararı hatanın yanında yakalamak onları ayıran şeydir. Aşağıdaki iki sonda, betiğin seçtiği atlama noktasını test eder; döndürebileceği her dal için bir tane.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Proxy'ye tamamlanan bir bağlantı soruyu kimlik doğrulamaya veya proxy'nin kendi ilkesine taşır, bunun sahibi başkadır. Yolda proxy olmadan iç ana makineye tamamlanan bir bağlantı rotayı dışlar ve ilkeye işaret eder. İki komut da kabuk proxy değişkenlerini dışa aktarmadıkça macOS proxy sözlüğünü yok sayar, bu yüzden önce onları temizleyin. İki sondadan hiçbiri diğerini kanıtlamaz, bu yüzden tek bir hata sayfası bu kadar uzun süre yanıltır.

Biletle birlikte ne teslim edilmeli

Etkin ağ hizmetini, PAC URL'sini, başarısız ana makine için değerlendirme sonucunu ve hatanın göründüğü aşamayı gönderin. Bu dördü, bir sonraki kişinin hangi katmanın dahil olduğunu tahmin etmek yerine kararı yeniden üretmesini sağlar. Test anındaki tünel durumunu ekleyin, çünkü yeniden bağlanmadan önce yakalanan sonuç eskidir. Betik revizyonunu da saklayın, çünkü ilke dosyası haber verilmeden değişir ve dünün yanıtı artık geçerli olmayabilir.

Betik alınamadığında istemcinin nasıl davrandığını kaydedin, çünkü uygulamalar farklıdır ve proxy kararı cihazın tamamı için bir acil durdurma anahtarı değildir. Bazıları doğrudan bağlantıya geri döner, bazıları kapalı olarak başarısız olur ve bu fark, bir kesintinin bozuk proxy gibi mi yoksa çalışan ilke gibi mi göründüğünü değiştirir. Bir olay sırasında ona güvenmeden önce tam istemci ve sürüm için davranışı doğrulayın.