VPN über DNS ist nicht dasselbe wie ein VPN-DNS-Server

VPN über DNS beschreibt eine Transportidee und ist kein Synonym dafür, ein Gerät auf einen eigenen Resolver zu zeigen. Die Frage, die die Verwirrung klärt, ist einfach: Was transportieren die DNS-Nachrichten eigentlich? Ein gewöhnliches VPN kann einen Resolver einrichten, damit abgedeckte Anwendungen private Namen finden, und ein Wechsel dieses Resolvers ändert nur die Namensauflösung. Führen Sie die Prüfungen unten der Reihe nach aus, weil die drei Anordnungen Vokabular und fast nichts sonst teilen.

Trennen Sie die drei Anordnungen

In der ersten Anordnung stellt das VPN einen Resolver oder eine Einstellung für die Namensrichtlinie bereit. Anwendungsdaten laufen weiterhin über ihre eigenen Netzwerkverbindungen, und der Tunnel beeinflusst nur, welcher Server die Abfrage beantwortet.

In der zweiten schützt verschlüsseltes DNS den DNS-Austausch selbst. DNS über HTTPS und DNS über TLS verpacken Abfragen an den gewählten Resolver und transportieren keine Pakete anderer Anwendungen. Sie verbergen die Abfragenamen auch nicht vor dem Resolver, den Sie gewählt haben, was eine andere Vertrauensgrenze ist als sie vor dem lokalen Netz zu verbergen.

In der dritten kodiert ein mitwirkender Client andere Daten in DNS-Nachrichten, und ein mitwirkender Endpunkt rekonstruiert sie. Der gewöhnliche Resolver-Pfad wird zum Transport, und der Resolver ist nun Bestandteil des Datenpfads statt ein Namensdienst.

Prüfen Sie, was die DNS-Nachrichten transportieren

Wechseln Sie den Resolver und beobachten Sie, ob sich der Datenpfad der Anwendung ändert. Wenn die Anwendung weiterhin dieselben Adressen über dieselben Sockets verbindet, haben Sie die Namensauflösung geändert und sonst nichts.

Ein über DNS transportierter Tunnel braucht eine passende Anordnung auf der Serverseite. Iodine ist ein dokumentiertes Beispiel: seine Projektdokumentation beschreibt einen IP-Tunnel durch DNS, und er benötigt eine Serverkomponente, die die Kodierung versteht. Die Eingabe einer öffentlichen Resolver-Adresse in Android liefert diesen Endpunkt nicht, und ein Marketingbegriff, den zwei Produkte teilen, ist keine Protokollspezifikation.

Ein Mitschnitt ist die entscheidende Prüfung. Sehen Sie gewöhnliche Abfragen an den Resolver und sonst nichts, gibt es keinen Tunnel. Sehen Sie Nutzdaten, die in Abfragenamen und Antworten kodiert sind, haben Sie den Träger gefunden, und die nächste Frage ist, wie viel er bewegen kann.

Prüfen Sie die Kapazität, bevor Sie sich festlegen

DNS wurde für Abfragen und Antworten entworfen, nicht für Massenzustellung. Kodierungsaufwand, Größenbeschränkungen für Nachrichten und das Verhalten der Resolver nehmen alle einen Anteil am nominellen Pfad, sodass die nutzbare Kapazität niedriger ist, als die zugrunde liegende Verbindung vermuten lässt. Behandeln Sie jede Durchsatzzahl, die Sie nicht auf Ihrem eigenen Pfad gemessen haben, als Hypothese und nicht als Budget. Messen Sie beide Richtungen, weil Upload und Download auf einem Träger nach dem Anfrage-Antwort-Muster an unterschiedliche Grenzen stoßen können.

Der Client muss außerdem entscheiden, welcher Datenverkehr in den Tunnel gelangt. Eine lokale VPN-Dienstschnittstelle kann Pakete sammeln, aber die Schnittstelle sagt nichts darüber aus, wie der entfernte Transport sie schützt oder weiterleitet. Fragmentierung und erneute Übertragung verhalten sich anders, wenn der Träger ein Anfrage-Antwort-Protokoll statt eines Streams ist, und eine Verbindung, die offen bleibt, sagt wenig über interaktive Latenz.

Messen Sie mit dem Datenverkehr, den Sie transportieren wollen. Ein Tunnel, der für einen periodischen Herzschlag gut wirkt, kann für eine interaktive Sitzung unbrauchbar sein, und das Umgekehrte gilt ebenso.

Prüfen Sie die Sicherheit des Trägers

Gehen Sie nicht davon aus, dass DNS-Kapselung Vertraulichkeit oder starke Authentifizierung liefert. Der Resolver-Pfad und der Tunnelendpunkt sehen, was die Implementierung offenlegt, und diese Offenlegung variiert je nach Entwurf.

Verschlüsselung und die Wahl des Trägers sind getrennte Eigenschaften. Ein Tunnel kann über einen einfachen IP-Pfad verschlüsselt werden, und ein über DNS transportierter Tunnel kann mit oder ohne Schutz seiner Nutzdaten gebaut werden. Behalten Sie die HTTPS der Anwendung unabhängig davon bei, und bewerten Sie das tatsächliche Sicherheitsdesign des Tunnels statt seinen Namen.

Wenn die Anforderung Privatsphäre gegenüber dem lokalen Netz ist, beantworten verschlüsseltes DNS und ein Datentunnel unterschiedliche Teile davon. Schreiben Sie auf, gegen welchen Beobachter Sie sich wehren, bevor Sie eines wählen.

Passen Sie die Behebung zum tatsächlichen Fehler

Bei einem gewöhnlichen langsamen VPN fügt der Ersatz durch einen über DNS transportierten Tunnel einen eingeschränkten Transport oben auf das Problem. Er behebt weder Funkqualität noch Überlastung oder Serverlast und macht sie meist sichtbarer.

Bei Fehlern mit privaten Namen prüfen Sie zuerst die beabsichtigte Resolver-Richtlinie: welcher Server antworten soll, welche Namen im Geltungsbereich liegen und ob der Client sie nutzen darf. Wählen Sie dann einen autorisierten Transport, der zur Anforderung passt, und halten Sie die Resolver-Konfiguration im Änderungsprotokoll fest, damit der nächste Vorfall nicht dieselbe Suche neu beginnt.

Die Checkliste ist kurz: Anordnung bestimmen, prüfen, was die Nachrichten transportieren, Kapazität messen und dann das Vertrauen prüfen. Jeder Schritt, der nicht zum Symptom passt, bedeutet, dass die anderen beiden Anordnungen noch im Spiel sind.