Skrivaren offline när VPN ansluter? Kontrollera routingtabellen

Din bärbara dator ansluter till företagets VPN, och skrivaren två meter bort slutar svara. Ingenting har ändrats på skrivaren, och det lokala nätverket har inte gått ner. Det som har ändrats är routingtabellen: tunneladaptern äger nu en väg som täcker skrivarens adress, så dessa paket lämnar genom VPN:et och anländer till en gateway som inte har en aning om var ditt platta nätverk finns. Gå igenom de fyra kontrollerna nedan i ordning och stanna vid den första som misslyckas.

Steg ett: bevisa att skrivaren fortfarande nås på LAN:et

Innan du rör routingen, bekräfta att enheten lever för något som inte använder VPN:et. Be en telefon på samma Wi-Fi öppna skrivarens webbsida, eller pinga adressen från en annan maskin på det platta nätverket. Om skrivaren inte svarar där heller är VPN:et en tillfällighet och felet ligger hos skrivaren, dess Wi-Fi-anslutning eller klientisolering på åtkomstpunkten.

Om den svarar överallt utom på den här bärbara datorn har du ett routing- eller namnmatchingsproblem som bor på den bärbara datorn, och nästa steg säger vilket av de två det är.

Steg två: hitta den väg som Windows faktiskt väljer

Läs inte tabellen uppifrån och ner och gissa inte. Fråga Windows vilken post den väljer för den exakta adressen du bryr dig om, och hämta gränssnittsindexet samtidigt.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute skriver ut den vinnande vägen och dess gränssnitt, och det är de två fakta som allt annat hänger på. route print -4 visar posterna runt omkring, inklusive de två halvstandardvägarna som fulltunnelklienter installerar: 0.0.0.0/1 och 128.0.0.0/1, som tillsammans täcker hela IPv4-rymden utan att någonsin ersätta 0.0.0.0/0. En /1 är längre än en /0, men din 192.168.1.0/24 är ännu längre, och därför väger en saknad LAN-väg tyngre än själva tunnelns anspråk.

Två regler avgör svaret. Det längsta matchande prefixet vinner först, och bland poster med samma prefix vinner den lägsta totala metriken, där totalen kombinerar vägmetriken och gränssnittsmetriken. Om det valda gränssnittet är tunneln, fortsätt. Om det är den fysiska adaptern och trafiken fortfarande misslyckas, stanna här: ditt problem är namnuppslagning eller skrivarens egen åtkomstlista, inte VPN-vägen.

Steg tre: lägg till den smalaste vägen som namnger gateway och gränssnitt

Reparationen är en post som pekar skrivarens adress mot den lokala routern på den lokala adaptern. Kör den i en förhöjd kommandotolk och ersätt värdena du just läste.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

Värdet för if är gränssnittsindexet för den fysiska adaptern. Att utelämna det är den vanligaste orsaken till att kommandot verkar lyckas och inte ändrar något, för när två adaptrar kan nå samma nästa hopp står Windows fritt att välja den du inte ville ha. Flaggan -p gör posten beständig, så den överlever en omstart i stället för att dö med sessionen.

Föredra en värdrutt för den enskilda enheten framför en rutt för hela 192.168.1.0/24. En subnätväg är bredare än uppgiften behöver, och den kolliderar i samma stund som företagssidan också använder det prefixet: ett prefix har då två ägare, och vilken post som vinner avgör vilket nätverk du faktiskt kan nå.

Åt andra hållet: om du har rensat bort alternativet för standardgateway på VPN-anslutningen för att skydda LAN:et, slutar även de fjärran privata prefixen att matchas. Lägg till rutter för dem via VPN-gränssnittet på samma sätt, annars blir tunneln en länk som inte bär något.

Steg fyra: se till att undantaget överlever nästa anslutning

Många företagsklienter installerar om hela sin ruttsuppsättning vid varje anslutning och räknar samtidigt om gränssnittsmetrikerna, så en rutt som fungerade i går kan bli övertrumfad i dag. Efter återanslutning, upprepa Find-NetRoute för skrivaren och kontrollera att gränssnittet fortfarande matchar den fysiska adaptern. Om posten är borta är det något som raderar den; en beständig rutt skyddar dig inte mot en agent som sopar tabellen. Schemalagda aktiviteter som lägger tillbaka rutten efter att VPN:et anslutit är den vanliga lösningen, och de är också lösningen som går sönder när adapterindexet ändras efter en docka eller en drivrutinsuppdatering.

Håll koll på IPv6 för sig. En klient som bara gör anspråk på IPv4-standarden kan lämna IPv6-standardvägen på den fysiska adaptern, så en skrivare som nås över IPv6 fortsätter att fungera medan IPv4 misslyckas, eller tvärtom. Testa med ping -4 och ping -6 innan du bestämmer att routingtabellen är oskyldig.

Vad den lokala genvägen kostar dig

Varje rutt som kringgår tunneln är ett hål i tunnelns löfte. Trafik till den adressen passerar inte längre företagets gateway, vilket betyder ingen inspektion, ingen loggning och ingen policyverkställighet på den. På en hanterad enhet kan det vara ett efterlevnadsproblem snarare än en preferens, så fråga om det finns ett officiellt split-tunnelundantag innan du lägger till ett för hand. Håll din så smal som uppgiften och så kortvarig som situationen tillåter.

Om skrivaren svarar efter ändringen, upprepa de fyra kontrollerna efter din nästa återanslutning i stället för att anta att reparationen höll. Om den inte svarar, fånga Find-NetRoute-utdata före och efter anslutningen; skillnaden berättar om klienten raderade posten eller bara rangordnade om den.