Delad tunnel är på och skrivaren är fortfarande offline: varför

Din tunnel är uppe, internet fungerar, delad tunnling aktiverades för månader sedan, och skrivaren vid skrivbordet visas fortfarande som offline. Den kombinationen är ingen motsägelse, eftersom delad tunnling är ett routingbeslut och inte ett löfte om nåbarhet. Tre mekanismer sitter mellan utskriftskön och papperet, och de misslyckas på sätt som ser identiska ut från ikonen i aktivitetsfältet. Följ adressen först, sedan rutten, sedan filtret.

Börja med adressen bakom kön

Läs adressen eller värdnamnet som är sparat i utskriftskön och jämför det sedan med adressen som skrivaren visar på sin egen nätverksskärm. En kö som fortfarande pekar på en tidigare adress beter sig precis som ett routingfel, och de två är svåra att skilja enbart utifrån symtomet. Hämta båda värdena innan du ändrar något av dem. En av dem är vanligtvis inaktuell, och den inaktuella är vanligtvis kön.

En kö som bygger på ett värdnamn lägger till namnmatchning på vägen, en mekanism som är skild från routing. Om värdnamnet matchas annorlunda inne i tunneln når kön en annan maskin eller ingenting. En numerisk adress tar bort den variabeln under testets varaktighet.

Skriv ner paret, eftersom resten av undersökningen jämför dem i stället för att gissa.

Hur rutten för den adressen väljs

Anta att skrivaren är på 192.168.1.50 och att kontorsnätet också använder 192.168.1.0/24. Tunnelrutten som täcker det subnätet kan nu konkurrera med den direkta rutten till skrivaren i din lägenhet, och den mer specifika posten vinner. Att ändra porten till samma numeriska adress kan inte ta bort den tvetydigheten, eftersom tvetydigheten ligger i routingtabellen.

En VPN-profil som installerar en standardrutt fångar allt, och det lokala länkprefixet är då bara nåbart genom tunneln. En delad tunnelprofil installerar i stället företagets prefix, vilket vanligtvis återställer den lokala vägen. Granska rutten som faktiskt valdes för skrivarens adress, inte namnet på inställningen som skapade den.

Läs tabellen och den valda rutten tillsammans, eftersom tabellen visar kandidaterna och sökningen vinnaren.

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'

Varför upptäckt misslyckas när adressen fungerar

Automatisk skrivarupptäckt på ett lokalt nätverk beror på multicast-DNS eller ett äldre broadcastprotokoll, och båda är begränsade till en länk. En router vidarebefordrar inte den multicast-trafiken som standard, och en VPN är en router. Att lägga till en adressbaserad kö åtgärdar fallet där upptäckt är det enda som är trasigt, och det är just därför den lösningen så ofta misstas för tur.

Skillnaden är lätt att registrera: om adressen svarar på utskriftsporten men skrivaren aldrig dyker upp i listan för att lägga till skrivare, är det upptäcktsomfånget som är boven. Om ingen av dem fungerar är det rutten eller filtret. Två tester, två olika ansvariga och ingen ominstallation av drivrutin emellan.

Testa adressen direkt i stället för att vänta på att en lista fylls. Kommandona nedan gör precis det.

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

Vad klientens lokala åtkomstfilter tillför

Slutpunktsklienter kan filtrera lokal trafik oberoende av routingtabellen. Inställningen kallas ofta lokal nätverksåtkomst, och den kan blockera trafik till det lokala segmentet medan tunneln är ansluten, även när rutsökningen ser korrekt ut. Det är ett policylager, och ingen ruttredigering ändrar det.

På en hanterad enhet bör du fråga administratören vad profilen avser i stället för att själv vända på reglaget. Filtret finns vanligtvis eftersom någon beslutade att en ansluten maskin inte borde kunna nå kafénätet, och det var ett rimligt beslut.

Läs klientens egen status eller logg för den gällande policyn, eftersom gränssnittet ofta döljer den bakom en sammanfattningsrad. Den loggposten namnger vanligtvis regeln som beslutade.

Kontrollera vägen med ett litet jobb

När adressen, rutten och filtret alla pekar på skrivaren, skicka ett enda kort dokument till samma kö medan tunneln förblir ansluten. Det återskapar det ursprungliga felet mer exakt än en drivrutinsominstallation som bara testades efter frånkoppling. Håll jobbet alldagligt, eftersom du testar en väg och inte en enhet.

Upprepa sedan med tunneln frånkopplad, så att du vet om vägen du reparerade var den som brukade fungera. Den jämförelsen är det enda beviset på att ändringen betydde något.

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

Om jobbet skrivs ut i båda tillstånden stämmer kön, rutten och filtret, och felet är borta. Om det bara skrivs ut när det är frånkopplat fångar tunneln fortfarande skrivarens adress, eller så blockerar filtret den fortfarande, och nästa steg är rutsökningen i stället för ännu en drivrutin. Anteckna vilket av de tre lagren du ändrade, och samma ärende öppnas inte igen nästa månad.