Niyə qonaq VM-də PAC proksisi host URL-i ilə alınmır
PAC URL-i proksiyə deyil, siyasət skriptinə işarə edir. Qonaq onu gətirməli, öz ünvanları ilə qiymətləndirməli, sonra seçdiyi proksiyə çatmalıdır.
«Host bu PAC faylını istifadə edir, ona görə də eyni URL-i VM-ə qoydum» məqbul bir cümlə və natamam bir plandır. PAC URL-i proksiyə deyil, siyasət skriptinə işarə edir. Qonaq həmin skripti gətirə, onu qonağın öz ünvanları ilə qiymətləndirə və skriptin göstərdiyi proksiyə çata bilənə qədər URL sadəcə parametrlər sahəsindəki sətirdir. Virtual maşınlarda proksi siyasəti ətrafındakı qarışıqlığın çoxu həmin bir sətri bütün konfiqurasiya hesab etməkdən gəlir.
PAC URL-i proksi deyil, skriptdir
Faylda URL və host qəbul edib proksi təsviri və ya DIRECT sözünü qaytaran funksiya var. URL-də tətbiqə trafiki hara göndərəcəyini deyən heç nə yoxdur; bu qərar işləmə vaxtı skriptin içində, skriptin platformadan istədiyi məlumatlarla verilir. PAC URL-i qəbul edən parametr pəncərəsi əslində qərar proseduruna göstərici qəbul edir.
Bu fərq URL-i kopyalamağın işləmiş kimi görünməsinin səbəbidir. Sahə doldurulub, parametr yadda saxlanılıb və nasazlıq yalnız sonra, skript gətirilə bilməyəndə və ya qonağın çata bilmədiyi proksi qaytaranda üzə çıxır.
Dörd addımın hər biri fərqli şəkildə uğursuz olur
Qonağın içində dörd şey ardıcıl baş verməlidir və hər birinin öz xəta izi var. Qonaq PAC faylını gətirir. Tətbiq tələb olunan URL üçün skripti yerli məlumatla qiymətləndirir. Seçilmiş proksi həll edilir və ona çatılır. Proksi tələb edirsə, autentifikasiya baş verir.
Gətirməni sübut etməklə başlayın, çünki onsuz aşağıdakı hər şey mənasızdır. Şəxsi serverdəki PAC faylı hər hansı qaydanın kömək edə bilməsindən əvvəl həmin serverə icazəli yol tələb edir və çatılmayan skriptin içindəki proksi seçimi onu gətirəcək yolu yarada bilməz:
curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example
Əgər bu sorğu qonaqdan uğursuz olur, hostdan isə işləyirsə, problem skriptin məzmununda deyil, qonağın PAC serverinə gedən yolundadır. Əgər JavaScript faylı qaytarırsa, ikinci addıma keçin və skriptin qonağın konteksti üçün nə qərar verdiyini öyrənin.
Eyni skript VM-in içində fərqli qərar verir
PAC funksiyaları tələb olunan hostu və qiymətləndirməni aparan maşın haqqında məlumatı yoxlaya bilər. Müştərinin öz ünvanına qurulmuş qayda, məsələn interfeys ünvanını və ya subnet üzvlüyünü yoxlayan qayda, fiziki hostun deyil, qonağın ünvanını görəcək. Host tərəfindəki NAT-ın arxasında bunlar fərqli ünvanlardır və buna görə eyni skript VM-in içində başqa proksi seçə və ya DIRECT-ə keçə bilər.
Bu skriptdə nasazlıq deyil. Skript fərqli girişlə məhz yazıldığı işi görür və bu, hostun proksidən istifadə etdiyi, qonağın isə birbaşa qoşulduğu qarışıq hesabatı izah edir. Qərarı düşünməklə deyil, təkrar istehsal edin: ünvan və URL qəbul edən PAC qiymətləndiricisi, distributivinizdə varsa, məsələni bir əmrlə həll edir. Əks halda həqiqətən istifadə olunacaq tətbiqlə sınaqdan keçirin və təxmin etmək əvəzinə onun proksi jurnalını oxuyun.
Qonağın hostun proksi parametrlərini mənimsədiyi qənaətinə gəlməyin, çünki trafiki host tərəfindəki çevrilmədən keçir. Şəbəkə çevrilməsi paketləri ötürür; o, tətbiq konfiqurasiyasını kopyalamır və sistem proksisi tətbiq konfiqurasiyasıdır.
PAC-ı heç oxumayan alətlər
Əmr sətri alətləri ayrı sərhəddir və çox vaxt məhz burada itir. curl PAC fayllarını icra etmir, bunu onun proksi sənədləşməsi açıq deyir. Proksi dəyişənini PAC yükləmə URL-inə yönəltmək skripti proksi son nöqtəsinə çevirmir; alət JavaScript faylı ilə HTTP danışmağa çalışacaq və şəbəkə probleminə bənzəyən şəkildə uğursuz olacaq.
Eyni şey açıq proksi dəyişənlərinə və ya yalnız öz konfiqurasiyasına uyan bir çox paket meneceri, dil mühiti və qurma aləti üçün keçərlidir. Əgər sizi maraqlandıran sınaq CLI alətidirsə, onu PAC skriptinin seçəcəyi konkret proksi ilə konfiqurasiya edin və bu seçimi necə çıxardığınızı qeyd edin ki, növbəti şəxs təkrar edə bilsin.
Linux-da masaüstü tətbiqləri üçün sistem parametri həm avtomatik rejimə qoyulmalı, həm də URL verilməlidir; rejim hələ əl ilə ikən yadda saxlanılan URL heç nə etmir. Hər ikisini yoxlayın və qonağın içində yoxlayın:
gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url
DIRECT də bir qərardır
PAC nəticəsinin DIRECT olması tətbiqin HTTP proksisini yan keçdiyini bildirir, şəbəkədən çıxdığını deyil. Yaranan bağlantı yenə də tuneldən keçən əməliyyat sistemi marşrutunu izləyə və ya proksidən istifadə ilə heç bir əlaqəsi olmayan səbəblərdən uğursuz ola bilər. Əksinə, proksi nəticəsi bir tətbiqin sorğusunu təsvir edir, qonaqdakı hər prosesi deyil.
Ona görə də tələbin yazıldığı istiqamətdə yoxlayın. Tələb «bu tətbiq daxili sayta çatır»dırsa, həmin tətbiqin çatdığını sübut edin və onu hansı proksinin və ya marşrutun daşıdığını qeyd edin. Tələb «VM korporativ şəbəkədədir»dirsə, seçilmiş proksidən işləyən brauzer yalnız o brauzer üçün sübutdur, başqa heç nə deyil.
Sınaq keçsin deyə hostun tunelini söndürmək və ya yönləndirmə siyasətini yumşaltmaq əvəzinə zənciri qonağın içində düzəldin. Zəncirin dörd halqası var və onlardan birini atlayan dəyişiklik skript növbəti dəfə yenilənənə və ya qonağın ünvanı dəyişənə qədər davam edəcək.