Din skrivare fungerade för en timme sedan. Sedan slog du på VPN:en, och nu står jobben i kön tills de misslyckas. Den troliga orsaken är inte skrivaren, utan nödstoppet: det släpper trafik som skulle lämna maskinen utanför tunneln, och en LAN-skrivare är precis sådan trafik. Det egentliga beslutet är inte hur du lagar utskriften, utan om den här enheten överhuvudtaget ska nå det lokala nätverket. Tre villkor avgör det, och vilket som helst av dem kan avsluta diskussionen tidigt.

Vad nödstoppet släpper och varför

Ett nödstopp är en routingregel med ett felbeteende kopplat till sig. När tunneln är uppe lämnar matchande paket maskinen krypterade; när tunneln faller svartlistar klienten standardvägen så att ingenting går ut i klartext. En skrivare på samma subnät matchar aldrig tunnelvägen, så den behandlas som ett flyktförsök även om trafiken aldrig lämnar byggnaden.

Upptäckten gör symtomet förvirrande. Skrivare annonserar via multicast-DNS på port 5353, och kön som visas i dialogrutan för att lägga till skrivare byggs från dessa annonser. Medan blockeringen är aktiv kan annonsen utebli, så skrivaren försvinner från listan trots att adressen fortfarande svarar. IPP på 631, rå utskrift på 9100 och SMB på 445 är vanliga LAN-tjänster helt utan tunnelväg.

Bevisa först att skrivaren är nåbar

Innan du ändrar någon policy, bekräfta att skrivaren är frisk och bekräfta adressen du tror att den har. Läs adressen från skrivarens panel eller dess egen webbsida. En inaktuell post i operativsystemets lista kan peka på en adress som DHCP gav en annan enhet för veckor sedan.

Koppla bort VPN:en och testa sedan adressen och de två vanliga utskriftsportarna:

nc -vz 192.168.1.50 9100
nc -vz 192.168.1.50 631

I Windows är motsvarigheten Test-NetConnection 192.168.1.50 -Port 9100. Anslut VPN:en igen och upprepa. Svarar portarna med VPN:en avstängd och tar timeout med den på, har du återskapat blockeringen och resten är en policyfråga. Misslyckas de i båda lägena, stoppa: skrivaren, Wi-Fi-segmentet eller klientisoleringen är boven, och ett VPN-undantag skulle bara öka exponeringen.

Tre villkor som avgör tillåt eller blockera

Kör dem i ordning. Det första villkoret som misslyckas avgör utfallet, så de senare behöver inte testas.

ConditionAllow a scoped exceptionKeep the block
Who owns the networkHome or single-tenant office where you control the segmentHotel, cafe or shared Wi-Fi where the printer is not yours
Who owns the device policyPersonal device with no enforced profileManaged profile that enforces always-on VPN
What the device carriesNothing another LAN peer must not reachClient data that must not touch an untrusted segment

Gästnätverk är det tydligaste nej. På ett hotellsegment är det lokala intervallet alla andra gäster, så ett undantag som når din skrivare når också deras bärbara datorer. En skrivare du inte äger är inte skäl att öppna det segmentet.

Hanterade enheter är det andra nej. När en administratörsprofil tvingar fram alltid-på VPN med låsning återställer klienten blockeringen efter varje lokal ändring, och kringgåendet kan bryta mot policyn du accepterade. Be om en stödd väg för lokala resurser i stället för att redigera inställningar som skrivs över.

Det minsta undantaget din klient stöder

Det du vill ha är en destinationsbegränsad regel för en skrivaradress, inte en generell ”tillåt lokalt”-brytare. En generell brytare täcker oftast hela det privata intervallet och link-local-trafik, vilket är långt mer än en utskriftskö behöver, och den gör varje enhet på segmentet till en jämlike du har accepterat.

Windows erbjuder delad tunnling, och vissa byggen erbjuder också ett lokalnätsalternativ. Där den enda stödda vägen är en värdpost lägger du till en adress via den fysiska gatewayen efter att tunneln är uppe, till exempel route add 192.168.1.50 mask 255.255.255.255 192.168.1.1, och tar bort den när sessionen slutar. WireGuard fungerar annorlunda: AllowedIPs avgör vad som kommer in i tunneln, så en fulltunnelprofil med 0.0.0.0/0 bär utskriftsjobbet till slutpunkten om inte en mer specifik väg går runt den, och wg-quick kan installera brandväggsregler som blockerar allt annat.

På Android är den alltid-på-inställning som blockerar anslutningar utan VPN:en nödstoppet, och skrivarupptäckt från en app innanför den blockeringen har ingen LAN-väg. Modellen med per-app och undantag finns dokumenterad på Android VPN-sidan, som är stället att kontrollera innan du ändrar något:Guide för Android VPN-anslutning. Nyare macOS-versioner begär lokalnätstillstånd separat från tunneln, och iOS gör detsamma för åtkomst till lokalnätet, men kön kan ändå misslyckas med tunneln uppe eftersom leverantörens klient routar subnätet in i den.

Vilken klient du än använder, håll undantaget till en adress och de två eller tre portar som skrivaren faktiskt använder. Reservera en DHCP-lease i stället för att bredda regeln till hela subnätet, eftersom adressen kan flytta på sig.

Verifiera undantaget och vet när du ska ångra det

Efter ändringen, anslut igen och kontrollera tre saker i ordning. Skrivaren svarar på sina portar, en ofarlig testsida skrivs ut, och en adressökning returnerar fortfarande VPN-slutpunkten i stället för din ISP. Om utskrift fungerar men sökningen visar din ISP har du öppnat mer än skrivaren och bör återställa.

Upprepa testet efter en omstart och efter varje klient- eller profiluppdatering, eftersom uppdateringar återställer standardvärden tillräckligt ofta för att spela roll. Ett undantag som bara håller till nästa anslutning är inte ett beslut, det är ett tillfälligt hål. Skriv ner den exakta regeln så att du kan ta bort den medvetet.

Om enheten är avsedd att vara enbart tunnel, en resebärbar dator eller en maskin med kunddata, är rätt svar att behålla blockeringen och skriva ut någon annanstans: spara som PDF och skriv ut från en telefon eller en annan maskin, eller nå en utskriftsserver som tunneln kan routa till. Att stänga av nödstoppet för ett jobb byter ett verkligt skydd mot lite bekvämlighet.

Relaterade artiklar