Kill switch blokerer din printer? Tre kontroller, du bør køre først

Din printer virkede for en time siden. Så slog du VPN til, og nu står jobene i køen, indtil de fejler. Kill switchen er den sandsynlige årsag, ikke printeren: den dropper trafik, der ville forlade maskinen uden for tunnelen, og en LAN-printer er netop den slags trafik. Den egentlige beslutning er ikke, hvordan udskrivning skal repareres, men om denne enhed overhovedet bør nå det lokale netværk. Tre betingelser afgør det, og enhver af dem kan afslutte diskussionen tidligt.

Hvad kill switchen dropper, og hvorfor

En kill switch er en routingregel med en fejltilstand knyttet til sig. Når tunnelen er oppe, forlader matchende pakker krypteret; når tunnelen falder, blackholer klienten standardruten, så intet går ud i klartekst. En printer på samme subnet matcher aldrig tunnelruten, så den behandles som et flugtforsøg, selv om trafikken aldrig forlader bygningen.

Opdagelse gør symptomet forvirrende. Printere annoncerer via multicast DNS på port 5353, og køen i dialogboksen tilføj printer bygges ud fra disse annoncer. Mens blokeringen er aktiv, kommer annoncen måske ikke frem, så printeren forsvinder fra listen, selv om dens adresse stadig svarer. IPP på 631, rå udskrivning på 9100 og SMB på 445 er almindelige LAN-tjenester helt uden tunnelrute.

Bevis først, at printeren er tilgængelig

Før du ændrer nogen politik, skal du bekræfte, at printeren er sund, og bekræfte den adresse, du tror, den har. Læs adressen på printerpanelet eller dens egen webside. En forældet post på operativsystemets liste kan pege på en adresse, som DHCP gav en anden enhed for uger siden.

Afbryd VPN, og test derefter adressen og de to almindelige printporte:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

På Windows er ækvivalenten Test-NetConnection 192.168.1.50 -Port 9100. Tilslut VPN igen, og gentag. Hvis portene svarer med VPN slået fra og får timeout med den slået til, har du reproduceret blokeringen, og resten er et politisk spørgsmål. Hvis de fejler i begge tilstande, så stop: printeren, Wi-Fi-segmentet eller klientisolering er skyld i det, og en VPN-undtagelse ville kun øge eksponeringen.

Tre betingelser, der afgør tillad eller bloker

Kør dem i rækkefølge. Den første betingelse, der fejler, afgør resultatet, så de senere behøver ikke testes.

Gæstenetværk er det klareste nej. På et hotelsegment er det lokale område alle andre gæster, så en undtagelse, der når din printer, når også deres bærbare. En printer, du ikke ejer, er ikke grund til at åbne det segment.

Administrerede enheder er det andet nej. Når en administratorprofil håndhæver always-on VPN med lockdown, genopretter klienten blokeringen efter enhver lokal ændring, og omvejen kan bryde den politik, du accepterede. Bed om en understøttet vej til den lokale ressource i stedet for at redigere indstillinger, der bliver overskrevet.

Den mindste undtagelse, din klient understøtter

Du vil have en destinationsafgrænset regel til én printeradresse, ikke en generel tillad-lokal-kontakt. En generel kontakt dækker typisk hele det private område og link-local-trafik, hvilket er langt mere, end én printkø har brug for, og den gør hver enhed på segmentet til en peer, du har accepteret.

Windows tilbyder split tunnelling, og nogle builds tilbyder også en lokalnetværksmulighed. Hvor den eneste understøttede rute er en hostpost, skal du tilføje en enkelt adresse gennem den fysiske gateway, efter tunnelen er oppe, for eksempel route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, og slette den igen, når sessionen slutter. WireGuard fungerer anderledes: AllowedIPs afgør, hvad der kommer ind i tunnelen, så en fuldtunnelprofil 0.0.0.0/0 bærer printjobbet til endepunktet, medmindre en mere specifik rute omgår den, og wg-quick kan installere firewallregler, der blokerer alt andet.

På Android er den always-on-indstilling, der blokerer forbindelser uden VPN, kill switchen, og printeropdagelse fra en app inde i den blokering har ingen LAN-vej. Modellen med per-app og undtagelser er dokumenteret på Android VPN-siden, og det er stedet at tjekke, før du ændrer noget: Android VPN-forbindelsesguide. Nyere macOS-versioner beder om lokalnetværkstilladelse separat fra tunnelen, og iOS gør det samme for lokalnetværksadgang, men køen kan stadig fejle med tunnelen oppe, fordi leverandørens klient ruter subnettet ind i den.

Uanset hvilken klient du bruger, hold undtagelsen til én adresse og de to eller tre porte, som printeren faktisk bruger. Reserver en DHCP-lease i stedet for at udvide reglen til hele subnettet, fordi adressen kan flytte sig.

Verificér undtagelsen, og vid, hvornår den skal rulles tilbage

Efter ændringen skal du gentilslutte og tjekke tre ting i rækkefølge. Printeren svarer på sine porte, en uskadelig testside udskrives, og et adresseopslag returnerer stadig VPN-endepunktet i stedet for din ISP. Hvis udskrivning virker, men opslaget viser din ISP, har du åbnet mere end printeren og bør rulle tilbage.

Gentag testen efter en genstart og efter enhver klient- eller profilopdatering, fordi opdateringer gendanner standardindstillinger ofte nok til at betyde noget. En undtagelse, der kun overlever til næste genopkobling, er ikke en beslutning, det er et midlertidigt hul. Skriv den præcise regel ned, så du kan fjerne den bevidst.

Hvis enheden er beregnet til kun tunnel, en rejsebærbar eller en maskine med klientdata, er det rigtige svar at beholde blokeringen og printe andre steder: gem som PDF og print fra en telefon eller en anden maskine, eller få adgang til en printserver, som tunnelen kan rute til. At slå kill switchen fra for ét job bytter en reel beskyttelse for en lille bekvemmelighed.