Mac VPN və PAC proksisi: iki qərar, bir tənzimləmə deyil

Mac kompüteriniz siyasət skriptini endirir və sonra həmin skriptdən soruşur ki, sorğu hansı vasitəçidən keçməlidir, tunel isə yalnız seçilmiş addımın necə əldə olunduğunu müəyyən edir. Hər iki cavab eyni soketə düşür, buna görə də hər ikisi uğurlu olduqdan sonra uğursuz olan sorğu iki nasazlıq olduğu halda bir nasazlıq kimi görünür. Endirməni seçimdən, seçimi isə marşrutdan ayırmaq bu biletlərdəki işin çoxunu təşkil edir. Aşağıdakı ardıcıllıq macOS-un əslində nə etdiyini izləyir və hər mərhələni görünən edən yoxlamaları göstərir.

PAC ünvanı ilə proksi harada ayrılır

https://config.corp.example/proxy.pac kimi ünvan endiriləcək sənədi adlandırır və həmin sənəd trafiki ötürmək üçün serveri adlandırır. URL-i proksi host sahəsinə yapışdırmaq klientdən heç vaxt belə bağlantı dinləməyən fayl serverinə proksi bağlantısı açmağı tələb edir. Faylın içində klientin hər sorğu üçün çağırdığı funksiya var və onun qaytardığı dəyər həmin tək təyinat üçün növbəti addımdır. Bu dolayılıq eyni şəbəkə xidmətindəki iki maşının, hər ikisi düzgün URL daşıyarkən, niyə fərqli davrana bildiyini izah edir. O, həm də izah edir ki, siyasət dəyişikliyi proksinin özünə heç kim toxunmadan nəyə görə qüvvəyə minir.

Aşağı axında hər şeyi şərh etməzdən əvvəl skripti oxuyun, çünki içindəki qaydalar təşkilatın istisnalarını və onların tətbiq olunma sırasını daşıyır. Erkən geniş diapazon sonrakı daxili şəkilçini kölgədə qoya bilər və proksisi açıq-aşkar keçməli olan host ondan istifadə etməyə davam edir. Kimsə siyasətin səhv olduğunu israr etdikdə, bu iddianın həll olunduğu yeganə yer skriptdir.

Skript hər hansı qərar verməzdən əvvəl endirilməlidir

Siyasəti endirmək üçün adın həll olunması və faylı təqdim edən hər şeyə marşrut lazımdır və qoşulmuş tunel heç birini nəzərdə tutmur. Əgər host yalnız özəl DNS vasitəsilə həll olunursa, o anda istifadə edilən həlledici endirmənin başlaya biləcəyini müəyyən edir. Əgər host özəl diapazondadırsa, marşrut bu maşından mövcud olmalıdır, həmkarın noutbukundan deyil. Əvvəlki sessiyada keşlənmiş nüsxə keşin vaxtı bitənə və ya maşın yenidən başlayana qədər bütün bunları gizlədir.

Aşağıdakı üç yoxlamanı sıra ilə aparın və ilk uğursuzluqda dayanın, çünki mərhələlər eyni səbəbi paylaşmır. Birlikdə onlar siyasətin konfiqurasiya olunub-olunmadığını, ona çatmağın mümkün olub-olmadığını və nə qaytardığını göstərir.

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

Birinci əmr aktiv xidmət üçün proksi lüğətini, o cümlədən sistemin saxladığı istənilən avtomatik konfiqurasiya URL-ini çap edir. İkinci, bir adlandırılmış xidmətə bağlı URL-i bildirir və bu, Wi-Fi ilə Ethernet arasında keçən noutbukda əhəmiyyətlidir. Üçüncü faylı göstərmədən gətirir, belə ki 404, vaxt aşımı və həlledici nasazlığı fərqləndirilə bilər. Əgər o son əmr skripti qaytarır, tətbiqlər isə yenə uğursuz olursa, problem artıq gətirmə mərhələsini keçib.

DIRECT cavabı əslində nəyi atlayır

PAC spesifikasiyası klientə kiçik bir lüğət verir və DIRECT onun bir sözüdür. Bu söz klientə həmin sorğu üçün proksini atlamağı deyir və soketin sonra hansı interfeysdən istifadə edəcəyi barədə heç nə demir. Tam tuneldə birbaşa soket yenə də VPN-dən çıxır və tunelin çıxış ünvanını təyinat yerinə göstərir.

DIRECT cavabını VPN-dən kənar kimi oxumaq insanları yanlış tənzimləmə panelinə göndərən səhvdir. Əks mənzərə də eyni dərəcədə geniş yayılıb, çünki özəl proksiyə bölünmüş marşrutla çatmaq olar, maşının qalan hissəsi isə tuneldən kənarda qalır. Onda təyinatın bildirdiyi şey proksinin öz çıxışına aiddir və bu, başqa ölkədə ola bilər. Bir daxili host və bir ictimai host üçün gözləntini yazmaq bunu tez aşkara çıxarır, çünki skript çox vaxt ikisinə fərqli cavab verir. Hansı addımın ünvanı yaratdığını bildikdən sonra hesabat müəmmalı olmaqdan çıxır.

Bir səhv səhifəsi kimi görünən üç nasazlıq

Siyasət endirilə bilməz, seçilmiş proksiyə çatmaq mümkün olmaya bilər və xidmətə çatan sorğu orada yenə də rədd edilə bilər. Hər üçü vaxt aşımı və ya ümumi səhv səhifəsi kimi gəlir və heç biri pozulan mərhələni adlandırmır. Qərarı səhvin yanında tutmaq onları ayıran şeydir. Aşağıdakı iki sınaq skriptin seçdiyi addımı yoxlayır, qaytara biləcəyi hər budaq üçün birini.

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

Proksiyə tamamlanmış bağlantı məsələni autentifikasiyaya və ya proksinin öz siyasətinə keçirir və onun başqa sahibi var. Yolda proksi olmadan daxili hosta tamamlanmış bağlantı marşrutu istisna edir və siyasətə işarə edir. Hər iki əmr qabıq proksi dəyişənlərini ixrac etmirsə macOS proksi lüğətinə məhəl qoymur, ona görə əvvəlcə onları təmizləyin. Heç bir sınaq digərini sübut etmir, buna görə də bir səhv səhifəsi bu qədər uzun müddət yanıldır.

Biletlə birlikdə nəyi təhvil vermək lazımdır

Aktiv şəbəkə xidmətini, PAC URL-ini, uğursuz host üçün qiymətləndirmə nəticəsini və səhvin göründüyü mərhələni göndərin. Bu dördü növbəti şəxsə hansı qatın iştirak etdiyini təxmin etmək əvəzinə qərarı təkrar yaratmağa imkan verir. Test anındakı tunel vəziyyətini əlavə edin, çünki yenidən qoşulmadan əvvəl tutulmuş nəticə köhnəlmiş olur. Skriptin versiyasını da saxlayın, çünki siyasət faylı xəbərdarlıq olmadan dəyişir və dünənki cavab artıq aktual olmaya bilər.

Skript gətirilə bilmədikdə klientin necə davrandığını qeyd edin, çünki tətbiqlər fərqlidir və proksi qərarı cihaz miqyaslı dayandırma açarı deyil. Bəziləri birbaşa bağlantıya qayıdır, digərləri isə bağlı vəziyyətdə uğursuz olur və bu fərq nasazlığın sınmış proksi kimi, yoxsa işlək siyasət kimi görünməsini dəyişir. Hadisə zamanı ona güvənməzdən əvvəl dəqiq klient və versiya üçün davranışı təsdiqləyin.