Waarom Firefox een intranet-host in je bypass-subnet nog steeds via de proxy laat gaan
Een bypass-bereik voor letterlijke IP-adressen geeft niet automatisch een hostnaam vrij die in dat bereik wordt omgezet.
Je hebt 192.168.0.0/16 in de lijst ‘Geen proxy voor’ van Firefox gezet. http://192.168.1.20/ openen gaat rechtstreeks, maar http://wiki.office.example/ bereikt nog steeds de proxy. Beide URL's kunnen naar dezelfde server verwijzen.
Het belangrijke verschil is de bestemmingsreeks die Firefox vergelijkt. Een uitzondering voor een IP-bereik en een uitzondering voor een hostnaam zijn niet uitwisselbaar. Ga er niet van uit dat de handmatige bypass-lijst elke hostnaam omzet voordat je besluit of een regel voor adresbereik geldt.
| Ingevoerde URL | Informatie beschikbaar voor vergelijking |
|---|---|
| http://192.168.1.20/ | Een letterlijk IP-adres |
| http://wiki.office.example/ | Een hostnaam |
Als het intranet een eigen domein heeft, gebruik dan de juiste uitzonderingen voor hostnaam of domein in plaats van te gokken naar welke adressen de namen kunnen worden omgezet. Houd niet-gerelateerde openbare diensten buiten die uitzondering. Een domein kan zowel interne als extern gehoste applicaties bevatten.
Mozilla's oorspronkelijke uitleg maakt uitdrukkelijk onderscheid tussen letterlijke IP-overeenkomsten en namen die naar die IP's worden omgezet. Dat document is historisch, dus controleer het gedrag van de huidige client en de beleidsinterface voordat je elk syntaxisvoorbeeld eruit kopieert.
Wanneer het beleid DNS nodig heeft
Een PAC-bestand biedt een aparte, expliciete plek voor DNS-bewuste beslissingen. Het introduceert ook faalmodi bij distributie, uitvoering en omzetting van het script. Gebruik het omdat de routeringseis die logica nodig heeft, niet alleen om een lange bypass-lijst korter te laten lijken.
Inspecteer bij een beheerde installatie ook het effectieve beleid van Firefox. Een vergrendeld proxybeleid kan verklaren waarom een lokale aanpassing de route niet bepaalt.
Noteer bij het oplossen van problemen de letterlijke URL die je hebt ingevoerd, niet alleen het uiteindelijke IP van de server. Het vergelijken van een hostnaam-URL met een letterlijke-adres-URL verandert de informatie die beschikbaar is voor de bypass-beslissing, en dat is precies waarom de twee verzoeken verschillende routes kunnen nemen.