Opdelt tunnel er slået til, og printeren er stadig offline: hvorfor

Din tunnel er oppe, internettet virker, opdelt tunnellering blev aktiveret for måneder siden, og printeren ved skrivebordet vises stadig som offline. Den kombination er ikke en selvmodsigelse, fordi opdelt tunnellering er en rutningsbeslutning snarere end et løfte om tilgængelighed. Tre mekanismer sidder mellem udskriftskøen og papiret, og de fejler på måder, der ser ens ud fra ikonet i proceslinjen. Følg først adressen, derefter ruten, derefter filteret.

Begynd med adressen bag køen

Læs den adresse eller værtsnavn, der er gemt i udskriftskøen, og sammenlign den derefter med den adresse, printeren viser på sin egen netværksskærm. En kø, der stadig peger på en tidligere adresse, opfører sig præcis som en rutningsfejl, og de to er svære at skelne alene ud fra symptomet. Få begge værdier, før du ændrer nogen af dem. En af dem er normalt forældet, og den forældede er normalt køen.

En kø, der er bygget på et værtsnavn, tilføjer navneopløsning til stien, hvilket er en mekanisme adskilt fra rutning. Hvis værtsnavnet opløses anderledes inde i tunnelen, når køen en anden maskine eller når ingenting. En numerisk adresse fjerner den variabel i testens varighed.

Skriv parret ned, fordi resten af undersøgelsen sammenligner dem i stedet for at gætte.

Hvordan ruten for den adresse vælges

Antag, at printeren er på 192.168.1.50, og at kontornetværket også bruger 192.168.1.0/24. Tunnelforbindelsen, der dækker det undernet, kan nu konkurrere med den direkte rute til printeren i din lejlighed, og den mere specifikke post vinder. At ændre porten til den samme numeriske adresse kan ikke fjerne den tvetydighed, fordi tvetydigheden ligger i rutetabellen.

En VPN-profil, der installerer en standardrute, fanger alt, og det lokale linkpræfiks er derefter kun tilgængeligt gennem tunnelen. En opdelt tunnelprofil installerer i stedet de virksomhedspræfikser, hvilket normalt gendanner den lokale sti. Undersøg den rute, der faktisk er valgt for printerens adresse, i stedet for navnet på den indstilling, der frembragte den.

Læs tabellen og den valgte rute sammen, fordi tabellen viser kandidater, og opslaget viser vinderen.

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'

Hvorfor registrering fejler, når adressen virker

Automatisk printerregistrering på et lokalt netværk afhænger af multicast-DNS eller af en ældre broadcast-protokol, og begge er begrænset til et link. En router videresender ikke den multicast som standard, og en VPN er en router. At tilføje en adressebaseret kø retter det tilfælde, hvor registrering er det eneste, der er brudt, og det er præcis derfor, den løsning så ofte forveksles med held.

Forskellen er let at registrere: hvis adressen svarer på udskriftsporten, men printeren aldrig dukker op på listen tilføj printer, er det registreringens rækkevidde, der er skyld i det. Hvis ingen af dem virker, er det ruten eller filteret. To tests, to forskellige ejere og ingen geninstallation af driver imellem.

Test adressen direkte i stedet for at vente på, at en liste udfyldes. Kommandoerne nedenfor gør præcis det.

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

Hvad klientens lokale adgangsfilter tilføjer

Endpoint-klienter kan filtrere lokal trafik uafhængigt af rutetabellen. Indstillingen kaldes ofte lokal netværksadgang, og den kan blokere trafik til det lokale segment, mens tunnelen er tilsluttet, selv når ruteopslaget ser korrekt ud. Det er et politiklag, og ingen mængde ruteændring ændrer det.

På en administreret enhed bør du spørge administratoren, hvad profilen sigter mod, i stedet for selv at skifte kontakten. Filteret findes normalt, fordi nogen besluttede, at en tilsluttet maskine ikke skal kunne nå caféens netværk, og det var en rimelig beslutning.

Læs klientens egen status eller log for den gældende politik, da brugergrænsefladen ofte skjuler den bag en oversigtslinje. Den logpost navngiver normalt den regel, der bestemte.

Kontroller stien med et lille job

Når adressen, ruten og filteret alle peger på printeren, skal du sende et enkelt kort dokument til den samme kø, mens tunnelen forbliver tilsluttet. Det gengiver den oprindelige fejl mere præcist end en driver-geninstallation, der først blev testet efter afbrydelse. Hold jobbet almindeligt, fordi du tester en sti og ikke en enhed.

Gentag derefter med tunnelen afbrudt, så du ved, om den sti, du rettede, var den, der plejede at virke. Den sammenligning er det eneste bevis på, at ændringen betød noget.

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

Hvis jobbet udskrives i begge tilstande, stemmer køen, ruten og filteret overens, og fejlen er væk. Hvis det kun udskrives, når forbindelsen er afbrudt, fanger tunnelen stadig printerens adresse, eller filteret blokerer den stadig, og næste skridt er ruteopslaget i stedet for endnu en driver. Noter, hvilket af de tre lag du ændrede, og den samme sag åbner ikke igen næste måned.