Connessione a un server remoto tramite una VPN quando l'indirizzo della sottorete della rete locale è in conflitto con una rete remota


35

Questa è una domanda canonica sulla risoluzione dei conflitti di sottorete IPv4 tra una rete locale di un client VPN e una attraverso il collegamento VPN da essa.

Dopo la connessione a una posizione remota tramite OpenVPN, i client tentano di accedere a un server su una rete esistente su una sottorete come 192.0.2.0/24. Tuttavia, a volte, la rete sulla LAN del client ha lo stesso indirizzo di sottorete: 192.0.2.0/24. I client non sono in grado di connettersi al server remoto digitando il suo IP a causa di questo conflitto. Non sono nemmeno in grado di accedere a Internet pubblico mentre sono connessi alla VPN.

Il problema è che questa sottorete 192.0.2.0/24 deve essere instradata dalla VPN, ma deve anche essere instradata come LAN del client.

Qualcuno sa come mitigare questo problema? Ho accesso al server OpenVPN.


3
Puoi provare a impostare una route statica per l'indirizzo / 32 dell'host che stai tentando di raggiungere e utilizzare il peer VPN come gateway e vedere cosa succede.
SpacemanSpiff,

se il concentratore vpn rispetta le rotte client, la tua sicurezza perimetrale potrebbe aver bisogno di aiuto. ottengo l'accesso alla lan di contabilità, aggiungo il percorso alla gamma di ingegneria e quindi posso collegarmi senza problemi. i merdosi firewall come Sonicwall fanno questo
nandoP

@SpacemanSpiff: Anche se questo potrebbe risolvere il problema sul lato client, il server non sarebbe ancora in grado di rispondere, poiché vedrebbe la connessione come proveniente dalla propria rete, non da un client VPN.
Massimo

Risposte:


18

È possibile risolvere questo problema usando NAT; non è molto elegante.

Quindi, supponendo che non si possa risolvere questo problema avendo reti interne che hanno numeri di rete così insoliti da non essere mai realmente in conflitto, ecco il principio:

Poiché sia ​​la sottorete locale che quella remota hanno numeri di rete identici, il traffico proveniente dal tuo client non realizzerà mai che deve passare attraverso il gateway del tunnel per raggiungere la sua destinazione. E anche se immaginiamo che potrebbe, la situazione sarebbe la stessa per l'host remoto in quanto sta per inviare una risposta.

Quindi rimani con me e fingi che non ci siano ancora problemi collaterali mentre scrivo che per la piena connettività, dovrai NAT entrambe le estremità all'interno del tunnel in modo da differenziare gli host e consentire il routing.

Fare delle reti qui:

  • La rete dell'ufficio utilizza 192.0.2.0/24
  • L'ufficio remoto utilizza 192.0.2.0/24
  • Il gateway VPN della rete dell'ufficio nasconde gli host 192.0.2.0/24 dietro il numero di rete NATed 198.51.100.0/24
  • Il gateway VPN della rete dell'ufficio remoto nasconde gli host 192.0.2.0/24 dietro il numero di rete NATed 203.0.113.0/24

Quindi all'interno del tunnel VPN, gli host dell'ufficio sono ora 198.51.100.x e gli host dell'ufficio remoto sono 203.0.113.x. Facciamo inoltre finta che tutti gli host siano mappati 1: 1 nel NAT dei rispettivi gateway VPN. Un esempio:

  • L'host di rete dell'ufficio 192.0.2.5/24 è mappato staticamente come 198.51.100.5/24 nel gateway vpn dell'ufficio NAT
  • L'host di rete dell'ufficio remoto 192.0.2.5/24 è mappato staticamente come 203.0.113.5/24 nel NAT gateway gateway vpn

Pertanto, quando l'host 192.0.2.5/24 nell'ufficio remoto desidera connettersi all'host con lo stesso IP nella rete dell'ufficio, deve farlo utilizzando l'indirizzo 198.51.100.5/24 come destinazione. Succede quanto segue:

  • Nell'ufficio remoto, l'host 198.51.100.5 è una destinazione remota raggiunta attraverso la VPN e instradata lì.
  • Nell'ufficio remoto, l'host 192.0.2.5 viene mascherato come 203.0.113.5 quando il pacchetto passa la funzione NAT.
  • In ufficio, l'host 198.51.100.5 viene tradotto in 192.0.2.5 quando il pacchetto passa la funzione NAT.
  • In ufficio, il traffico di ritorno verso l'host 203.0.113.5 passa attraverso lo stesso processo nella direzione opposta.

Quindi, mentre esiste una soluzione, ci sono una serie di problemi che devono essere affrontati affinché questo funzioni nella pratica:

  • L'IP mascherato deve essere utilizzato per la connettività remota; Il DNS diventa complesso. Questo perché gli endpoint devono avere un indirizzo IP univoco, come visualizzato dall'host di connessione.
  • Una funzione NAT deve essere implementata su entrambi i lati come parte della soluzione VPN.
  • La mappatura statica degli host è un must per la raggiungibilità dall'altra parte.
  • Se il traffico è unidirezionale, solo l'estremità ricevente necessita del mapping statico di tutti gli host coinvolti; il cliente può cavarsela con NAT dinamicamente se lo si desidera.
  • Se il traffico è bidirezionale, entrambe le estremità richiedono una mappatura statica di tutti gli host coinvolti.
  • La connettività Internet non deve essere compromessa indipendentemente dalla VPN divisa o non divisa.
  • Se non riesci a mappare 1 a 1, diventa disordinato; un'attenta contabilità è una necessità.
  • Naturalmente si corre il rischio di utilizzare indirizzi NAT che risultano essere anche duplicati :-)

Quindi risolvere questo richiede un'attenta progettazione. Se il tuo ufficio remoto è davvero composto da guerrieri della strada, aggiungi un livello di problemi:

  • non sanno mai in anticipo quando finiscono con ID rete sovrapposti.
  • il gateway per ufficio remoto NAT dovrebbe essere implementato sui propri laptop.
  • il gateway dell'ufficio avrebbe bisogno di due VPN, una NAT-free e una NATed, per coprire entrambi gli scenari. Altrimenti, nel caso in cui qualcuno dovesse scegliere una delle sottoreti che hai scelto per il metodo NAT, le cose non funzionerebbero .

A seconda del client VPN, potresti essere in grado di selezionare automaticamente una VPN o l'altra a seconda dell'indirizzo di rete del segmento locale.

Osservare che ogni menzione di NAT in questo contesto indica una funzione NAT che, per così dire, ha luogo nella prospettiva del tunnel. Dal punto di vista del processo, la mappatura NAT statica deve essere eseguita prima che il pacchetto "entri" nel tunnel, ovvero prima che sia incapsulato nel pacchetto di trasporto che deve portarlo attraverso Internet all'altro gateway VPN.

Ciò significa che non bisogna confondere gli indirizzi IP pubblici dei gateway VPN (e che in pratica possono anche essere NAT: ed, ma quindi completamente al di fuori della prospettiva del trasporto al sito remoto tramite VPN) con gli indirizzi privati ​​univoci utilizzati come mascherate per gli indirizzi privati ​​duplicati. Se questa astrazione è difficile da immaginare, viene fatta un'illustrazione di come NAT possa essere fisicamente separato dal gateway VPN per questo scopo qui:
Uso di NAT in reti sovrapposte .

Condensare la stessa immagine a una separazione logica all'interno di una macchina, in grado di eseguire entrambe le funzionalità gateway NAT e VPN, sta semplicemente facendo lo stesso esempio un ulteriore passo avanti, ma pone maggiormente l'accento sulle capacità del software a portata di mano. Hacking insieme ad esempio OpenVPN e iptables e pubblicare qui la soluzione sarebbe una sfida degna.

Dal punto di vista software è certamente possibile:
PIX / ASA 7.xe versioni successive: esempio di configurazione di una LAN IPsec da LAN a LAN con reti sovrapposte
e:
Configurazione di un tunnel IPSec tra router con sottoreti LAN duplicate

L'implementazione effettiva dipende quindi da molti fattori, dai sistemi operativi coinvolti, dal software associato e dalle sue possibilità non da ultimo. Ma è certamente fattibile. Dovresti pensare e sperimentare un po '.

L'ho imparato da Cisco come visto dai link.


NAT potrebbe funzionare anche con molte connessioni VPN e le loro traduzioni? Non ho capito completamente il caso qui. Ho un thread qui unix.stackexchange.com/q/284696/16920 su Come fare VPN da sito a sito con sottoreti sovrapposte Unix-Way?
Léo Léopold Hertz

17

Se è necessaria una soluzione temporanea sporca a un server ips singolo o solo noto, la soluzione più semplice dovrebbe essere l'opzione di routing lato client statico.

Nel mio caso ho aggiunto il mio server di destinazione desiderato (192.168.1.100) alla mia tabella di routing sul mio client Linux tramite:

route add 192.168.1.100 dev tun0

Successivamente, rimuovi questa route statica con il comando di eliminazione route.


2
Questa è una soluzione perfetta e un tempismo persino perfetto! :)
Yuval A

Quanto dura questo? Fino a quando non ti disconnetti? Fino al riavvio?
carbocation

1
Sul mio sistema Linux (xfce con ubuntu / mint) le impostazioni vengono "perse" dopo una disconnessione vpn e sì, anche dopo un riavvio. Puoi verificare se l'impostazione è attiva con il comando route (ci sarà una voce con l'ip e il dispositivo tun0 di solito in fondo)
Aydin K.

La versione OSX di route prende l'interfaccia in modo diverso, quindi invece di dev tun0te ne hai bisogno-interface tun0
Sirens

5

sì, questo è il peggio. per me è successo tutto il tempo dalle camere d'albergo, prima che gli amministratori vpn si rendessero conto che avrebbero dovuto usare gamme ip più oscure. 10.0.0.0/24 e 10.1.1.1/24 sono i peggiori. se puoi aiutarlo mai ip una rete wireless come quella.

quindi la risposta è "aggiustare" il wap per usare una diversa rete interna (es. 10.255.255.0/24) e quindi darti un contratto di locazione diff (es. ip in un intervallo che può tornare al corp vpn), o se non hai / Non riesco a ottenere admin su Wap, basta andare su Starbucks. o 20 minuti di ricovero :)

se questo è solo in un ambiente di laboratorio, usa solo intervalli diversi.


Dang davvero? Non esiste un'opzione migliore?
John Russell,

1
non che io sappia ... questo è sempre stato un problema ... sembra che qualcuno abbia votato male alla mia risposta, ma in realtà non ha suggerito una soluzione ... ah, uccidi il messaggero!
nandoP

3

Sono su un mac con El Capitan. Mentre i suggerimenti sopra non hanno funzionato per me, mi hanno portato a una soluzione funzionante:

  1. prima di avviare la VPN, eseguire ifconfig
  2. avviare la VPN, fare ifconfige notare quale è la nuova interfaccia. Nel mio caso era ppp0 con un indirizzo IP di 192.168.42.74

    ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
    
  3. digitare:

    sudo route add 192.168.1.79  192.168.42.74
    

Ho provato prima con un pinge poi ho dimostrato che funzionava accedendo al server git.

Quando ho provato a usare dev ppp0 per la fine del comando route come detto sopra, mi sono lamentato.


2
Da cosa viene 192.168.1.79questo scambio?
carbocation

Il server di destinazione a cui ti stai connettendo. Questo server risiede nella stessa rete della VPN, non della connessione locale.
Carlo del Mundo,

1

Ho una soluzione semplice che sto usando in uno spazio di co-working che ha un intervallo IP in conflitto (10.x)

Mi sono connesso alla rete con il mio telefono cellulare, quindi ho condiviso la connessione di rete via bluetooth con il mio laptop. Ora posso usare la VPN per il mio datore di lavoro remoto.

Sono sicuro che funzionerà allo stesso modo tramite USB se hai bisogno di una connessione più veloce.


1
Ehi, questa è in realtà una soluzione abbastanza intelligente.
Nathan Osman,

1

Se hai solo bisogno di colpire alcuni uno o due indirizzi IP, aggiungi l'istruzione route al tuo file di configurazione ovpn in questo modo:

percorso 192.168.1.10 255.255.255.255

percorso 192.168.1.11 255.255.255.255

Aggiungerà un percorso solo per quei IP quando connetti il ​​tuo VPN e lo rimuoverà quando il VPN lo ha disconnesso.

Ha funzionato per me su Windows comunque.


1

La risposta di Aydin K. è per Linux. Se desideri la stessa funzionalità per Windows, puoi digitare

route ADD 192.168.1.10 <IP of tunnel adapter>

o

route ADD 192.168.1.10 IF <interface id>

puoi ottenere l'id dell'interfaccia con il comando:

route print

0

Proprio come promemoria: l'intero problema è dovuto agli anni di carenza di indirizzi IPv4 e all'ampio uso della gamma di indirizzi IP privati dietro NAT per ovviare a questa carenza!

La soluzione ideale e definitiva a questo problema è piuttosto semplice (anche se può e vorrà del tempo per essere implementata a livello globale): IPv6 ...

In un mondo IPv6, non c'è carenza di IP pubblico (e non ci sarà, evento tra qualche decennio). Quindi non c'è motivo di non avere un IP pubblico su ogni singolo dispositivo di ogni rete. E se hai bisogno dell'isolamento della rete, continua a filtrare con un firewall, ma senza NAT brutto ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.