Geteilter Tunnel ist aktiv, und der Drucker ist weiterhin offline: warum
Geteiltes Tunneling entscheidet über Routen, nicht über Erreichbarkeit. Verfolgen Sie die Adresse der Druckwarteschlange, die Route und den lokalen Filter des Clients, bevor Sie Treiber neu installieren.
Ihr Tunnel steht, das Internet funktioniert, geteiltes Tunneling wurde vor Monaten aktiviert, und der Drucker neben dem Schreibtisch wird weiterhin als offline angezeigt. Diese Kombination ist kein Widerspruch, denn geteiltes Tunneling ist eine Routing-Entscheidung und kein Versprechen von Erreichbarkeit. Zwischen der Druckwarteschlange und dem Papier liegen drei Mechanismen, und sie versagen auf Arten, die vom Symbol im Infobereich identisch aussehen. Verfolgen Sie zuerst die Adresse, dann die Route, dann den Filter.
Beginnen Sie mit der Adresse hinter der Warteschlange
Lesen Sie die in der Druckwarteschlange gespeicherte Adresse oder den Hostnamen und vergleichen Sie sie mit der Adresse, die der Drucker auf seinem eigenen Netzwerkbildschirm anzeigt. Eine Warteschlange, die noch auf eine frühere Adresse zeigt, verhält sich genau wie ein Routing-Fehler, und beide lassen sich allein am Symptom kaum unterscheiden. Nehmen Sie beide Werte auf, bevor Sie einen davon ändern. Einer davon ist meist veraltet, und der veraltete ist meist die Warteschlange.
Eine Warteschlange, die auf einem Hostnamen aufbaut, fügt der Strecke die Namensauflösung hinzu, ein vom Routing getrennter Mechanismus. Löst der Hostname innerhalb des Tunnels anders auf, erreicht die Warteschlange eine andere Maschine oder gar nichts. Eine numerische Adresse beseitigt diese Variable für die Dauer des Tests.
Notieren Sie das Paar, denn der Rest der Untersuchung vergleicht es, statt zu raten.
Wie die Route für diese Adresse gewählt wird
Angenommen, der Drucker steht auf 192.168.1.50 und das Büronetzwerk nutzt ebenfalls 192.168.1.0/24. Die Tunnelroute, die dieses Subnetz abdeckt, kann nun mit der direkten Route zum Drucker in Ihrer Wohnung konkurrieren, und der spezifischere Eintrag gewinnt. Den Port auf dieselbe numerische Adresse zu ändern, beseitigt diese Mehrdeutigkeit nicht, denn die Mehrdeutigkeit steckt in der Routing-Tabelle.
Ein VPN-Profil, das eine Standardroute installiert, erfasst alles, und das lokale Linkpräfix ist dann nur noch über den Tunnel erreichbar. Ein Split-Tunnel-Profil installiert stattdessen die Unternehmenspräfixe, was den lokalen Pfad meist wiederherstellt. Prüfen Sie die tatsächlich für die Adresse des Druckers gewählte Route und nicht den Namen der Einstellung, die sie erzeugt hat.
Lesen Sie die Tabelle und die gewählte Route zusammen, denn die Tabelle zeigt Kandidaten und die Suche den Gewinner.
Get-Printer | Select-Object Name, PortName, DriverName
Get-PrinterPort -Name 'IP_192.168.1.50' | Select-Object PrinterHostAddress
route print -4 | Select-String '192.168.1'Warum die Erkennung fehlschlägt, wenn die Adresse funktioniert
Die automatische Druckererkennung in einem lokalen Netzwerk hängt von Multicast-DNS oder einem älteren Broadcast-Protokoll ab, und beide sind auf eine Verbindung beschränkt. Ein Router leitet diesen Multicast standardmäßig nicht weiter, und ein VPN ist ein Router. Das Hinzufügen einer adressbasierten Warteschlange behebt den Fall, in dem die Erkennung das Einzige ist, was kaputt ist, und genau deshalb wird dieser Workaround so oft für Glück gehalten.
Der Unterschied lässt sich leicht festhalten: Antwortet die Adresse auf dem Druckport, aber der Drucker erscheint nie in der Liste zum Hinzufügen von Druckern, liegt der Fehler im Erkennungsbereich. Funktioniert keines von beiden, liegt es an der Route oder am Filter. Zwei Tests, zwei verschiedene Zuständige und dazwischen keine Treiberneuinstallation.
Testen Sie die Adresse direkt, statt zu warten, dass sich eine Liste füllt. Die folgenden Befehle tun genau das.
Test-NetConnection 192.168.1.50 -Port 9100
nslookup 192.168.1.50
ping -c 2 192.168.1.50Was der lokale Zugriffsfilter des Clients hinzufügt
Endpoint-Clients können lokalen Datenverkehr unabhängig von der Routing-Tabelle filtern. Die Einstellung heißt oft lokaler Netzwerkzugriff, und sie kann Datenverkehr zum lokalen Segment blockieren, solange der Tunnel verbunden ist, selbst wenn die Routensuche korrekt aussieht. Das ist eine Richtlinienebene, und keine Routenbearbeitung ändert daran etwas.
Fragen Sie auf einem verwalteten Gerät den Administrator, was das Profil bezweckt, statt den Schalter selbst umzulegen. Der Filter existiert meist, weil jemand entschieden hat, dass eine verbundene Maschine das Netzwerk des Cafés nicht erreichen können soll, und das war eine vernünftige Entscheidung.
Lesen Sie den eigenen Status oder das Protokoll des Clients für die geltende Richtlinie, da die Benutzeroberfläche sie oft hinter einer Zusammenfassungszeile verbirgt. Dieser Protokolleintrag nennt meist die Regel, die entschieden hat.
Prüfen Sie den Pfad mit einem kleinen Auftrag
Sobald Adresse, Route und Filter alle auf den Drucker zeigen, senden Sie ein einzelnes kurzes Dokument an dieselbe Warteschlange, während der Tunnel verbunden bleibt. Das reproduziert den ursprünglichen Fehler genauer als eine Treiberneuinstallation, die erst nach dem Trennen getestet wurde. Halten Sie den Auftrag unspektakulär, denn Sie testen einen Pfad und kein Gerät.
Wiederholen Sie es dann mit getrenntem Tunnel, damit Sie wissen, ob der reparierte Pfad der war, der früher funktionierte. Dieser Vergleich ist der einzige Beweis, dass die Änderung etwas bewirkt hat.
Test-NetConnection 192.168.1.50 -Port 9100
Get-PrintJob -PrinterName 'Front Desk'
Get-NetRoute -DestinationPrefix 192.168.1.0/24Wird der Auftrag in beiden Zuständen gedruckt, stimmen Warteschlange, Route und Filter überein, und der Fehler ist weg. Wird er nur bei getrennter Verbindung gedruckt, erfasst der Tunnel noch die Adresse des Druckers, oder der Filter blockiert ihn noch, und der nächste Schritt ist die Routensuche statt eines weiteren Treibers. Notieren Sie, welche der drei Schichten Sie geändert haben, und dasselbe Ticket öffnet sich nächsten Monat nicht erneut.