VPN e LAN di casa sulla stessa sottorete: segui prima la rotta
Entrambi gli adattatori rivendicano 192.168.1.0/24 e una sola rotta vince. Segui l'elenco degli adattatori, la rotta vincente e il ritorno prima di rinumerare o dare la colpa al DNS.
Ti connetti alla VPN dell'ufficio, l'icona nella barra diventa verde, l'intranet si carica e la stampante a due metri smette di rispondere. La condivisione che funzionava stamattina va in timeout sulla stessa macchina, e nessun registro menziona una stampante. Il riflesso è il DNS, perché un nome che non si risolve sembra un nome che non esiste, ma il problema è l'indirizzo: due adattatori ora rivendicano 192.168.1.0/24 e solo una rotta può vincere quel prefisso. Seguila in questo ordine e vedrai quale adattatore l'ha presa prima di cambiare qualcosa.
Parti dal sintomo, non dal tunnel
L'indizio è l'ambito. Se l'intranet funziona e ogni dispositivo locale fallisce, il tunnel è sano e il percorso locale no. Se i dispositivi locali funzionano e l'intranet fallisce, il contrario. Se tutto funziona tranne un host, sei davanti a un solo indirizzo che esiste su entrambi i lati.
Annota un indirizzo locale e uno remoto prima di toccare un'impostazione. “La stampante” non è verificabile; 192.168.1.40 lo è. Quello singolo passo evita l'ora persa più comune su questo problema, cioè riscrivere le impostazioni DNS per una decisione di routing.
Passo 1: vedi entrambi gli adattatori rivendicare il prefisso
Apri Connessioni di rete (ncpa.cpl) e leggi i due adattatori fianco a fianco. L'adattatore Ethernet mostra 192.168.1.50/24 con gateway 192.168.1.1. L'adattatore VPN mostra 192.168.1.201/24, inviato dal server. Entrambi sono legittimi, entrambi credono che il prefisso sia on-link, e lo stack ne manterrà una sola rotta.
Get-NetIPAddress -AddressFamily IPv4 elenca gli indirizzi, e Get-NetIPInterface | Sort-Object InterfaceMetric mostra l'ordine in cui lo stack li userà. Quella colonna della metrica è la decisione che stai per leggere, quindi annota i numeri invece di ricordarli.
Confuta la teoria del DNS a buon mercato: Resolve-DnsName printer.office.lan restituisce lo stesso indirizzo di ieri. Il nome si è risolto; poi il pacchetto è uscito dall'adattatore sbagliato. Due minuti qui risparmiano un pomeriggio nelle impostazioni del resolver.
Passo 2: leggi la rotta che ha vinto davvero
Find-NetRoute -RemoteIPAddress 192.168.1.40 stampa l'interfaccia, il salto successivo e l'origine che lo stack userebbe per quell'indirizzo. Tratta quell'output come la risposta, non come un indizio. route print -4 dà tutta la tabella quando vuoi vedere quale voce ha perso e di quanto.
La specificità batte l'intenzione. Un 192.168.0.0/25 inviato batte un 192.168.0.0/24 locale perché il prefisso è più lungo, quindi da 192.168.0.0 a 192.168.0.127 escono dal tunnel mentre la metà superiore resta locale. Che mezza LAN sparisca senza messaggio di errore è il comportamento corretto di quella tabella.
tracert -d 192.168.1.40 lo conferma da fuori dalla tabella: se il primo salto è un indirizzo di tunnel invece del tuo router, la rotta è tutta la storia. Su Linux la stessa domanda è ip route get 192.168.1.40, che stampa indirizzo di origine e dispositivo su una riga. Quando la risposta nomina tun0, smetti di guardare il browser.
Passo 3: controlla il ritorno prima di incolpare il client
Una rotta in avanti corretta fallisce comunque se il lato remoto non può rispondere. Quando si raggiunge una LAN di cliente attraverso il tunnel, il gateway di quella LAN deve sapere dove vive il pool del tunnel: ip route add 10.8.0.0/24 via 192.168.1.12 su quel router, e push “route 192.168.1.0 255.255.255.0” dal server perché i clienti conoscano il ritorno.
Senza la prima voce, la risposta lascia la destinazione verso il suo gateway predefinito, che inoltra un indirizzo privato al provider e lo scarta. Il sintomo è unidirezionale e facile da leggere male: le richieste compaiono su tun0, le risposte mai.
Una regola masquerade sull'host VPN elimina la necessità di quella rotta statica: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Nasconde anche gli indirizzi di origine reali, il che rende più difficile ogni domanda successiva sui registri. Un host di destinazione con il gateway predefinito sbagliato produce lo stesso silenzio, con un redirect ICMP nel caso migliore e un buco nero in quello normale, ed è per questo che la cattura va fatta su entrambe le estremità.
Passo 4: scegli una riparazione con cui puoi convivere
Per questo si usano cinque riparazioni, e non sono intercambiabili. Scegli in base a ciò che deve restare raggiungibile nello stesso momento, non in base a quale comando è più corto.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Le metriche sono l'opzione economica e quella a cui la gente ricorre per prima. La modifica vale per l'interfaccia, quindi funziona finché il tunnel è attivo, e appartiene a uno script accanto al client, non a una shell che dimenticherai. Non può dare accesso simultaneo allo stesso indirizzo su due reti, e questo è il limite che manda tutti gli altri giù per la tabella.
Rinumerare la LAN di casa in 10.10.0.0/24 è la soluzione pulita: un rinnovo del lease DHCP più le prenotazioni, le code di stampa e gli indirizzi codificati che citano l'intervallo vecchio. Rinumerare il lato ufficio di solito non è una tua decisione. IPv6 elimina del tutto la collisione quando entrambe le reti lo supportano, usando un prefisso locale univoco da fd00::/8 invece di qualcosa di memorizzabile, ma prova l'applicazione su TCP, non con un ping, perché ICMP può funzionare mentre il servizio no.
L'opzione di traduzione propria di OpenVPN è l'ultima risorsa, inviata dal server in una voce di directory specifica del client. Prende quattro parametri dopo il nome dell'opzione — direzione, rete, netmask e alias — e l'alias non è facoltativo: push "route 192.168.2.0 255.255.255.0" e push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". La rete e la netmask sono l'intervallo che il client vede (192.168.2.0/24), l'alias è il vero intervallo dell'ufficio lato server (192.168.1.0/24), e la rotta inviata è ciò che rende raggiungibile quell'intervallo visibile. L'ufficio appare allora a quel client sotto 192.168.2.x. Documenta la mappatura nel profilo, altrimenti la prossima persona la depurerà come guasto di routing.
Pubblicare un solo servizio è la versione ristretta della traduzione, e non ha affatto bisogno dell'opzione di OpenVPN. Una regola DNAT sull'host VPN ripubblica una sola porta, così la LAN conserva i suoi indirizzi e raggiunge il servizio all'indirizzo host che già conosce. Il costo è quello solito: il servizio vede l'host VPN come origine, quindi i registri per client e le ricerche inverse smettono di significare qualcosa. Questo copre una coda di stampa o una pagina di amministrazione, non host su entrambi i lati che si raggiungono.
Cosa non funzionerà ancora, e cosa registrare
Il broadcast non attraversa un tunnel instradato. DLNA, UPnP, l'esplorazione NetBIOS e Wake-on-LAN dipendono da broadcast o multicast che un dispositivo tun non trasporta, quindi nessuna rotta ripara la scoperta. Il bridging con dev tap estende il segmento, e con esso i broadcast DHCP, ARP e ogni altro pacchetto di scoperta; preferisci una rotta host unicast come route 192.168.2.1 255.255.255.255 per l'indirizzo lato LAN di un router remoto.
Due router che usano entrambi 192.168.1.1 sullo stesso percorso appartengono alla stessa famiglia di problemi: l'indirizzo locale vince sempre, quindi la pagina del router remoto resta irraggiungibile finché una LAN non si sposta. Aggiungere un secondo adattatore non cambia nulla in nessuno dei due casi.
Annota le prove prima di modificare qualcosa: ip route get o Find-NetRoute, ping -c 3 all'indirizzo in questione, un traceroute, e tcpdump -ni tun0 icmp sul client, poi la tabella di routing e i contatori NAT sul server. Un ping che funziona in un verso e muore nell'altro punta al ritorno, non al tunnel, e quella sola distinzione decide quale delle riparazioni sopra ti serve davvero.