Android-App verweigert Betrieb über VPN: Welche Schicht entscheidet

Wenn eine Android-App in dem Moment nicht mehr funktioniert, in dem der Tunnel hochkommt, können drei verschiedene Dinge verantwortlich sein, und sie erzeugen ähnlich aussehende Fehler. Die App kann den eigenen Netzwerkzustand des Telefons lesen und lokal ablehnen. Der Server kann die Adresse, von der Sie kommen, klassifizieren und sie zurückweisen. Oder die Ablehnung hat überhaupt nichts mit dem VPN zu tun. Die Reihenfolge unten sammelt Belege, bevor sie etwas ändert, denn den Ausgang zu wechseln ist der teuerste Schritt und derjenige, der am wenigsten hilft, wenn die Prüfung lokal abläuft.

Schritt 1: herausfinden, wann die App ablehnt

Der Zeitpunkt ist das erste Unterscheidungsmerkmal. Leeren Sie den Logpuffer, reproduzieren Sie den Fehler und schauen Sie, was die App getan hat, bevor sie sich beschwert hat:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Lehnt die App ab, bevor überhaupt eine ausgehende Anfrage versucht wird, sehen Sie eine lokale Entscheidung. Verbindet sie sich, sendet etwas und zeigt dann einen Fehler, kam die Ablehnung von der anderen Seite. Scheitert die App bei abgeschaltetem Tunnel genauso, war das VPN nie die Variable.

Behandeln Sie diesen Zeitpunkt als Beleg und nicht als Beweis. Eine App kann eine zwischengespeicherte Antwort erneut abspielen, und Hintergrundanfragen können erfolgreich gewesen sein oder fehlgeschlagen sein, bevor Sie nachgesehen haben. Notieren Sie die Zeitstempel der letzten erfolgreichen Anfrage und des Fehlers, nicht nur den Moment, in dem die Meldung erschien.

Schritt 2: die Sicht des Telefons auf das Netzwerk lesen

Android stellt den VPN-Zustand als Netzwerkfähigkeit bereit, sodass eine App keine Liste kommerzieller Anbieter braucht, um zu bemerken, dass ein Tunnel aktiv ist. Sie fragt den Konnektivitätsdienst, welches das aktuelle Netzwerk ist, und die Antwort enthält ein VPN-Transportbit:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Diese Prüfung ist lokal und billig, und sie erklärt eine ganze Klasse von Berichten der Art »diese App funktioniert nicht über VPN« ohne jede Fernklassifizierung. Was die App sehen kann, hängt weiterhin von ihrem eigenen Netzwerkkontext ab, also nehmen Sie nicht an, dass jede App jedes Profil auf dem Gerät inspiziert.

Von einer Workstation aus sehen Sie denselben Zustand auf einem Testgerät mit adb shell dumpsys connectivity und indem Sie nach dem VPN-Netzwerkeintrag suchen. Vergleichen Sie einen Lauf mit hochgefahrenem Tunnel mit einem Lauf bei abgeschaltetem Tunnel, und bewahren Sie beide Ausgaben auf.

Schritt 3: lesen, was der Server tatsächlich sieht

Der andere Beobachter ist der Dienst. Er sieht die Quelladresse, die ankommt, und kann auf die Adresse, das dahinterliegende Hostingnetz, die Region, den Netzbetreiber oder Signale reagieren, die an Konto und Gerät gebunden sind. Nichts davon ist eine eindeutige Identität, und gemeinsam genutzte Adressierung macht Kollateralsperren normal: eine eingeschränkte Adresse kann unbeteiligte Nutzer hinter derselben Übersetzung mit ausschalten.

Holen Sie die Adresse über denselben Weg, den die App nutzt, nicht aus einem Browser auf einem Laptop. Auf dem Telefon zeigt eine schlichte Anfrage an einen Adress-Echo-Dienst, was die Gegenseite empfängt, und der Vergleich mit einer Anfrage über das Mobilfunknetz sagt Ihnen, ob sich die Adresse überhaupt geändert hat.

Funktioniert die App über Mobilfunk und scheitert über den Tunnel mit demselben Konto, liegt die Ablehnung am fernen Ende oder in der eigenen Richtlinie der App. Scheitert sie bei beidem, ist das VPN nicht der Unterschied, und Sie sollten aufhören, Endpunkte zu testen.

Schritt 4: die Belege einem von drei Urteilen zuordnen

Drei Kombinationen decken fast jeden Bericht ab. Eine Ablehnung ohne ausgehenden Versuch bei aktivem Tunnel deutet auf eine lokale Transportprüfung. Eine Anfrage, die hinausgeht und mit einem Fehler, einer Zeitüberschreitung bei einem bestimmten Host oder einer Regionsmeldung zurückkommt, deutet auf die ferne Seite. Ein Fehler, der über Mobilfunk ohne Tunnel reproduzierbar ist, deutet auf das Konto, die App-Version oder die eigene Richtlinie des Dienstes, und keine VPN-Änderung wird ihn bewegen.

Schreiben Sie das Urteil zusammen mit dem Beleg auf, der es erzeugt hat. Der Wert dieses Schritts liegt darin, dass er die Schleife beendet, in der jemand viermal Ausgangsknoten wechselt, um eine Prüfung zu beheben, die auf dem Handgerät läuft.

Er hält auch die Aussagen ehrlich. Selbsthosting ändert den Endpunkt und dessen Internetausgang; es bringt Android nicht dazu, ein aktives VPN-Netz zu vergessen, und es garantiert keine Akzeptanz durch einen Dienst, der Adressen klassifiziert. Ein lokaler Filter kann auf einem eigenen VPN-Netz genauso leicht auslösen wie auf einem kommerziellen.

Schritt 5: den unterstützten Weg gehen und ihn prüfen

Beginnen Sie mit der dokumentierten Richtlinie des Produkts und seinem Supportverantwortlichen. Senden Sie die Clientversion, die genaue Meldung und ein enges Fehlerfenster; schicken Sie keine vollständigen Verkehrsmitschnitte oder Zugangsdaten, nur um zu belegen, dass ein Fehler existiert.

Erlaubt der Dienst direkten Zugang und lässt die Geräterichtlinie es zu, ist der Ausschluss pro App der unterstützte Mechanismus, und er nimmt diese App bewusst aus dem Tunnel, statt den Tunnel zu verbergen. Der Verkehr der App verlässt dann seinen eigenen Weg, was eine Richtlinienentscheidung ist, die jemand verantworten muss. In einer Konfiguration, die ohne VPN blockiert, kann eine ausgeschlossene App schlicht die Verbindung verlieren, also testen Sie diese Kombination, bevor Sie versprechen, dass sie funktioniert.

Wiederholen Sie nach jeder Änderung den Zeitpunkt-Test aus Schritt eins, bestätigen Sie, dass die App funktioniert, und bestätigen Sie, dass jede andere App weiterhin den Tunnel nutzt. Stellen Sie dann die vorherige Konfiguration wieder her und prüfen Sie, ob der Fehler zurückkommt, denn eine Korrektur, die Sie nicht reproduzieren können, ist ein Zufall, dem Sie wieder begegnen.