Яагаад зочин VM доторх PAC прокси хостын URL-тай ажиллахгүй байна

«Хост энэ PAC файлыг ашигладаг тул би ижил URL-ыг VM-д хийлээ» гэдэг нь утга учиртай өгүүлбэр бөгөөд дутуу төлөвлөгөө юм. PAC URL прокси биш, бодлогын скрипт рүү заана. Зочин тэр скриптийг татаж авч, зочины өөрийн хаягаар үнэлж, скриптийн нэрлэсэн аль ч проксид хүрэх хүртэл URL нь тохиргооны талбар дахь тэмдэгт мөр төдий. Виртуал машин дахь прокси бодлогын эргэн тойронд үүсэх будлианы ихэнх нь тэр нэг мөрийг бүхэл тохиргоо гэж үзэхээс гардаг.

PAC URL бол скрипт, прокси биш

Файл дотор URL болон хост авч, прокси тайлбар эсвэл DIRECT гэдэг үгийг буцаадаг функц байна. URL-д програмд трафикийг хаашаа илгээхийг хэлэх зүйл байхгүй; тэр шийдвэрийг гүйцэтгэлийн үед, скриптийн дотор, скрипт платформоос асуудаг өгөгдлөөр гаргадаг. PAC URL хүлээн авдаг тохиргооны цонх нь шийдвэр гаргах процедур руу заагч хүлээн авч байна.

Яг энэ ялгаа нь URL-ыг хуулах нь ажилласан мэт харагдах шалтгаан юм. Талбар дүүрч, тохиргоо хадгалагдаж, алдаа нь дараа нь л, скриптийг татаж чадахгүй үед эсвэл зочин хүрч чадахгүй прокси буцаах үед л илэрдэг.

Дөрвөн алхам тус бүр өөр өөрөөр бүтэлгүйтдэг

Зочины дотор дөрвөн зүйл дараалан болох ёстой бөгөөд тус бүр өөрийн алдааны тэмдэгтэй. Зочин PAC файлыг татаж авдаг. Програм нь хүссэн URL-ийн скриптийг локал мэдээллээр үнэлдэг. Сонгосон прокси шийдэгдэж, түүнд хүрдэг. Прокси шаардвал баталгаажуулалт явагдана.

Таталтыг нотлохоос эхэл, учир нь үүнгүйгээр дараах бүхэн утгагүй. Хувийн сервер дээрх PAC файл ямар ч дүрэм тусалж эхлэхээс өмнө тэр сервер рүү зөвшөөрөгдсөн зам шаарддаг бөгөөд хүрч чадахгүй скриптийн доторх прокси сонголт түүнийг татах замыг үүсгэж чадахгүй:

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

Хэрэв энэ хүсэлт зочноос бүтэлгүйтэж, хостоос ажиллавал асуудал скриптийн агуулгад биш, зочины PAC сервер рүү гарах замд. Хэрэв JavaScript файл буцаавал хоёр дахь алхам руу шилжиж, скрипт зочины нөхцөл байдалд юу шийддэгийг олж мэд.

Ижил скрипт VM дотор өөрөөр шийддэг

PAC функцууд хүссэн хост болон үнэлгээ хийж буй машины тухай мэдээллийг шалгаж болно. Клиентийн өөрийн хаяг дээр бүтээсэн дүрэм, жишээ нь интерфэйсийн хаяг эсвэл дэд сүлжээний гишүүнчлэлийг шалгадаг дүрэм нь физик хостын биш, зочины хаягийг харна. Хостын талын NAT-ийн цаана эдгээр нь өөр хаяг тул ижил скрипт өөр прокси сонгох эсвэл VM дотор DIRECT рүү буцаж болно.

Энэ нь скриптийн гэмтэл биш. Скрипт нь зөвхөн зориулалтын ажлаа өөр оролтоор хийж байгаа бөгөөд энэ нь хост прокси ашиглаж, зочин шууд холбогддог гэсэн будлиантай тайланг тайлбарлаж байна. Шийдвэрийн талаар бодохын оронд дахин үүсгэ: хаяг болон URL авдаг PAC үнэлэгч, хэрэв таны түгээлтэд байвал, асуудлыг нэг командаар шийднэ. Эс бөгөөс бодитоор ашиглагдах програмаар туршиж, таамаглахын оронд түүний прокси логыг уншиж.

Зочин хостын прокси тохиргоог өвлөсөн гэж дүгнэж болохгүй, учир нь түүний трафик хостын талын орчуулгаар дамждаг. Сүлжээний орчуулга пакетуудыг дамжуулдаг; энэ нь програмын тохиргоог хуулбарладаггүй бөгөөд системийн прокси бол програмын тохиргоо юм.

PAC-г огт уншдаггүй хэрэгслүүд

Командын мөрийн хэрэгслүүд нь тусдаа хил бөгөөд яг энд их цаг үрэгддэг. curl нь PAC файлуудыг гүйцэтгэдэггүй, түүний прокси баримт бичиг тодорхой хэлдэг шиг. Прокси хувьсагчийг PAC татах URL руу чиглүүлэх нь скриптийг проксийн төгсгөлийн цэг болгохгүй; хэрэгсэл JavaScript файлтай HTTP-ээр ярихыг оролдож, сүлжээний асуудал мэт харагдах байдлаар бүтэлгүйтнэ.

Мөн адил зүйл зөвхөн тодорхой прокси хувьсагч эсвэл өөрийн тохиргоог дагадаг олон багц менежер, хэлний гүйцэтгэх орчин, бүтээх хэрэгсэлд хамаарна. Хэрэв чамд чухал шалгалт нь CLI хэрэгсэл бол PAC скриптийн сонгох байсан тодорхой проксигоор тохируулж, тэр сонголтод хэрхэн хүрснээ тэмдэглэж, дараагийн хүн давтаж болох боломжтой болго.

Linux дээрх ширээний програмуудад системийн тохиргоог автомат горимд оруулж, URL өгөх шаардлагатай; горим хараахан гарын горимд байхад хадгалсан URL юу ч хийдэггүй. Хоёуланг шалга, мөн зочины дотор шалга:

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

DIRECT ч бас шийдвэр

PAC-ийн үр дүн DIRECT гэдэг нь програм HTTP проксиг тойрч гарна гэсэн үг бөгөөд сүлжээнээс зугтсан гэсэн үг биш. Үүссэн холболт одоо ч операцийн системийн маршрутаар туннелээр явж болох бөгөөд прокси ашиглахтай ямар ч хамаагүй шалтгаанаар бүтэлгүйтэж болно. Харин эсрэгээр, проксийн үр дүн нэг програмын хүсэлтийг тодорхойлдог, зочины бүх процессыг биш.

Тиймээс шаардлагыг бичсэн чиглэлд шалга. Хэрэв шаардлага нь «энэ програм дотоод сайтад хүрнэ» бол тэр програм хүрдэг гэдгийг нотолж, аль прокси эсвэл маршрут түүнийг дамжуулсныг тэмдэглэ. Хэрэв шаардлага нь «VM корпорацийн сүлжээнд байна» бол сонгосон проксигоор ажиллаж буй хөтөч нь тэр хөтчийн хувьд нотолгоо бөгөөд үүнээс өөр зүйл биш.

Шалгалт давахын тулд хостын туннелийг унтраах эсвэл дамжуулах бодлогыг сулруулахын оронд зочины дотор гинжийг зас. Гинжид дөрвөн холбоос байх бөгөөд тэдгээрийн нэгийг алгасах өөрчлөлт нь скрипт дараагийн удаа шинэчлэгдэх эсвэл зочины хаяг өөрчлөгдөх хүртэл үргэлжилнэ.