myAudit — Messrequests in Echtzeit prüfen¶

myAudit zeigt Ihnen die Messrequests Ihres eigenen Testgeräts in Echtzeit: welche Requests ankommen, mit welchem Seitencode, und welcher Kategorie dieser Code zugeordnet wird. Damit prüfen Sie eine Einbindung vor dem Go-live, ohne Logdateien auszuwerten.

Prüfbar sind Webseiten und native oder hybride Apps (iOS, Android).

Neu: beide Messverfahren in einem Test. Die consentfreie Zensusmessung (IOMb) und die pseudonyme Messung (IOMp) laufen in derselben Sitzung und derselben Liste — Sie sehen an einem Seitenaufruf, ob beide greifen, und schalten mit dem Filter Type zwischen ihnen um. Bisher deckte myAudit nur die Zensusmessung ab; für die pseudonyme Messung brauchte es ein zweites Werkzeug.

Wie die Markierung funktioniert¶

Markiert wird nicht der einzelne Request, sondern der Weg: Sie leiten die Messaufrufe Ihres Testgeräts über einen Testproxy, den Sie sich im Portal selbst starten. Unsere Messsysteme erkennen ihn an seiner IP-Adresse und ordnen alle Aufrufe, die darüber kommen, Ihrer Sitzung zu — bei beiden Messverfahren auf dieselbe Weise.

Entschlüsselt wird dabei nichts: auf dem DNS-Weg werden TLS-Verbindungen anhand des Hostnamens durchgereicht (SNI-Passthrough, das Zertifikat kommt vom Zielsystem), im Tunnel werden die Pakete unverändert weitergeleitet.

Vorher prüfen¶

• Die Messung muss live sein. Der Testproxy kennt nur Messdomains, für die das Zertifikat bereits ausgestellt und aktiv ist. Eine gerade angelegte Messdomain, deren CNAME noch nicht auflöst, kann myAudit nicht sehen — siehe Einrichtung der Messdomain.
• Ihre Angebotskennung (st) sollten Sie kennen, sonst erkennen Sie Ihre eigenen Zeilen nicht. Was die Parameter bedeuten: Parameter-Referenz.
• IOMp-Requests gibt es nur, wenn die pseudonyme Messung eingebaut ist.
• Ein Gerät, dessen Netzwerkeinstellungen Sie ändern dürfen, und ein Netz, das den nötigen Verkehr durchlässt: für den Tunnel ausgehend UDP 51820, für den DNS-Weg ausgehend Port 53. Auf verwalteten Firmengeräten fehlen dafür oft die Rechte; ein erzwungener Firmen-Resolver oder ein festgelegtes „Privates DNS" unter Android verhindert die Erfassung, ohne einen Fehler zu zeigen.

1. Sitzung starten¶

Im Portal im Bereich MyAudit auf Start MyAudit test klicken. Die Bereitstellung dauert 1–2 Minuten, danach zeigt die Sitzung, wie Sie Ihr Testgerät anschließen.

• Pro Benutzer läuft eine Sitzung gleichzeitig. Läuft noch eine, beenden Sie sie zuerst.
• Zeigt die Sitzung den Status Failed, starten Sie sie erneut. Der Status erscheint erst nach mehreren automatischen Versuchen, das kann einige Minuten dauern. Bleibt es dabei, schicken Sie uns den angezeigten Fehlertext (siehe unten).
• Meldet das Portal, dass gerade alle Testproxys belegt sind, versuchen Sie es in ein paar Minuten erneut.
• Die Sitzung endet automatisch: spätestens nach 3 Stunden — und bereits nach 30 Minuten, in denen kein Request ankommt. Die 30 Minuten laufen ab dem Sitzungsstart und beginnen mit jedem erfassten Request neu; richten Sie Ihr Testgerät also zügig ein. Vorzeitig beenden können Sie jederzeit.

Im Bild sind Adresse, Angebotskennung und QR-Code unkenntlich gemacht — in Ihrer Sitzung stehen dort Ihre eigenen Werte.

2. Testgerät anschließen¶

Die Sitzung führt mit der Karte Connect your device: darin der QR-Code für den VPN-Tunnel, die Schritte und die Schaltfläche Download .conf. Der Tunnel ist der Weg für alles — Webseiten wie Apps, Desktop wie Mobilgerät. Darunter steht zugeklappt Set your device's DNS instead: die DNS-Adresse ist der Fallback für den Fall, dass der Tunnel ausscheidet.

Der Grund für die Empfehlung: der DNS-Weg ist eine Umleitung und setzt voraus, dass das Gerät den Hostnamen überhaupt bei uns erfragt. Bereits zwischengespeicherte Namen, offene Verbindungen und Anwendungen mit eigenem Resolver laufen daran vorbei. Der Tunnel setzt unterhalb der Namensauflösung an, hat dieses Problem nicht und erfasst zusätzlich HTTP/3.

Empfohlen: VPN-Tunnel¶

In der Sitzung steht der QR-Code direkt in der Karte Connect your device; darunter finden Sie für Desktop-Rechner die Schaltfläche Download .conf. Sie müssen nichts anfragen.

Durch den Tunnel wird nur der Verkehr zu unseren Messendpunkten geleitet, der übrige Verkehr des Geräts geht direkt hinaus.

1. Kostenfreie App WireGuard installieren (Android, iOS, Windows, macOS).
2. In WireGuard + bzw. Tunnel hinzufügen antippen und Von QR-Code scannen wählen.
3. Den QR-Code aus der Sitzung scannen, einen Namen vergeben (frei wählbar, z. B. myAudit-Test) und den Tunnel erstellen. Auf dem Desktop importieren Sie stattdessen die Datei aus Download .conf.
4. Tunnel einschalten und die Verbindung prüfen: Tunnel antippen, unter Transfer steigen die Zähler, und es gibt einen erfolgreichen letzten Handshake. Bleibt der Handshake aus, blockiert Ihr Netz vermutlich den ausgehenden UDP-Port 51820 — dann testen Sie aus einem anderen Netz, etwa über den Mobilfunk des Testgeräts.

Die Screenshots zeigen Android; unter iOS heißen die Schritte gleich. Nach einem Neustart des Geräts ist der Tunnel in der Regel aus — prüfen Sie den Handshake erneut, bevor Sie von einem Messproblem ausgehen.

Fallback: DNS-Adresse¶

Für den Fall, dass der Tunnel ausscheidet — und nicht für Android (siehe oben). Klappen Sie in der Sitzung Set your device's DNS instead auf: darin steht eine DNS-Server-Adresse (IPv4, mit Kopier-Schaltfläche), unter How to set your DNS on each platform zusätzlich der Weg je Plattform. Diese Adresse tragen Sie auf dem Testgerät als DNS-Server ein und ersetzen dabei alle vorhandenen Einträge — ein zweiter, eigener DNS-Server daneben führt dazu, dass ein Teil der Aufrufe am Proxy vorbeigeht und die Liste leer bleibt, obwohl alles richtig eingerichtet aussieht.

Für Webseiten erfasst dieser Weg nur, wenn Sie im Browser das verschlüsselte DNS (DoH) abschalten — sonst fragt der Browser seinen eigenen Resolver, der Testproxy sieht die Aufrufe nicht, und die Seite lädt trotzdem normal. Verlässlich ist der DNS-Weg für Apps, die den System-Resolver benutzen.

Eines kann nur dieser Weg: einen Messhostnamen prüfen, bevor das öffentliche DNS auf die neue Messinfrastruktur zeigt. Dafür bleibt er erhalten.

Lassen Sie das zweite DNS-Feld leer, schalten Sie verschlüsseltes DNS (DoH bzw. „Secure DNS" in Chrome und Firefox, iCloud Private Relay) für die Testdauer aus, und starten Sie den Browser neu, bevor Sie die Testseite aufrufen — sonst nutzt er einen zwischengespeicherten Namen und fragt den Proxy nie.

3. Requests prüfen¶

Rufen Sie die zu testende Seite auf bzw. benutzen Sie Ihre App. Die Requests erscheinen in der Regel innerhalb von Sekunden in der Liste.

Die Filterleiste hat die Felder Site, Time (1 h, 6 h, 24 h, 7 d) und Type (IOMB, IOMP, All) — angewendet werden sie mit Apply. Angezeigt werden die Requests Ihrer eigenen Sitzung. In der Tabelle steht Ihre Angebotskennung (st) in der Spalte Site, der Seitencode (cp) in Code und die daraus abgeleitete Zuordnung in Category.

Darauf schauen Sie:

• Kommt pro Seitenaufruf ein Zensus-Request an?
• Steht in Code Ihr Seitencode — und nicht Leercode_nichtzuordnungsfaehig? Dieser Wert bedeutet, dass kein Code übergeben wurde: gemessen wird, zuordenbar ist nichts.
• Passt die Kategorie in Category zu dem, was der Code bedeuten soll? Ein „—" heißt: dieser Code ist noch nicht zugeordnet.
• Stimmt die Domain in Domain? Hier fällt auf, wenn Aufrufe unter einem fremden Host ankommen, etwa über einen AMP-Cache oder Proxy.
• Erscheinen IOMp-Requests nach der Einwilligung? In der Regel erscheinen sie erst dann; vorher nur IOMB zu sehen, ist korrekt.

Der User-Agent wird in der IOMb-Detailansicht bewusst nicht angezeigt.

Requests werden 7 Tage aufbewahrt und danach automatisch gelöscht. Das betrifft die myAudit-Ansicht, nicht Ihre Messdaten.

4. Test beenden¶

Erst das Gerät, dann die Sitzung:

1. Den Tunnel ausschalten bzw. den DNS-Server des Geräts zurück auf automatisch stellen.
2. Die Sitzung im Portal beenden.

Andersherum steht Ihr Gerät ohne funktionierende Namensauflösung da — die Adresse des Proxys wird beim Beenden freigegeben und kann später anderweitig vergeben werden.

Das gilt auch für das Ende von selbst: die Sitzung endet ohne Benachrichtigung — nach 3 Stunden, oder schon nach 30 Minuten ohne eingehenden Request. Den DNS-Weg trifft gerade Letzteres leicht: kommt nichts an, ist die Sitzung nach einer halben Stunde weg. Wenn danach auf dem Gerät noch die DNS-Adresse steht, funktioniert dort gar keine Namensauflösung mehr — es sieht aus, als wäre das Internet defekt. Das ist das Erste, was Sie prüfen, wenn ein Testgerät plötzlich nichts mehr erreicht.

Hinweise¶