Accesso alla LAN via OpenVPN rotto? Controlla zone, rotte e percorso di ritorno

Il tunnel segnala una connessione riuscita, la pagina del router stesso si carica, e l'unità di rete verso una macchina dietro di esso va ancora in timeout. Nulla in questa combinazione è contraddittorio: il router risponde in quanto se stesso, e raggiungere qualcosa dietro di esso è un'altra decisione presa altrove. Segui i controlli qui sotto in ordine e fermati al primo errore, perché ciascuno poggia sul precedente. Quando tutti e quattro passano, il guasto è sopra il tunnel, non dentro.

Quale filtro vede un pacchetto diretto alla LAN

Un pacchetto indirizzato al router viene consumato localmente; un pacchetto indirizzato a un host dietro di esso deve essere inoltrato, e i firewall giudicano questi due casi separatamente. Il permesso di raggiungere il router non dice quindi nulla sul permesso di attraversarlo. Un firmware che nasconde i suoi insiemi di regole implementa comunque entrambi, di solito come selettore che offre la LAN, Internet o entrambe. Se il selettore esclude la LAN, nessun controllo successivo conterà.

OpenWrt rende ispezionabile questa separazione, e la distinzione merita una lettura. La zona che termina il tunnel ha bisogno di una regola di inoltro verso la zona LAN, mentre una regola di input governa solo i servizi sul router stesso. Una pagina di amministrazione funzionante accanto a una LAN morta è il risultato abituale di quella regola di inoltro mancante.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Guarda la destinazione di inoltro della zona che porta il tunnel: accept è ciò che serve alla scala, e reject spiega ogni timeout sottostante. Due impostazioni vicine producono lo stesso sintomo, quindi escludile mentre sei qui. L'isolamento wireless nasconde gli host cablati ai client wireless, e un router che tratta gli host LAN inattivi come offline può scartare le risposte anche dopo che l'inoltro funziona.

Perché un tunnel diviso ha bisogno del prefisso spinto

Un client che invia tutto il traffico attraverso il tunnel possiede già il prefisso LAN tramite la sua rotta predefinita, quindi non c'è nulla da aggiungere. Il tunnel diviso è il caso che richiede il prefisso dichiarato esplicitamente, perché nient'altro nella configurazione lo menziona. Aggiungi la direttiva alla configurazione del server e ricarica il servizio.

push "route 192.168.50.0 255.255.255.0"

I profili che contengono route-nopull ignorano le rotte spinte, quindi lo stesso prefisso appartiene al file del client. In ogni caso, conferma che la voce sia arrivata invece di presumerlo, perché una sostituzione silenziosa appare identica a un problema di firewall.

ip route show | grep 192.168.50

Un peer da sito a sito chiede più di un push. Il server deve apprendere quali prefissi stanno dietro quel peer, cosa che fa una riga iroute nel suo file client-config-dir, e la sua tabella ha bisogno di una rotta corrispondente verso il tunnel.

La risposta ha bisogno di un indirizzo che possa raggiungere

Inoltrare la richiesta è solo metà di uno scambio, perché l'host LAN deve rispondere a un indirizzo del pool del tunnel. I router piccoli lo sistemano di solito traducendo l'origine sulla zona del tunnel, così la risposta è indirizzata al router e non richiede configurazione altrove. Rimuovi quella traduzione e l'host ha bisogno della propria rotta verso il pool, che ottiene gratis quando il router è il suo gateway predefinito. Un host con indirizzo impostato a mano e un altro gateway risponde tramite quel gateway, e il client vede una sessione aprirsi e poi bloccarsi.

tcpdump -ni tun0 host 192.168.50.20

Esegui questo sul router mentre il client ripete la richiesta, e leggi la destinazione della risposta invece della richiesta. Una risposta indirizzata al pool significa che il percorso di ritorno funziona e il guasto è più in profondità. Nessuna risposta significa che l'host non ha mai accettato il pacchetto, il che ti riporta all'insieme di regole.

Una scala che finisce nel posto giusto

Quattro controlli localizzano il livello, e ciascuno è un singolo comando invece di un giudizio. Eseguili in ordine e fermati al primo errore. L'ordine conta più dei comandi, perché un passo successivo che passa nasconde il motivo per cui uno precedente è fallito.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

I nomi vanno alla fine della scala, mai all'inizio. Una condivisione che risponde come 192.168.50.20 ma non come nas.local punta alla risoluzione o a un suffisso di ricerca, e le modifiche al firewall non possono cambiare nessuno dei due.

Annota il primo passo fallito, poi dai alle porte di servizio il loro giro, perché un listener e un permesso dell'host sono requisiti separati. Condivisione file, desktop remoto e flussi delle telecamere richiedono entrambi, e un firewall dell'host che si fida della sottorete LAN ma non del pool del tunnel scarta il client mentre ping riesce ancora. Quando tutti i controlli passano e l'applicazione continua a fallire, il guasto è sopra il tunnel: un servizio legato a un'interfaccia, o un proxy configurato sul client.