De ce un proxy PAC într-un VM oaspete eșuează cu URL-ul gazdei

„Gazda folosește acest fișier PAC, așa că am pus același URL în VM” este o propoziție rezonabilă și un plan incomplet. Un URL PAC indică un script de politică, nu un proxy. Până când oaspetele nu poate obține acel script, nu îl poate evalua cu adresele proprii ale oaspetelui și apoi nu poate ajunge la orice proxy pe care scriptul îl numește, URL-ul este doar un șir într-un câmp de setări. Cea mai mare parte a confuziei din jurul politicii de proxy în mașinile virtuale vine din tratarea acelei singure linii ca întreaga configurație.

Un URL PAC este un script, nu un proxy

Fișierul conține o funcție care primește un URL și o gazdă și returnează o descriere de proxy sau cuvântul DIRECT. Nimic din URL nu îi spune aplicației unde să trimită traficul; acea decizie se ia în timpul executării, în interiorul scriptului, cu date pe care scriptul le cere platformei. O fereastră de setări care acceptă un URL PAC acceptă un indicator către o procedură de decizie.

Această distincție este motivul pentru care copierea URL-ului poate părea că a funcționat. Câmpul este completat, setarea este salvată, iar defecțiunea apare abia mai târziu, când scriptul nu poate fi obținut sau când returnează un proxy la care oaspetele nu poate ajunge.

Cele patru pași eșuează fiecare în felul său

În interiorul oaspetelui trebuie să se întâmple patru lucruri în ordine, iar fiecare are propria semnătură de eroare. Oaspetele obține fișierul PAC. Aplicația evaluează scriptul pentru URL-ul solicitat folosind informații locale. Proxy-ul selectat este rezolvat și este atins. Autentificarea are loc dacă proxy-ul o cere.

Începeți prin a demonstra obținerea, pentru că tot restul este lipsit de sens fără ea. Un fișier PAC pe un server privat necesită o cale permisă către acel server înainte ca orice regulă să poată ajuta, iar o alegere de proxy într-un script inaccesibil nu poate crea calea care l-ar obține:

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

Dacă acea cerere eșuează din oaspete și funcționează din gazdă, problema este calea oaspetelui către serverul PAC, nu conținutul scriptului. Dacă returnează un fișier JavaScript, treceți la al doilea pas și aflați ce decide scriptul pentru contextul oaspetelui.

Același script decide altfel în interiorul unui VM

Funcțiile PAC pot inspecta gazda solicitată și informații despre mașina care face evaluarea. O regulă construită pe adresa proprie a clientului, de exemplu una care verifică o adresă de interfață sau apartenența la o subrețea, va vedea adresa oaspetelui, nu pe cea a gazdei fizice. În spatele NAT-ului din partea gazdei acestea sunt adrese diferite, așa că același script poate alege alt proxy sau poate reveni la DIRECT în interiorul VM-ului.

Aceasta nu este o eroare în script. Scriptul face exact ceea ce a fost scris să facă, cu o intrare diferită, și asta explică raportul confuz în care gazda folosește proxy-ul, iar oaspetele se conectează direct. Reproduceți decizia în loc să raționați despre ea: un evaluator PAC care primește o adresă și un URL, dacă distribuția dumneavoastră include unul, rezolvă întrebarea cu o singură comandă. În caz contrar, testați cu aplicația care va fi folosită efectiv și citiți jurnalul ei de proxy în loc să ghiciți.

Nu concluzionați că oaspetele a moștenit setările de proxy ale gazdei pentru că traficul său trece printr-o traducere din partea gazdei. Traducerea de rețea transmite pachete; ea nu copiază configurația aplicațiilor, iar proxy-ul de sistem este configurație de aplicație.

Instrumente care nu citesc deloc PAC

Instrumentele din linia de comandă sunt o graniță separată, și exact aici se pierde mult timp. curl nu execută fișiere PAC, după cum documentația sa despre proxy spune clar. Direcționarea unei variabile de proxy către URL-ul de descărcare al PAC nu transformă scriptul într-un punct final de proxy; instrumentul va încerca să vorbească HTTP cu un fișier JavaScript și va eșua într-un mod care pare o problemă de rețea.

Același lucru se aplică multor manageri de pachete, medii de execuție pentru limbaje și instrumente de build, care respectă doar variabile de proxy explicite sau propria configurație. Dacă testul care vă interesează este un instrument CLI, configurați-l cu proxy-ul concret pe care scriptul PAC l-ar fi ales, și notați cum ați ajuns la acea alegere, ca următoarea persoană să o poată repeta.

Pentru aplicațiile de birou pe Linux, setarea de sistem trebuie comutată în modul automat și trebuie să primească și un URL; un URL salvat în timp ce modul este încă manual nu face nimic. Verificați ambele, și verificați-le în interiorul oaspetelui:

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

DIRECT este și o decizie

Un rezultat PAC de DIRECT înseamnă că aplicația ocolește proxy-ul HTTP, nu că a scăpat din rețea. Conexiunea rezultată poate urma în continuare o rută a sistemului de operare printr-un tunel, sau poate eșua din motive care nu au nicio legătură cu folosirea proxy-ului. Invers, un rezultat de proxy descrie cererea unei singure aplicații, nu fiecare proces din oaspete.

Așadar verificați în direcția în care a fost scrisă cerința. Dacă cerința este „această aplicație ajunge la site-ul intern”, demonstrați că acea aplicație ajunge, și notați care proxy sau rută a transportat-o. Dacă cerința este „VM-ul este în rețeaua companiei”, un browser care funcționează printr-un proxy selectat este dovadă pentru acel browser și nimic mai mult.

Reparați lanțul în interiorul oaspetelui în loc să opriți tunelul gazdei sau să relaxați politica de redirecționare pentru ca un test să treacă. Lanțul are patru verigi, iar o modificare care sare una dintre ele va rezista până la următoarea actualizare a scriptului sau schimbare a adresei oaspetelui.