Split tunneling staat aan en de printer is nog steeds offline: waarom

Je tunnel staat aan, het internet werkt, split tunneling is maanden geleden ingeschakeld, en de printer naast het bureau wordt nog steeds als offline weergegeven. Die combinatie is geen tegenspraak, want split tunneling is een routeringsbeslissing en geen belofte van bereikbaarheid. Tussen de afdrukwachtrij en het papier zitten drie mechanismen, en ze falen op manieren die er vanaf het pictogram in het systeemvak identiek uitzien. Volg eerst het adres, dan de route, dan het filter.

Begin met het adres achter de wachtrij

Lees het adres of de hostnaam die in de afdrukwachtrij is opgeslagen en vergelijk die met het adres dat de printer op zijn eigen netwerkscherm toont. Een wachtrij die nog naar een eerder adres wijst, gedraagt zich precies als een routeringsfout, en die twee zijn alleen aan het symptoom moeilijk te onderscheiden. Haal beide waarden op voordat je een van beide wijzigt. Een van de twee is meestal verouderd, en de verouderde is meestal de wachtrij.

Een wachtrij die op een hostnaam is gebouwd, voegt naamresolutie aan het pad toe, een mechanisme dat losstaat van routering. Als de hostnaam binnen de tunnel anders wordt omgezet, bereikt de wachtrij een andere machine of niets. Een numeriek adres haalt die variabele voor de duur van de test weg.

Schrijf het paar op, want de rest van het onderzoek vergelijkt ze in plaats van te gissen.

Hoe de route voor dat adres wordt gekozen

Stel dat de printer op 192.168.1.50 staat en dat het kantoornetwerk ook 192.168.1.0/24 gebruikt. De tunnelroute die dat subnet dekt, kan nu concurreren met de directe route naar de printer in je appartement, en de specifiekere vermelding wint. De poort naar hetzelfde numerieke adres wijzigen kan die dubbelzinnigheid niet wegnemen, want de dubbelzinnigheid zit in de routeringstabel.

Een VPN-profiel dat een standaardroute installeert, vangt alles, en het lokale linkprefix is dan alleen via de tunnel bereikbaar. Een split-tunnelprofiel installeert in plaats daarvan de bedrijfsprefixen, wat meestal het lokale pad herstelt. Onderzoek de route die daadwerkelijk voor het adres van de printer is gekozen, niet de naam van de instelling die hem heeft gemaakt.

Lees de tabel en de gekozen route samen, want de tabel toont kandidaten en de opzoeking de winnaar.

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'

Waarom detectie faalt wanneer het adres werkt

Automatische printerdetectie op een lokaal netwerk is afhankelijk van multicast-DNS of van een ouder broadcastprotocol, en beide zijn beperkt tot één verbinding. Een router stuurt die multicast niet standaard door, en een VPN is een router. Een op adressen gebaseerde wachtrij toevoegen lost het geval op waarin detectie het enige is dat kapot is, en daarom wordt die omweg zo vaak voor geluk aangezien.

Het verschil is gemakkelijk vast te leggen: als het adres op de afdrukpoort antwoordt maar de printer nooit in de lijst voor printer toevoegen verschijnt, is het detectiebereik de schuldige. Als geen van beide werkt, is het de route of het filter. Twee tests, twee verschillende verantwoordelijken en geen herinstallatie van stuurprogramma’s ertussen.

Test het adres rechtstreeks in plaats van te wachten tot een lijst zich vult. De onderstaande opdrachten doen precies dat.

Test-NetConnection 192.168.1.50 -Port 9100
nslookup 192.168.1.50
ping -c 2 192.168.1.50

Wat het lokale toegangsfilter van de client toevoegt

Eindpuntclients kunnen lokaal verkeer filteren onafhankelijk van de routeringstabel. De instelling heet vaak lokale netwerktoegang, en kan verkeer naar het lokale segment blokkeren terwijl de tunnel is verbonden, zelfs wanneer de routeopzoeking correct lijkt. Dat is een beleidslaag, en geen enkele routebewerking verandert daar iets aan.

Vraag op een beheerd apparaat de beheerder wat het profiel beoogt in plaats van zelf de schakelaar om te zetten. Het filter bestaat meestal omdat iemand heeft besloten dat een verbonden machine het netwerk van het café niet zou moeten kunnen bereiken, en dat was een redelijke beslissing.

Lees de eigen status of het logboek van de client voor het geldende beleid, want de interface verbergt het vaak achter een samenvattingsregel. Die logboekregel noemt meestal de regel die heeft besloten.

Controleer het pad met één kleine taak

Zodra het adres, de route en het filter allemaal naar de printer wijzen, stuur je één kort document naar dezelfde wachtrij terwijl de tunnel verbonden blijft. Dat reproduceert de oorspronkelijke storing nauwkeuriger dan een herinstallatie van het stuurprogramma die pas na het verbreken is getest. Houd de taak onopvallend, want je test een pad en geen apparaat.

Herhaal het daarna met de tunnel verbroken, zodat je weet of het pad dat je hebt gerepareerd het pad was dat eerder werkte. Die vergelijking is het enige bewijs dat de wijziging iets uitmaakte.

Test-NetConnection 192.168.1.50 -Port 9100
Get-PrintJob -PrinterName 'Front Desk'
Get-NetRoute -DestinationPrefix 192.168.1.0/24

Als de taak in beide toestanden wordt afgedrukt, stemmen de wachtrij, de route en het filter overeen en is de storing weg. Als hij alleen wordt afgedrukt wanneer de verbinding is verbroken, vangt de tunnel nog steeds het adres van de printer of blokkeert het filter het nog, en de volgende stap is de routeopzoeking en niet een ander stuurprogramma. Noteer welke van de drie lagen je hebt gewijzigd, en dezelfde melding gaat volgende maand niet opnieuw open.