Nega mehmon VM dagi PAC proksisi host URL bilan ishlamaydi

«Host bu PAC faylidan foydalanadi, shuning uchun men o’sha URL ni VM ga qo’ydim» — bu mantiqiy gap va tugallanmagan reja. PAC URL proksiga emas, siyosat skriptiga ishora qiladi. Mehmon bu skriptni olmaguncha, uni mehmonning o’z manzillari bilan baholamaguncha va skript nomlagan istalgan proksiga yetmaguncha, URL sozlamalar maydonidagi satr bo’lib qoladi. Virtual mashinalarda proksi siyosati atrofidagi chalkashlikning ko’p qismi o’sha bitta satrni butun konfiguratsiya deb qabul qilishdan kelib chiqadi.

PAC URL — skript, proksi emas

Faylda URL va hostni olib, proksi tavsifini yoki DIRECT so’zini qaytaradigan funksiya bor. URL da ilovaga trafikni qayerga yuborishni aytadigan hech narsa yo’q; bu qaror ishlash vaqtida, skript ichida, skript platformadan so’raydigan ma’lumotlar bilan qabul qilinadi. PAC URL ni qabul qiladigan sozlamalar oynasi qaror qabul qilish tartibiga ko’rsatkichni qabul qiladi.

Aynan shu farq URL ni nusxalash ishlagandek ko’rinishining sababidir. Maydon to’ldiriladi, sozlama saqlanadi, xato esa faqat keyinroq, skriptni olib bo’lmaganda yoki u mehmon yeta olmaydigan proksi qaytarganda ko’rinadi.

To’rt qadamning har biri o’zicha muvaffaqiyatsiz bo’ladi

Mehmon ichida to’rt narsa tartib bilan sodir bo’lishi kerak va har birining o’z xato belgisi bor. Mehmon PAC faylini oladi. Ilova so’ralgan URL uchun skriptni mahalliy ma’lumotlar bilan baholaydi. Tanlangan proksi aniqlanadi va unga yetiladi. Proksi talab qilsa, autentifikatsiya amalga oshadi.

Olib kelishni isbotlashdan boshlang, chunki usiz keyingi hamma narsa ma’nosiz. Shaxsiy serverdagi PAC fayli har qanday qoida yordam berishidan oldin o’sha serverga ruxsat etilgan yo’lni talab qiladi va yetib bo’lmaydigan skript ichidagi proksi tanlovi uni olib keladigan yo’lni yarata olmaydi:

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

Agar bu so’rov mehmondan muvaffaqiyatsiz bo’lib, hostdan ishlasa, muammo skript mazmunida emas, mehmonning PAC serveriga boradigan yo’lida. Agar u JavaScript faylini qaytarsa, ikkinchi qadamga o’tib, skript mehmon konteksti uchun nima qaror qilishini aniqlang.

Xuddi shu skript VM ichida boshqacha qaror qiladi

PAC funksiyalari so’ralgan hostni va baholashni bajaradigan mashina haqidagi ma’lumotlarni tekshira oladi. Mijozning o’z manziliga qurilgan qoida, masalan, interfeys manzilini yoki sub tarmoqqa tegishlilikni tekshiradigan qoida, jismoniy hostning emas, mehmonning manzilini ko’radi. Host tomonidagi NAT orqasida bular boshqa manzillar, shuning uchun xuddi shu skript boshqa proksi tanlashi yoki VM ichida DIRECT ga qaytishi mumkin.

Bu skriptdagi nuqson emas. Skript aynan o’zi yozilgan ishni boshqa kirish bilan bajarmoqda va bu host proksidan foydalanib, mehmon to’g’ridan-to’g’ri ulanadigan chalkash hisobotni tushuntiradi. Qaror haqida fikr yuritish o’rniga uni qayta ishlab chiqaring: manzil va URL ni qabul qiladigan PAC baholovchisi, agar distributivingizda bo’lsa, masalani bitta buyruq bilan hal qiladi. Aks holda haqiqatda ishlatiladigan ilova bilan sinab ko’ring va taxmin qilish o’rniga uning proksi jurnalini o’qing.

Mehmon hostning proksi sozlamalarini meros qilib olgan deb xulosa qilmang, chunki uning trafigi host tomonidagi tarjimadan o’tadi. Tarmoq tarjimasi paketlarni uzatadi; u ilovalar konfiguratsiyasini nusxalamaydi va tizim proksisi ilova konfiguratsiyasidir.

PAC ni umuman o’qimaydigan vositalar

Buyruq qatori vositalari alohida chegara va aynan shu yerda ko’p vaqt yo’qoladi. curl PAC fayllarini bajarmaydi, uning proksi hujjatlari aniq aytganidek. Proksi o’zgaruvchisini PAC yuklab olish URL iga yo’naltirish skriptni proksi oxirgi nuqtasiga aylantirmaydi; vosita JavaScript fayli bilan HTTP tilida gaplashishga urinib, tarmoq muammosiga o’xshash tarzda muvaffaqiyatsiz bo’ladi.

Xuddi shu narsa faqat aniq proksi o’zgaruvchilariga yoki o’z konfiguratsiyasiga rioya qiladigan ko’plab paket menejerlari, til ishlash muhitlari va qurish vositalariga ham tegishli. Agar siz uchun muhim sinov CLI vositasi bo’lsa, uni PAC skript tanlaydigan aniq proksi bilan sozlang va bu tanlovga qanday kelganingizni yozib qo’ying, keyingi odam takrorlay olsin.

Linux dagi ish stoli ilovalari uchun tizim sozlamasi avtomatik rejimga qo’yilishi va unga URL ham berilishi kerak; rejim hali qo’lda bo’lganda saqlangan URL hech narsa qilmaydi. Ikkalasini ham tekshiring va ularni mehmon ichida tekshiring:

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

DIRECT ham qaror

PAC natijasi DIRECT degani ilova HTTP proksini chetlab o’tadi, tarmoqdan qochib ketdi degani emas. Hosil bo’lgan ulanish hali ham tunnel orqali operatsion tizim marshrutini kuzatishi yoki proksi ishlatilishiga aloqasi bo’lmagan sabablarga ko’ra muvaffaqiyatsiz bo’lishi mumkin. Aksincha, proksi natijasi bitta ilovaning so’rovini tavsiflaydi, mehmondagi har bir jarayonni emas.

Shuning uchun talab yozilgan yo’nalishda tekshiring. Agar talab «bu ilova ichki saytga yetadi» bo’lsa, o’sha ilova yetishini isbotlang va uni qaysi proksi yoki marshrut olib o’tganini yozib qo’ying. Agar talab «VM korporativ tarmoqda» bo’lsa, tanlangan proksi orqali ishlaydigan brauzer o’sha brauzer uchun dalil, undan ortig’i emas.

Sinov o’tishi uchun host tunnelini o’chirish yoki yo’naltirish siyosatini yumshatish o’rniga mehmon ichidagi zanjirni tuzating. Zanjirda to’rt bo’g’in bor va ulardan birini o’tkazib yuboradigan o’zgarish skript keyingi marta yangilanmaguncha yoki mehmon manzili o’zgarmaguncha saqlanadi.