Waarom mislukken sommige websites alleen met de VPN aan?

Dat één site faalt terwijl al het andere laadt, bewijst dat de tunnel verkeer draagt, en dat vernauwt het probleem meer dan de meeste mensen verwachten. Drie waarnemingen sorteren de rest: of je überhaupt een HTTP-antwoord kreeg, of de hostnaam naar een adres is omgezet, en of kleine verzoeken doorkomen terwijl grote blijven hangen. Gokken naar de VPN voordat je die antwoorden hebt, verplaatst de fout meestal in plaats van hem op te lossen.

Werk de waarnemingen op volgorde af, want een site die antwoordde kan niet ook zijn mislukt bij het omzetten. Als er helemaal niets laadt, zit je in de verkeerde tak en gelden de controles voor verbonden maar zonder internet.

Laat de foutmelding de tak kiezen

Een weigering, een botcontrole of een foutpagina betekent dat de dienst antwoordde, dus pakketten bereikten een toepassing en kwamen terug. Dat verschuift de vraag naar het toegangsbeleid van de site, dat de uitgang, het account of niet-gepubliceerde verzoekpatronen kan wegen. Een fout bij naamresolutie bereikte de site helemaal niet, en het adres is het eerste dat je moet bekijken. Een time-out zit tussen beide in: er werd iets verzonden en niets bevestigde het.

Certificaatwaarschuwingen horen bij een vierde tak. Ze betekenen dat de verbinding werd beantwoord door iets waarvan de browser de identiteit niet kon verifiëren, dus ofwel een proxy aan jouw kant ofwel een echte mismatch waar je niet doorheen moet klikken. Behandel dat als een vertrouwensvraag, niet als een routeringsvraag.

Een site die antwoordt bewijst geen kapotte tunnel

Als het antwoord een blokkeerpagina is, vergelijk dan dezelfde pagina via een tweede uitgang terwijl browser en machine ongewijzigd blijven. Volgt het resultaat het uitgangsadres, dan behandelt de site dat adres anders, en geen clientconfiguratie zal dat veranderen. Volgt de blokkade in plaats daarvan je browser, dan zit de oorzaak in een extensie, een opgeslagen proxy of een resolverinstelling. Twee runs scheiden die verklaringen goedkoop.

Fouten die alleen in de browser optreden, komen vaak genoeg voor om ze vroeg te testen. Een pagina die in de ene ondersteunde browser laadt en in een andere faalt, wijst op profielstatus, een contentblokkeerder of versleutelde DNS die in de browser zelf is ingesteld. Chrome's richtlijnen voor veilige DNS laten zien waar die instelling zit, en die via de ondersteunde bediening wijzigen werkt beter dan het apparaat resetten.

Als alleen grote overdrachten hangen, kijk naar de pakketgrootte

Een pagina die zijn kop rendert en dan blijft hangen, heeft een andere signatuur dan een pagina die nooit begint. Kleine antwoorden kunnen doorkomen terwijl een payload op volle grootte ergens wordt weggegooid dat de afzender niets kan melden, en zo ziet een pad-MTU-fout eruit vanuit een browser. Vergelijk een piepklein verzoek en een groot verzoek naar dezelfde host voordat je over filtering gaat theoriseren. Path MTU Discovery hoort de kleinste linkgrootte langs het pad te leren, en dat hangt af van ICMP-feedback die gefilterde netwerken stelselmatig weggooien.

Test die hypothese met een grootte-sweep in plaats van één ping. Een fout die bij een consistente payloadgrootte begint is sterk bewijs, terwijl een fout die rondzwerft dat niet is.

Bevestig de oplossing op het verzoek dat faalde

Test de oorspronkelijke bewerking opnieuw, niet de startpagina, want een gecachte schil kan renderen terwijl de API-aanroep achter een aanmelding nog steeds faalt. De onderstaande commando's scheiden naamresolutie, een klein verzoek en een groot verzoek naar dezelfde host. Vervang hostnaam en pad door die uit het verzoek dat echt brak.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Als het dig-antwoord verschilt van wat de browser gebruikte, is de resolver de variabele en is de DNS-instelling van de browser zelf de plek om te kijken. Als het kleine verzoek een status teruggeeft terwijl het grote blijft hangen, werk dan de pakketgrootte-tak af. Als beide time-out gaan, staan het uitgangspad en de omgang van de site met dat adres weer op tafel.

Houd de wijziging die het oorspronkelijke verzoek liet slagen en draai de rest terug. Een hoop gelijktijdige wijzigingen aan browser, resolver en client zorgen dat je niet meer kunt zeggen welke ervan ertoe deed.