Konuk VM'deki PAC proxy'si ana makinenin URL'siyle neden başarısız olur

«Ana makine bu PAC dosyasını kullanıyor, ben de aynı URL'yi VM'ye koydum» makul bir cümle ve eksik bir plandır. PAC URL'si bir proxy'ye değil, bir ilke betiğine işaret eder. Konuk bu betiği indirene, konuğun kendi adresleriyle değerlendirene ve betiğin adlandırdığı herhangi bir proxy'ye ulaşana kadar URL, ayarlar alanındaki bir dizgeden ibarettir. Sanal makinelerdeki proxy ilkesi etrafındaki karışıklığın çoğu, o tek satırın tüm yapılandırma sayılmasından kaynaklanır.

PAC URL'si bir betiktir, proxy değil

Dosya, bir URL ve bir ana makine alıp proxy açıklaması ya da DIRECT sözcüğünü döndüren bir işlev içerir. URL'de uygulamaya trafiği nereye göndereceğini söyleyen hiçbir şey yoktur; bu karar çalışma zamanında, betiğin içinde, betiğin platformdan istediği verilerle verilir. PAC URL'sini kabul eden bir ayarlar iletişim kutusu, bir karar yordamına işaretçi kabul ediyordur.

Bu ayrım, URL'yi kopyalamanın işe yaramış gibi görünebilmesinin nedenidir. Alan doldurulur, ayar kaydedilir ve hata ancak sonradan, betik indirilemediğinde ya da konuğun ulaşamayacağı bir proxy döndürdüğünde ortaya çıkar.

Dört adımın her biri farklı biçimde başarısız olur

Konuğun içinde dört şeyin sırayla gerçekleşmesi gerekir ve her birinin kendi hata imzası vardır. Konuk PAC dosyasını indirir. Uygulama, istenen URL için betiği yerel bilgilerle değerlendirir. Seçilen proxy çözümlenir ve ona ulaşılır. Proxy gerektiriyorsa kimlik doğrulama yapılır.

İndirmeyi kanıtlayarak başlayın, çünkü o olmadan sonraki her şey anlamsızdır. Özel bir sunucudaki PAC dosyası, herhangi bir kural yardımcı olmadan önce o sunucuya izin verilen bir yol gerektirir ve ulaşılamayan bir betiğin içindeki proxy seçimi onu indirecek yolu oluşturamaz:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Bu istek konuktan başarısız olup ana makineden çalışıyorsa, sorun betiğin içeriğinde değil, konuğun PAC sunucusuna giden yolundadır. Bir JavaScript dosyası döndürürse ikinci adıma geçin ve betiğin konuğun bağlamı için ne karar verdiğini bulun.

Aynı betik VM içinde farklı karar verir

PAC işlevleri, istenen ana makineyi ve değerlendirmeyi yapan makineyle ilgili bilgileri inceleyebilir. İstemcinin kendi adresi üzerine kurulmuş bir kural, örneğin bir arabirim adresini ya da bir alt ağa üyeliği denetleyen kural, fiziksel ana makinenin değil konuğun adresini görür. Ana makine tarafındaki NAT'ın arkasında bunlar farklı adreslerdir, bu yüzden aynı betik başka bir proxy seçebilir veya VM içinde DIRECT'e geri dönebilir.

Bu, betikteki bir hata değildir. Betik, yazıldığı işi farklı bir girdiyle yapıyor ve bu, ana makinenin proxy'yi kullandığı konuğun ise doğrudan bağlandığı kafa karıştırıcı raporu açıklar. Kararı akıl yürütmek yerine yeniden üretin: bir adres ve URL alan bir PAC değerlendiricisi, dağıtımınızda varsa, soruyu tek komutla çözer. Aksi halde gerçekten kullanılacak uygulamayla test edin ve tahmin etmek yerine onun proxy günlüğünü okuyun.

Konuğun ana makinenin proxy ayarlarını devraldığı sonucuna varmayın, çünkü trafiği ana makine tarafındaki çeviriden geçer. Ağ çevirisi paketleri iletir; uygulama yapılandırmasını kopyalamaz ve sistem proxy'si uygulama yapılandırmasıdır.

PAC'ı hiç okumayan araçlar

Komut satırı araçları ayrı bir sınırdır ve zamanın çoğu burada kaybedilir. curl, PAC dosyalarını çalıştırmaz, kendi proxy belgeleri nin açıkça söylediği gibi. Bir proxy değişkenini PAC indirme URL'sine yöneltmek betiği proxy uç noktası yapmaz; araç bir JavaScript dosyasıyla HTTP konuşmayı deneyecek ve ağ sorunu gibi görünen bir biçimde başarısız olacaktır.

Aynısı, yalnızca açık proxy değişkenlerine veya kendi yapılandırmalarına uyan birçok paket yöneticisi, dil çalışma zamanı ve derleme aracı için de geçerlidir. Önemsediğiniz test bir CLI aracıysa, onu PAC betiğinin seçeceği somut proxy ile yapılandırın ve bu seçime nasıl vardığınızı not edin ki bir sonraki kişi yineleyebilsin.

Linux'ta masaüstü uygulamaları için sistem ayarı otomatik moda alınmalı ve ayrıca bir URL verilmelidir; mod hâlâ el ile ayarlıyken kaydedilen URL hiçbir şey yapmaz. İkisini de denetleyin ve konuğun içinde denetleyin:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT de bir karardır

PAC sonucunun DIRECT olması, uygulamanın HTTP proxy'sini atladığı anlamına gelir, ağdan kaçtığı anlamına değil. Ortaya çıkan bağlantı hâlâ bir tünelden geçen işletim sistemi rotasını izleyebilir veya proxy kullanımıyla hiçbir ilgisi olmayan nedenlerle başarısız olabilir. Tersine, bir proxy sonucu tek bir uygulamanın isteğini tanımlar, konuktaki her süreci değil.

Bu yüzden gereksinimin yazıldığı yönde doğrulayın. Gereksinim «bu uygulama iç siteye ulaşıyor» ise, o uygulamanın ulaştığını kanıtlayın ve hangi proxy'nin veya rotanın onu taşıdığını not edin. Gereksinim «VM kurumsal ağda» ise, seçilen bir proxy üzerinden çalışan bir tarayıcı o tarayıcı için kanıttır, fazlası değil.

Bir testin geçmesi için ana makinenin tünelini kapatmak ya da yönlendirme ilkesini gevşetmek yerine zinciri konuğun içinde onarın. Zincirin dört halkası vardır ve bunlardan birini atlayan bir değişiklik, betik bir sonraki kez güncellenene veya konuğun adresi değişene kadar dayanır.