Los proxyproblemen in drie lagen op: controleer eerst of het publieke IP en de exitlocatie echt zijn gewijzigd, onderscheid daarna DNS-, timeout- en certificaatfouten en controleer ten slotte authenticatie, poort en protocol.
De proxy is ingesteld en gebruikersnaam en wachtwoord kloppen, maar de verbindingscontrole meldt toch een fout. Veel mensen nemen dan meteen contact op met de proxyleverancier, wisselen van node, veranderen de poort of dringen aan bij support. Dat is meestal niet efficiënt, omdat de oorzaak overal in het volledige netwerkpad kan zitten en de proxy slechts één onderdeel daarvan is.
In plaats van willekeurig instellingen te veranderen, kunt u beter een vaste volgorde van buiten naar binnen volgen: controleer eerst of de exit echt actief is, kijk daarna of het netwerkpad werkt en onderzoek pas vervolgens de authenticatie en het protocol op applicatieniveau. Met deze drie lagen zijn de meeste problemen te lokaliseren.
Is de exit echt actief?
Deze stap wordt gemakkelijk overgeslagen omdat de configuratie geslaagd lijkt. Een succesvolle configuratie en verkeer dat daadwerkelijk via de proxy loopt zijn echter twee verschillende zaken.
Controleer twee dingen. Ten eerste: is het IP-adres veranderd? Noteer het publieke IP zonder proxy, schakel de proxy in en controleer opnieuw. Zijn beide adressen gelijk, dan gaat het verkeer helemaal niet via de proxy en heeft verder zoeken weinig zin. Ten tweede: klopt de locatie? Proxygegevens bevatten meestal land, regio, staat of provincie, plaats, coördinaten tot zes decimalen en postcode. Vergelijk deze met de regio die u hebt aangeschaft. Een systeemtijdzone die duidelijk niet bij de exitregio past is eveneens een waarschuwingssignaal.
Als de exit niet actief wordt, ligt de oorzaak vaak bij achtergebleven lokale instellingen en niet bij de provider. Wanneer een eerder gebruikte netwerktool bij afsluiten niet goed heeft opgeruimd, kunnen omgevingsvariabelen zoals HTTP_PROXY of HTTPS_PROXY op systeemniveau blijven staan, of kunnen in macOS de schakelaars voor Web Proxy of SOCKS Proxy nog aanstaan. De client kan dan denken dat hij de systeemproxy gebruikt, terwijl verzoeken er in werkelijkheid omheen gaan. Zulke resten verwijderen en opnieuw testen is vaak nuttiger dan de proxy helemaal opnieuw configureren.
Drie veelvoorkomende fouten in het netwerkpad
Als de exit is bevestigd, controleert u vervolgens of het verzoek de bestemming werkelijk bereikt.
DNS-resolutie is het eerste mogelijke knelpunt. Dit kan zich uiten als een resolutiefout of als een duidelijk verkeerd resultaat, waarbij een domein dat naar de doeldienst hoort te wijzen op een onverwacht adres uitkomt. Probeer opnieuw met een openbare DNS-server of wis de lokale DNS-cache en kijk of het probleem verdwijnt.
Het tweede type is een verbindingstimeout. Wanneer een firewall of beveiligingsprogramma de poort blokkeert, blijft de aanvraag vaak laden totdat er een timeout optreedt. Controleer de regels waarmee de poort wordt toegestaan en let ook op beperkingen van de omgeving zelf, zoals een bedrijfsnetwerk of openbare wifi. Een snelle test is rechtstreeks verbinden zonder proxy. Als dan ook geen enkele website opent, ligt het probleem in het basisnetwerk en niet bij de proxy. Start de router opnieuw op of schakel over naar een mobiele hotspot om dit te bevestigen.
Certificaatfouten verdienen aparte aandacht. Bij meldingen dat een certificaat niet wordt vertrouwd of dat de handshake mislukt, denken veel mensen direct aan ontsleuteld verkeer of een vervangen certificaat. Dat kan, maar er is ook een minder opvallende oorzaak: een onjuiste lokale tijd. Veel authenticatie- en sessiemechanismen zijn afhankelijk van tijdstempels. Als de lokale tijd meer dan 5 minuten afwijkt van de servertijd, kan handtekeningvalidatie mislukken en kan de verbinding worden geweigerd; bij HTTPS uit zich dit als mislukte certificaatvalidatie. Controleer bij certificaatfouten daarom ook de tijdsynchronisatie van het systeem. Is die niet goed, schakel automatische synchronisatie in, corrigeer de tijd direct, start de client opnieuw en test nogmaals.
Verwar authenticatie en protocol niet
Als de proxyserver bereikbaar is maar het verkeer nog steeds niet werkt, ligt het probleem meestal op applicatieniveau.
Authenticatiegegevens zijn de meest voorkomende oorzaak. Gebruikersnaam, wachtwoord en authenticatiemethode moeten overeenkomen met wat de provider heeft geleverd; ook een gewijzigd wachtwoord dat niet in de configuratie is bijgewerkt komt vaak voor. Controleer bij handmatige configuratie bovendien of de ingevoerde poort gelijk is aan de poort waarop de proxytool zelf luistert. De nummers kunnen op elkaar lijken, maar met de verkeerde poort komt er helemaal geen verbinding tot stand.
De tweede categorie is een protocolmismatch. HTTP, HTTPS en SOCKS5 zijn niet onderling uitwisselbaar: geeft de provider SOCKS5 en staat in de configuratie HTTP, dan zal de controle mislukken. Controleer ook of de proxy toegang tot de doelsite en doelpoort toestaat, want sommige proxies beperken bepaalde doelen of protocollen.
De snelste manier om een nodeprobleem van een configuratieprobleem te onderscheiden is een andere node testen. Werkt de nieuwe node wel, dan ligt het aan de oorspronkelijke node. Werkt die ook niet, ga dan terug naar de configuratie en het netwerkpad. Wijzig niet steeds meerdere parameters tegelijk; verander één variabele per keer en noteer het resultaat, anders kunnen uw eigen wijzigingen de echte oorzaak verbergen.
Verbonden betekent niet dat de omgeving bruikbaar is
Er is nog een veelvoorkomende valkuil. De proxy kan een normale verbinding tonen terwijl het account toch vaak risicocontroles activeert. Het probleem zit dan mogelijk niet in de vraag of er verbinding is, maar in de vraag of de exit eruitziet als een normale gebruikersomgeving.
Controleer opnieuw de basispunten: komt de exitlocatie overeen met de registratieregio van het account; is het IP-type passend, omdat platforms datacenter-IP's en residentiële IP's verschillend kunnen beoordelen; en is dit IP eerder door de doelsite gemarkeerd? Als er via hetzelfde IP veel afwijkend gedrag heeft plaatsgevonden, kunnen latere gebruikers daar last van krijgen. Controleer na een geslaagde verbindingstest daarom ook kort hoe schoon de exit is.
Als één apparaat meerdere omgevingen gebruikt, kunt u exits het best één-op-één toewijzen: elke omgeving krijgt een eigen exit. Problemen zijn dan afzonderlijk te lokaliseren en als één exit wordt gemarkeerd, raakt dat alleen de bijbehorende omgeving in plaats van alles tegelijk. PurpleMark configureert en isoleert exits in beheer van meerdere omgevingen precies volgens dit principe.
Deze methoden voor probleemoplossing zijn uitsluitend bedoeld voor technische uitwisseling. Gebruik de betreffende tools en diensten alleen in overeenstemming met toepasselijke wet- en regelgeving.
