Een PAC-bestand live controleren: welke regel echt geldt

Het onderdeel dat het laatst wordt gecontroleerd

Weinig onderdelen in het Zscaler-beheer beslissen zoveel en worden zo zelden als eerste bekeken als het PAC-bestand. Het bepaalt welke weg een verbinding neemt, en doet dat stil op de achtergrond. Gedraagt een verzoek zich vreemd, dan gaat het vermoeden meestal eerst naar de policy of het netwerk. Het PAC-bestand komt pas aan de beurt als al het andere is uitgesloten.

De reden daarvoor is zelden nalatigheid. PAC-bestanden zijn proxy-auto-config-scripts, dus JavaScript-functies met een eigen vormtaal. Wie er niet regelmatig mee werkt, leest ze langzaam. Ontbreekt de ene collega die zich er zeker bij voelt, dan wordt het bestand een blackbox: niemand wijzigt iets, uit angst iets belangrijkers te breken.

Die voorzichtigheid is terecht. Een PAC-bestand wordt bij elke verbindingsopbouw geëvalueerd, voor elke gebruiker, op elke locatie. Een fout erin werkt onmiddellijk en breed door. Zo ontstaat een toestand die veel organisaties kennen: het bestand werkt, niemand doorgrondt het helemaal, en iedereen hoopt dat daar niets aan hoeft te veranderen.

Wat PAC-Lens doet

PAC-Lens haalt het PAC-bestand op dat daadwerkelijk actief is in uw tenant, controleert de syntaxis en beantwoordt de ene vraag waar het in de praktijk om gaat: welke regel geldt voor dit specifieke adres?

U voert een test-URL in en ziet de van toepassing zijnde regel gemarkeerd in de code, samen met de weg die deze voorschrijft. Het verschil met de tot nu toe gebruikelijke aanpak zit niet alleen in de snelheid, maar in het soort resultaat: van een vermoeden wordt een bevinding. Hoe een testadres wordt ingevoerd en de overeenkomende regel direct gemarkeerd in de code verschijnt, laat onze video van ruim tweeënhalve minuut hierover zien.

Het woord "actief" is daarbij belangrijk. Gecontroleerd wordt niet een kopie uit de bestandsmap die misschien drie wijzigingen oud is, maar de versie die daadwerkelijk in de tenant wordt uitgeleverd. Precies dit verschil is bij het opsporen van fouten vaak doorslaggevend.

Een geval uit de dagelijkse praktijk

Een gebruiker meldt dat een interne applicatie op kantoor niet bereikbaar is, maar wel vanuit thuiswerken. Drie verklaringen zijn aannemelijk: de policy, het netwerk of het PAC-bestand. Zonder hulpmiddel wordt daar een keten van vervolgvragen van, vaak over meerdere niveaus en meerdere dagen.

Met PAC-Lens test u het betrokken adres rechtstreeks en ziet u welke PAC-regel geldt en waarheen deze het verzoek stuurt. Blijkt dat het bestand het verzoek langs de tunnel stuurt, dan is de oorzaak gevonden. Blijkt het tegendeel, dan is het PAC-bestand duidelijk uitgesloten.

Het gesprek dat daarna volgt, heeft een andere kwaliteit. Het begint met een bevinding in plaats van een vermoeden, en er is een regel aan te wijzen waar alle betrokkenen hetzelfde bij zien.

Waarom een vrijspraak net zo waardevol is

Bij het opsporen van fouten telt niet alleen waar het probleem ligt, maar ook waar het zeker niet ligt. Een netjes uitgesloten vermoeden verkort elke volgende ronde, omdat het voorkomt dat hetzelfde spoor twee keer wordt gevolgd.

In de praktijk is dat het vaker voorkomende geval: het PAC-bestand is meestal in orde. Alleen weet niemand dat vooraf met zekerheid, en die onzekerheid kost bij elke storing opnieuw tijd.

Als u toch al aan het PAC-bestand werkt

PAC-Lens leest en verklaart. Wie nieuwe regels wil bouwen, vindt dat in PAC Configuration Studio: een begeleide bouwomgeving die het zonder eigen JavaScript-kennis afkan en dezelfde trace-engine gebruikt als PAC-Lens. Een testresultaat daar is daarmee net zo betrouwbaar als een live bevinding hier.

De studio maakt, test en exporteert het definitieve PAC-bestand om te uploaden naar Zscaler. Het schrijft niet uit zichzelf naar de tenant. Het definitieve bestand blijft in uw handen, de upload verloopt zoals u gewend bent.

Om dit zonder tenant na te bootsen: de gratis PAC Tester wordt geleverd met een voorbeeldbestand. Zet het gesimuleerde client-IP op 192.168.1.50 en de gesimuleerde tijd op een werkdag, dan nemen twee adressen twee verschillende wegen. https://intranet.internal.acme.example/start eindigt op DIRECT, overeenkomende regel #3 (dnsDomainIs). https://files.acme-partner.example/report.pdf eindigt op PROXY partner-gw.acme.example:8080, overeenkomende regel #5 (shExpMatch). Wie het bestand eerst wil bouwen, exporteert het in de PAC Builder en laadt precies dit bestand in de tester.

Daar horen twee grenzen bij. Op zaterdag en zondag geeft regel #6 van het voorbeeld alles terug op DIRECT wat daar terechtkomt, vandaar de werkdag. En de tester doet geen netwerkverzoeken: bij hostnamen geven isInNet en dnsResolve geen antwoord. Een geslaagde test zegt wat dit bestand teruggeeft, niet hoe elke browser en elke DNS-resolver zich gedraagt.

Wat het apparaat kan bijdragen

PAC-Lens beantwoordt welke regel zou moeten gelden. Een tweede vraag blijft open: welke weg neemt een specifiek apparaat daadwerkelijk? Waar CentaurNexusAgent geïnstalleerd is, komt dat perspectief erbij. Deze meet regelmatig het pad en herkent of een verzoek via Zscaler loopt. Naast de regel staat zo de waarneming vanaf de werkplek.

Beide samen maken de diagnose betrouwbaarder: de regel zegt wat zou moeten gelden, de meting wat daadwerkelijk aankomt. Wijken ze van elkaar af, dan is dat zelf al de bevinding.

De agent verzamelt daarbij uitdrukkelijk geen bezochte adressen, geen hostnamen en geen pagina-inhoud. Overgedragen worden statuswaarden, geen inhoud.