iPhone-appen hittar inte lokala enheter när VPN:en är på
Två portar avgör om en iPhone-app kan nå en skrivare eller tv via en VPN: tillståndet för Lokalt nätverk och tunnelns egna rutter. Kontrollera dem i ordning.
Din skrivarapp visar en tom lista, kameraappen rapporterar att ingen enhet hittades och cast-knappen i en videoapp snurrar tills den ger upp. VPN-ikonen sitter i statusfältet, telefonen har full signal och Safari laddar sidor utan problem, så inget med anslutningen ser trasigt ut. Sedan öppnar du appens egna inställningar och hittar inget att slå om.
Jag gick rakt in i den här väggen med en etikettskrivare på ett hemnätverk: appen hade aldrig fått åtkomst till det lokala nätverket, och profilen jag testade var en full tunnel som svalde varje paket adresserat till 192.168.1.0/24. Två oberoende portar var stängda, och att öppna en av dem hade inte tagit bort symptomet.
Två portar mellan en app och en skrivare
Den första porten är ett integritetsbeslut som tillhör operativsystemet och inte appen. iOS avgör om en app får skicka trafik till adresser på det lokala nätverket, och frågar användaren första gången appen försöker. Den andra porten är routingtabellen. Ett paket riktat mot 192.168.1.50 lämnar antingen telefonen via Wi-Fi mot skrivaren, eller så går det in i tunneln, och det valet står i VPN-profilen.
De två portarna misslyckas på olika sätt, och det är just det som gör diagnosen möjlig. Ett nekat tillstånd dödar appens eget socket-anrop, så appen har inget att rapportera och faller tillbaka på ett generiskt tomt läge. Ett routingproblem ser ut som en timeout, eftersom paketen lämnade telefonen och dog någonstans på andra sidan. Samma tomma skärm, annan reparation.
Läs tillståndet innan du rör VPN:en
Öppna Inställningar, sedan Integritet och säkerhet, sedan Lokalt nätverk. Varje app som har begärt åtkomst visas där med en växel. Apple har flyttat och bytt namn på delar av den här skärmen mellan iOS 14 och iOS 18, så om posten inte är där du väntar dig, skriv Lokalt nätverk i inställningarnas sökfält i stället för att leta genom trädet.
Det som fångar folk är engångsfrågan. iOS frågar när en app först rör det lokala nätverket, och bara då. Tryck på Tillåt inte och frågan återkommer inte vid nästa start; växeln är den enda vägen tillbaka, och den börjar avstängd. Att installera om appen nollställer beslutet, vilket är varför vissa felsökningstrådar hävdar att en ominstallation löste upptäckten. Det gjorde den, genom att radera nekandet.
På en iPhone som är övervakad eller hanterad är växeln ibland grå. En nyttolast med integritetsinställningar som skickas ut via MDM kan förinställa eller låsa åtkomsten till det lokala nätverket, och en låst växel som är av betyder att reparationen är en policyändring och inte en telefonändring. Apple dokumenterar frågan och växeln per app här: support.apple.com/en-us/102229.
Kontrollera vad tunneln faktiskt routar
En full tunnel tar 0.0.0.0/0 och därmed varje privat område. Paket till 10.x, 172.16.0.0/12 och 192.168.x.x reser till servern, som oftast kastar dem eller översätter dem till sitt eget subnät, så skrivaren är oåtkomlig även efter att du gett tillståndet. En delad tunnel gör det motsatta, men bara för de områden som profilen listar.
IKEv2-profiler som byggs med Apple Configurator eller levereras som .mobileconfig uttrycker det som en inställning att skicka all trafik plus, i delat läge, en uttrycklig lista över lokala nätverk att utesluta. Klientappar byggda på NEPacketTunnelProvider uttrycker samma beslut genom includedRoutes. Inget av dem syns i statusfältet, och båda åsidosätter det appen förväntar sig att se.
Här är testet jag använder. Med VPN:en ansluten öppnar du routerns admin-sida på dess LAN-adress i Safari. Om offentliga webbplatser laddas medan den sidan får timeout ligger ditt privata område i tunneln. Om sidan laddas lämnar den lokala trafiken fortfarande telefonen via Wi-Fi, och blockeringen sitter någon annanstans.
Koppla symptomet till porten
Två appar på samma telefon kan vara oense, eftersom tillstånd ges per app medan rutter ges per profil. Jämför vad som misslyckas innan du ändrar något: mönstret namnger oftast porten av sig självt.
| What you see | Gate | Next step |
|---|---|---|
| Device list stays empty, Local Network switch is off | Permission | Enable the switch, force-quit the app, reopen it |
| Switch is on, router page times out, public sites load | Routing | Exclude the local range in the profile, or move to a split tunnel |
| Both pass, direct IP works, discovery stays empty | Link-local multicast | Enter the device address by hand, or check profile discovery support |
| Works by IP address, never by name such as printer.local | Name resolution | Fix mDNS reachability or use the numeric address |
| Everything fails with the VPN off, on hotel Wi-Fi | Client isolation | Change network, do not change permissions |
mDNS-raden förtjänar en kommentar. Upptäcktstrafik för Bonjour och de flesta cast-protokoll skickas som multicast till 224.0.0.251 och ff02::fb med link-local räckvidd, och en routad tunnel bär den inte. Därför kan en enhet svara på en direkt anslutning utan att någonsin dyka upp i en lista.
Testa handlingen, inte ikonen
När du har slagit om växeln för Lokalt nätverk, tvinga appen att stängas från appväxlaren och starta den igen. En körande process kan hålla kvar det nekade läget från före ändringen, och en app som fortsätter returnera en tom lista ser likadan ut oavsett om tillståndet fungerade. Kör sedan en konkret handling, till exempel skriva ut en testsida eller starta en video, i stället för att vänta på att en enhetslista ska fyllas.
Håll VPN-profilen fast genom jämförelsen. Om upptäckten börjar fungera först efter att du kopplar från har du lärt dig att tunneln är skyldig, inte tillståndet. Ändra en variabel per försök, annars säger nästa körning dig ingenting.
Åtgärda i den här ordningen
Sekvensen nedan är den jag följer nu, eftersom den aldrig lämnar en telefon i ett halvändrat läge där nästa test är oläsligt.
- Bekräfta att appen finns under Integritet och säkerhet, Lokalt nätverk, och att dess växel är på.
- Tvinga appen att stängas, starta den igen och försök en gång med den riktiga handlingen.
- Öppna routerns sida på LAN-adressen medan du är ansluten, för att bevisa om det privata området går genom tunneln.
- Om det gör det, redigera profilen så att lokala nätverk utesluts, eller be den som äger profilen att göra det.
- Om växeln är grå, behandla enheten som hanterad och skicka begäran till administratören.
Oftast gäller bara en av dem. Om ingen ändrar resultatet är de kvarvarande misstänkta nätverket självt, till exempel isolering på åtkomstpunkten eller en klienttillåtelselista knuten till Wi-Fi-adresser, och tabellen ovan pekar ut vilken.