Warum scheitern manche Webseiten nur mit aktivem VPN?

Wenn eine Seite ausfällt, während alles andere lädt, beweist das, dass der Tunnel Datenverkehr führt, und engt das Problem stärker ein, als die meisten erwarten. Drei Beobachtungen ordnen den Rest: ob du überhaupt eine HTTP-Antwort erhalten hast, ob der Hostname zu einer Adresse aufgelöst wurde und ob kleine Anfragen durchgehen, während große hängen. Wer vor diesen Antworten am VPN herumrät, verschiebt den Fehler meist, statt ihn zu beheben.

Arbeite die Beobachtungen der Reihe nach ab, denn eine Seite, die geantwortet hat, kann nicht zugleich an der Auflösung gescheitert sein. Wenn gar nichts lädt, bist du im falschen Zweig, und es gelten die Prüfungen für verbunden, aber ohne Internet.

Lass die Fehlermeldung den Zweig wählen

Eine Verweigerung, eine Bot-Prüfung oder eine Fehlerseite bedeutet, dass der Dienst geantwortet hat, also Pakete eine Anwendung erreicht und zurückgefunden haben. Damit verschiebt sich die Frage zur Zugriffsrichtlinie der Seite, die die Ausgangsadresse, das Konto oder nicht veröffentlichte Anfragemuster gewichten kann. Ein Fehler bei der Namensauflösung hat die Seite nie erreicht, und die Adresse ist das Erste, was zu prüfen ist. Eine Zeitüberschreitung liegt dazwischen: Es wurde etwas gesendet, und nichts hat es bestätigt.

Zertifikatswarnungen gehören zu einem vierten Zweig. Sie bedeuten, dass die Verbindung von etwas beantwortet wurde, dessen Identität der Browser nicht überprüfen konnte, also entweder ein Proxy auf deiner Seite oder eine echte Diskrepanz, die du nicht wegklicken solltest. Behandle das als Vertrauensfrage, nicht als Routingfrage.

Eine antwortende Seite beweist noch keinen kaputten Tunnel

Wenn die Antwort eine Blockseite ist, vergleiche dieselbe Seite über einen zweiten Ausgang, während Browser und Rechner unverändert bleiben. Folgt das Ergebnis der Ausgangsadresse, behandelt die Seite diese Adresse anders, und keine Client-Konfiguration wird sie umstimmen. Folgt die Sperre stattdessen deinem Browser, sitzt die Ursache in einer Erweiterung, einem gespeicherten Proxy oder einer Resolver-Einstellung. Zwei Durchläufe trennen diese Erklärungen billig.

Fehler, die nur im Browser auftreten, sind häufig genug, um sie früh zu testen. Eine Seite, die in einem unterstützten Browser lädt und in einem anderen scheitert, deutet auf Profilzustand, einen Inhaltsblocker oder im Browser selbst konfiguriertes verschlüsseltes DNS hin. Chromes Anleitung zu sicherem DNS zeigt, wo diese Einstellung liegt, und sie über die unterstützte Steuerung zu ändern ist besser, als das Gerät zurückzusetzen.

Wenn nur große Übertragungen hängen, prüfe die Paketgröße

Eine Seite, die ihren Kopf rendert und dann hängt, hat eine andere Signatur als eine Seite, die nie startet. Kleine Antworten können durchgehen, während eine Nutzlast in voller Größe irgendwo verworfen wird, das dem Absender nichts signalisieren kann, und genau so sieht ein Pfad-MTU-Fehler aus einem Browser aus. Vergleiche eine winzige Anfrage und eine große an denselben Host, bevor du über Filterung theoretisierst. Die Pfad-MTU-Erkennung soll die kleinste Verbindungsgröße entlang des Pfads lernen, und sie hängt von ICMP-Rückmeldungen ab, die gefilterte Netze routinemäßig verwerfen.

Teste diese Hypothese mit einem Größen-Sweep statt mit einem einzelnen Ping. Ein Fehler, der bei einer gleichbleibenden Nutzlastgröße beginnt, ist ein starker Beweis, während ein umherwandernder Fehler keiner ist.

Bestätige die Lösung an der Anfrage, die gescheitert ist

Teste den ursprünglichen Vorgang erneut, nicht die Startseite, denn eine gecachte Hülle kann rendern, während der API-Aufruf hinter einer Anmeldung weiterhin scheitert. Die Befehle unten trennen Namensauflösung, eine kleine Anfrage und eine große an denselben Host. Ersetze Hostname und Pfad aus der Anfrage, die tatsächlich gescheitert ist.

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

Wenn die dig-Antwort von der des Browsers abweicht, ist der Resolver die Variable, und die DNS-Einstellung des Browsers ist die Stelle zum Nachsehen. Wenn die kleine Anfrage einen Status zurückgibt, während die große hängt, bearbeite den Zweig zur Paketgröße. Wenn beide in eine Zeitüberschreitung laufen, stehen der Ausgangspfad und der Umgang der Seite mit dieser Adresse wieder auf dem Tisch.

Behalte die Änderung, die die ursprüngliche Anfrage erfolgreich gemacht hat, und mache den Rest rückgängig. Ein Haufen gleichzeitiger Änderungen an Browser, Resolver und Client lässt dich nicht mehr sagen, welche davon zählte.