AirDrop funziona, poi la VPN si connette e l’altro Mac o iPhone sparisce dal pannello di condivisione. Nel registro della VPN non c’è nulla sulla scoperta, perché il guasto riguarda di solito la raggiungibilità locale e non la crittografia. La pagina di supporto di Apple ammette che una configurazione VPN che limita la rete locale può interferire con Continuity e AirDrop; è un indizio utile, non una diagnosi. Iniziate dalle verifiche economiche, poi leggete la tabella di routing e trattate l’interruttore dell’accesso locale come una decisione sulla vostra privacy e non come un valore predefinito da ribaltare.

Cosa si rompe prima ancora che il tunnel entri in gioco

Entrambi i dispositivi devono avere Wi-Fi o Bluetooth attivi, AirDrop deve ricevere dai contatti o da tutti entro la sua finestra di ricezione, e i due account devono essere individuabili l’uno per l’altro. Impostare il ricevente su tutti per dieci minuti è un esperimento legittimo: se l’altro dispositivo compare, il problema erano le impostazioni e il tunnel è innocente. Provate con un destinatario noto invece di giudicare da ciò che offre il pannello di condivisione.

Un browser che carica pagine dimostra che il percorso internet funziona, non che funzioni la scoperta locale. Lasciate invariati entrambi i dispositivi e il punto in cui siete, poi accendete e spegnete la VPN e notate se l’altro dispositivo sparisce solo mentre il tunnel è attivo. Se la scoperta muore con il tunnel e torna senza, il tunnel è la variabile e il resto della lista vale. Se fallisce in entrambi gli stati, i prerequisiti hanno bisogno di un altro passaggio prima di cambiare qualsiasi politica di rete.

Il pannello di condivisione si svuota quando si sposta la rotta predefinita

Un client a tunnel completo installa di solito una rotta predefinita attraverso il tunnel più due semi-rotte che catturano la maggior parte delle destinazioni. Una sottorete locale sopravvive a quella disposizione solo se ha una rotta più specifica; altrimenti sparisce nel tunnel. AirDrop stesso viaggia sull’interfaccia peer-to-peer AWDL, quindi un client che filtra o instrada in modo aggressivo le interfacce locali può interferire mentre il percorso internet resta perfetto. Quattro comandi coprono l’interfaccia, le rotte, la connessione attiva e il filtro dei pacchetti.

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

Leggete prima la riga predefinita: se punta a un’interfaccia utun e nessuna rotta più specifica copre la vostra sottorete, il traffico locale entra nel tunnel e la consapevolezza sparisce con esso. La coppia 0/1 e 128.0/1 è una forma comune di tunnel completo, perché quelle rotte battono la vera predefinita senza sostituirla. Una riga awdl0 con stato attivo e un indirizzo esclude che l’interfaccia peer sia abbassata. Quando tutte e tre sembrano normali, la restrizione viene dalla politica del client o da un filtro sull’host, non dalla tabella di routing.

Una forma merita di essere citata, perché intrappola chi usa reti ospiti, e non sono le semi-rotte. DHCP installa l’indirizzo appena ricevuto come rotta on-link, e quella voce è più specifica di entrambe le metà, quindi una sottorete ospite attraversa il tunnel esattamente come una domestica. A rimuoverla è la politica e non il routing: una preferenza che blocca la rete locale e installa una regola di rifiuto, un filtro sull’host che scarta la sottorete, o il permesso di rete locale di macOS per il client. Una tabella dall’aspetto normale con un pannello di condivisione morto è quindi la firma della sezione successiva, non quella della forma delle rotte.

Un Mac gestito può non offrire l’interruttore dell’accesso locale

Molti client espongono una preferenza per consentire l’accesso alla rete locale mentre il tunnel è attivo, ma quella preferenza è applicata dal client e dal profilo di gestione, quindi su un Mac gestito può essere bloccata, nascosta o ignorata. Una regola di filtro sull’host o un agente di sicurezza può bloccare il traffico peer indipendentemente da ciò che offre il client VPN. Cercate l’interruttore prima di concludere che non faccia nulla. Quell’interruttore vive nelle preferenze del client stesso e non nelle impostazioni di rete di macOS, ed è per questo che un client il cui pannello non lo mostra è di solito governato da un profilo di gestione.

Rimuovere la gestione o disattivare ogni filtro perché compaia un destinatario scambia una configurazione controllata con una sconosciuta. Attivate l’opzione di accesso locale solo quando corrisponde alla politica sotto cui lavorate, e lasciatela spenta su una rete ospiti dove la scoperta locale non è mai stata desiderata.

Dimostratelo con un file, non con un’icona

Dopo aver cambiato routing o politica, inviate un file reale al destinatario previsto e confermate che il trasferimento si completa. Un nome che compare nel pannello è una scoperta, e il ritorno della scoperta non equivale a un trasferimento finito.

Se il dispositivo continua a non comparire, confrontate una seconda coppia di dispositivi sulla stessa rete per separare un problema dell’host da uno dell’intera rete. Quel confronto è più rapido che ribaltare le opzioni VPN una per una e produce un fatto per il ticket. Annotate l’interfaccia predefinita, la forma delle rotte e lo stato dell’interruttore dell’accesso locale finché il guasto è riproducibile. Altrimenti la persona successiva ripeterà tutte e quattro le verifiche dall’inizio.

Articoli correlati