NetGuards SOCKS-Modus deckt TCP ab, nicht jedes Protokoll

NetGuard belegt Androids VPN-Schnittstelle, um Datenverkehr zu filtern, und kann unterstützte Verbindungen an einen SOCKS-Endpunkt übergeben. Diese beiden Tatsachen werden oft als „das Telefon ist in einem VPN“ gelesen, ein Schluss, den der Mechanismus nicht stützt. Der Filter sieht Pakete; der Proxy sieht nur die Verbindungen, die ihm tatsächlich übergeben wurden. Zwischen diesen beiden Aussagen steht die ganze Frage der Abdeckung.

Die FAQ des vorgelagerten Projekts dokumentiert sowohl die Beschränkung auf einen Dienst als auch die SOCKS-Option. Die Existenz der Option ist kein Beweis dafür, dass jedes erlaubte Paket sie nutzt, und genau aus dieser Lücke stammen die Fragen zur Abdeckung.

Zwei Weiterleitungswege in einer App

Die TCP-Seite der Implementierung enthält die SOCKS-Verbindungsbehandlung, sodass eine erlaubte TCP-Verbindung mit dem Proxy ausgehandelt und durch ihn hindurchgeführt werden kann. Die UDP-Seite hat einen eigenen Socket-Pfad, und ihre Sende- und Empfangsbehandlung hängt nicht von dieser TCP-Aushandlung ab. Ein Datagramm, das der Filter zulässt, kann daher das gewöhnliche Netz erreichen, ohne je den Proxy zu passieren. Nichts davon ist ein Defekt der App; es ist einfach das, was die beiden Wege umsetzen.

Diese Unterscheidung hat eine Folge, die Menschen in beide Richtungen falsch darstellen. Jedes UDP-Paket ein Leck zu nennen, ignoriert die Sperrregeln, weil ein abgelehntes Datagramm nie das Gerät verlässt. Die ganze Anordnung ein VPN zu nennen, ignoriert den erlaubten direkten Weg, weil ein Teil des Verkehrs tatsächlich ohne Proxy hinausgeht. Was Sie haben, ist ein gefiltertes Gerät mit teilweiser Proxyführung, und die ehrliche Beschreibung ist eine Matrix, kein Etikett.

UDP anzukündigen heißt nicht, es umzusetzen

Ein SOCKS-Server, der UDP-Unterstützung behauptet, fügt der App auf Ihrem Telefon nicht die passende clientseitige Behandlung hinzu. Die theoretischen Merkmale des Protokolls und das Verhalten des installierten Builds sind verschiedene Themen, und nur das zweite beschreibt Ihren Verkehr.

Prüfen Sie die Version und Konfiguration, die Sie tatsächlich betreiben, testen Sie dann einen harmlosen Datagrammfluss und beobachten Sie, ob er am Proxy erscheint. Alles andere ist eine Schlussfolgerung aus einer Funktionsliste, und Funktionslisten beschreiben Absichten statt Codepfade.

DNS ist ein dritter Weg, kein Detail

Die Namensauflösung fügt der Matrix ihren eigenen Zweig hinzu. Ein lokaler DNS-Weiterleiter, eine gewöhnliche UDP-Abfrage, ein vom Proxy selbst aufgelöster Zielhostname und ein verschlüsselter Resolver im Browser sind vier verschiedene Anordnungen. Sie unterscheiden sich darin, wer die Abfrage sieht und welcher Netzpfad sie trägt, und ihre Vermischung ergibt einen Test, der über die anderen nichts beweist.

Entscheiden Sie bewusst, welche Sie wollen. Wenn die Anforderung lautet, dass Namen durch den Tunnel aufgelöst werden, leistet eine Browsereinstellung allein das nicht, und ein Proxy, der Hostnamen selbst auflöst, ändert die Antwort nur für Verbindungen, die er tatsächlich behandelt.

Der Proxy-Transport ist nicht automatisch privat

Einfaches SOCKS ist keine verschlüsselte Strecke vom Telefon zum Proxy. Wenn der Endpunkt über einen anderen geschützten Weg erreicht wird, benennen Sie diesen Weg und seine Fehlerpolitik, denn ein Rückfall ins offene Netz macht eine private Anordnung ohne Warnung zu einer öffentlichen. Auch die eigene Authentifizierung des Proxys zählt: ein offener Listener auf einem gemeinsam genutzten Gerät ist ein Dienst, für den niemand Rechenschaft ablegt.

Anordnungen über Profile hinweg verdienen dieselbe Prüfung. Ein Arbeitsprofil-VPN schützt nur den Verkehr, der seinen Weg nutzt, und die Koexistenz einer Firewall im persönlichen Profil mit einem Arbeitstunnel beweist nicht, dass die Weiterverbindung der Firewall diesen Tunnel erreicht. Prüfen Sie Erreichbarkeit und Authentifizierung, statt anzunehmen, die beiden Profile arbeiteten zusammen.

Abdeckung mit einer Matrix prüfen statt mit einem Seitenaufruf

Wählen Sie für eine autorisierte Bewertung harmlose Beispiele, die jede Klasse abdecken, die Ihnen wichtig ist: erforderliches TCP, erlaubtes UDP und DNS in beiden Adressfamilien. Halten Sie für jedes fest, ob es über den Proxy lief, blockiert oder direkt gesendet wurde. Diese eine Tabelle ist das Ergebnis und weit nützlicher als ein Screenshot einer Seite, die geladen wurde.

Wenn die Anforderung lautet, dass der gesamte ausgewählte Anwendungsverkehr einen entfernten Tunnel passieren muss, wählen Sie eine Implementierung mit ausdrücklich unterstützter kombinierter Filterung und Tunneling. Eine Zusammensetzung nur mit TCP-Proxy bleibt für engere Aufgaben nützlich, sofern der übrige Verkehr absichtlich behandelt und nicht vergessen wird.