È 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.