AirDrop borta med VPN på? Kontrollera den lokala routingen

AirDrop fungerar, sedan ansluter VPN:en och den andra Macen eller iPhonen försvinner från delningsbladet. Ingenting i VPN-loggen nämner upptäckt, eftersom felet oftast handlar om lokal nåbarhet och inte om kryptografi. Apples supportsida medger att en VPN-konfiguration som begränsar det lokala nätverket kan störa Continuity och AirDrop; det är en användbar ledtråd, inte en diagnos. Börja med de billiga kontrollerna, läs sedan routingtabellen och behandla reglaget för lokal åtkomst som ett beslut om din integritet och inte som ett standardvärde att vända.

Vad som går sönder innan tunneln ens är inblandad

Båda enheterna behöver Wi-Fi eller Bluetooth påslaget, AirDrop måste ta emot från kontakter eller från alla inom sitt mottagningsfönster, och de två kontona måste kunna hitta varandra. Att ställa mottagaren på alla i tio minuter är ett legitimt experiment: dyker den andra enheten upp där var inställningarna problemet och tunneln är oskyldig. Testa med en känd mottagare i stället för att döma efter vad delningsbladet erbjuder.

En webbläsare som laddar sidor bevisar att internetvägen fungerar, inte att den lokala upptäckten fungerar. Låt båda enheterna och platsen där du står vara oförändrade, slå sedan på och av VPN:en och notera om den andra enheten bara försvinner medan tunneln är uppe. Om upptäckten dör med tunneln och kommer tillbaka utan den är tunneln variabeln och resten av listan gäller. Om det misslyckas i båda lägena behöver förutsättningarna en runda till innan någon nätverkspolicy ändras.

Delningsbladet töms när standardvägen flyttar sig

En klient med full tunnel installerar oftast en standardväg genom tunneln plus två halvvägar som fångar de flesta destinationer. Ett lokalt subnät överlever det arrangemanget bara om det har en mer specifik väg; annars försvinner det in i tunneln. Själva AirDrop går över AWDL-gränssnittet för jämlikar, så en klient som filtrerar eller routar lokala gränssnitt aggressivt kan störa medan internetvägen förblir perfekt. Fyra kommandon täcker gränssnittet, vägarna, den aktiva anslutningen och paketfiltret.

ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40

Läs standardraden först: pekar den på ett utun-gränssnitt och täcker ingen mer specifik väg ditt subnät, går lokal trafik in i tunneln och medvetenheten försvinner med den. Paret 0/1 och 128.0/1 är en vanlig form av full tunnel, eftersom de vägarna slår den riktiga standardvägen utan att ersätta den. En awdl0-rad med aktiv status och en adress utesluter att jämlikgränssnittet är nere. När alla tre ser normala ut kommer begränsningen från klientpolicyn eller ett filter på värden och inte från routingtabellen.

En form är värd att nämna, eftersom den fångar folk på gästnätverk, och det är inte halvvägarna. DHCP installerar adressen du just fick som en väg på länken, och den posten är mer specifik än båda halvorna, så ett gästsubnät klarar tunneln precis som ett hemmanät. Det som tar bort det är policy och inte routing: en inställning som blockerar det lokala nätverket och installerar en avvisningsregel, ett filter på värden som släpper subnätet, eller macOS-tillståndet för lokalt nätverk för klienten. En normalt utseende tabell med ett dött delningsblad är därför signaturen för nästa avsnitt, inte för vägformen.

En hanterad Mac erbjuder kanske inte reglaget för lokal åtkomst

Många klienter visar en inställning som tillåter lokal nätverksåtkomst medan tunneln är uppe, men den inställningen upprätthålls av klienten och av hanteringsprofilen, så den kan vara låst, dold eller överskriden på en hanterad Mac. En brandväggsregel på värden eller en säkerhetsagent kan blockera jämliktrafiken oavsett vad VPN-klienten erbjuder. Leta efter reglaget innan du drar slutsatsen att det inte gör något. Det reglaget bor i klientens egna inställningar och inte i macOS nätverksinställningar, och därför styrs en klient vars panel inte visar det oftast av en hanteringsprofil.

Att ta bort hanteringen eller stänga av varje filter så att en mottagare syns byter en kontrollerad konfiguration mot en okänd. Slå bara på alternativet för lokal åtkomst när det passar policyn du arbetar under, och låt det vara av på ett gästnätverk där lokal upptäckt aldrig var önskad.

Bevisa det med en fil, inte med en ikon

När du har ändrat routing eller policy, skicka en riktig fil till den avsedda mottagaren och bekräfta att överföringen slutförs. Ett namn som dyker upp i bladet är upptäckt, och att upptäckten kommer tillbaka är inte samma sak som en slutförd överföring.

Om enheten fortfarande inte syns, jämför ett andra enhetspar på samma nätverk för att skilja ett värdproblem från ett problem i hela nätverket. Den jämförelsen är snabbare än att växla VPN-alternativ ett i taget, och den ger ett faktum till ärendet. Skriv ner standardgränssnittet, vägformen och läget för reglaget för lokal åtkomst medan felet går att återskapa. Annars upprepar nästa person alla fyra kontrollerna från början.