Nødstoppen blokkerer skriveren? Tre sjekker du bør gjøre først

Skriveren din fungerte for en time siden. Så slo du på VPN-en, og nå står jobbene i køen til de feiler. Den sannsynlige årsaken er ikke skriveren, men nødstoppen: den slipper trafikk som ville forlate maskinen utenfor tunnelen, og en LAN-skriver er nettopp slik trafikk. Det egentlige valget er ikke hvordan du fikser utskrift, men om denne enheten i det hele tatt skal nå det lokale nettverket. Tre vilkår avgjør det, og hvilket som helst av dem kan avslutte diskusjonen tidlig.

Hva nødstoppen slipper og hvorfor

En nødstopp er en rutingregel med en feilmodus festet til seg. Når tunnelen er oppe, forlater samsvarende pakker maskinen kryptert; når tunnelen faller, svartelister klienten standardruten slik at ingenting går ut i klartekst. En skriver på samme subnett samsvarer aldri med tunnelruten, så den behandles som et fluktforsøk selv om trafikken aldri forlater bygningen.

Oppdagelsen gjør symptomet forvirrende. Skrivere annonserer over multicast-DNS på port 5353, og køen som vises i dialogboksen for å legge til skriver, bygges fra disse annonsene. Mens blokkeringen er aktiv, kan annonsen utebli, så skriveren forsvinner fra listen selv om adressen fortsatt svarer. IPP på 631, rå utskrift på 9100 og SMB på 445 er vanlige LAN-tjenester helt uten tunnelvei.

Bevis først at skriveren er tilgjengelig

Før du endrer noen policy, bekreft at skriveren er frisk og bekreft adressen du tror den har. Les adressen fra skriverpanelet eller dens egen nettside. En utdatert oppføring i operativsystemets liste kan peke på en adresse som DHCP ga en annen enhet for uker siden.

Koble fra VPN-en, og test deretter adressen og de to vanlige utskriftsportene:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

På Windows er ekvivalenten Test-NetConnection 192.168.1.50 -Port 9100. Koble til VPN-en igjen og gjenta. Svarer portene med VPN-en av og timer ut med den på, har du gjenskapt blokkeringen, og resten er et policy-spørsmål. Feiler de i begge tilstander, stopp: skriveren, Wi-Fi-segmentet eller klientisolering er årsaken, og et VPN-unntak ville bare øke eksponeringen.

Tre vilkår som avgjør tillat eller blokker

Kjør dem i rekkefølge. Det første vilkåret som feiler avgjør utfallet, så de senere trenger ikke testes.

Gjestenettverk er det klareste nei. På et hotellsegment er det lokale området alle andre gjester, så et unntak som når skriveren din, når også deres bærbare maskiner. En skriver du ikke eier er ikke grunn til å åpne det segmentet.

Administrerte enheter er det andre nei. Når en administratorprofil håndhever alltid-på VPN med låsning, gjenoppretter klienten blokkeringen etter enhver lokal endring, og omveien kan bryte policyen du godtok. Be om en støttet vei for lokale ressurser i stedet for å redigere innstillinger som vil bli overskrevet.

Det minste unntaket klienten din støtter

Det du vil ha er en destinasjonsbegrenset regel for én skriveradresse, ikke en generell «tillat lokalt»-bryter. En generell bryter dekker gjerne hele det private området og link-lokal trafikk, som er langt mer enn én utskriftskø trenger, og den gjør hver enhet på segmentet til en likemann du har godtatt.

Windows tilbyr delt tunnellering, og noen bygg tilbyr også et lokalnettvalg. Der den eneste støttede veien er en vertsoppføring, legg til én adresse gjennom den fysiske gatewayen etter at tunnelen er oppe, for eksempel route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, og slett den når økten er over. WireGuard virker annerledes: AllowedIPs bestemmer hva som kommer inn i tunnelen, så en full-tunnel-profil med 0.0.0.0/0 bærer utskriftsjobben til endepunktet med mindre en mer spesifikk rute går utenom, og wg-quick kan installere brannmurregler som blokkerer alt annet.

På Android er den alltid-på-innstillingen som blokkerer tilkoblinger uten VPN-en, nødstoppen, og skriveroppdagelse fra en app inne i den blokkeringen har ingen LAN-vei. Modellen med per-app og unntak er dokumentert på Android VPN-siden, som er stedet å sjekke før du endrer noe:Veiledning for Android VPN-tilkobling. Nyere macOS-versjoner ber om lokalnett-tillatelse separat fra tunnelen, og iOS gjør det samme for lokalnettilgang, men køen kan fortsatt feile med tunnelen oppe fordi leverandørens klient ruter subnettet inn i den.

Uansett hvilken klient du bruker, hold unntaket til én adresse og de to eller tre portene skriveren faktisk bruker. Reserver en DHCP-lease i stedet for å utvide regelen til hele subnettet, fordi adressen kan flytte på seg.

Verifiser unntaket og vit når du skal angre det

Etter endringen, koble til igjen og sjekk tre ting i rekkefølge. Skriveren svarer på portene sine, en ufarlig testside skrives ut, og et adresseoppslag returnerer fortsatt VPN-endepunktet i stedet for ISP-en din. Hvis utskrift virker men oppslaget viser ISP-en din, åpnet du mer enn skriveren og bør tilbakestille.

Gjenta testen etter en omstart og etter enhver klient- eller profiloppdatering, siden oppdateringer gjenoppretter standardinnstillinger ofte nok til å bety noe. Et unntak som bare varer til neste tilkobling er ikke en beslutning, det er et midlertidig hull. Skriv ned den nøyaktige regelen så du kan fjerne den med vilje.

Hvis enheten er ment å være tunnel-only, en reiselaptop eller en maskin som holder klientdata, er det riktige svaret å beholde blokkeringen og skrive ut et annet sted: lagre som PDF og skriv ut fra en telefon eller en annen maskin, eller nå en utskriftsserver tunnelen kan rute til. Å slå av nødstoppen for én jobb bytter en reell beskyttelse mot litt bekvemmelighet.