Newsgroup: it.comp.reti.ip-admin
Titolo: Tunnel tra sedi

Ho la necessità di unire, anche senza cifratura,
due uffici che condividono la stessa subnet e senza
alcun indirizzamento subnettabile.
192.168.0.0/24
 da ambo i lati.
Gli IP sono univoci, ad esempio il .1 sarà solo su
un lato ed il .2 sarà solo dall'altro ma come ho detto
non posso prendere ad esempio una /29 e routare staticamente
tutta la subnet, perchè io ho .1 lato A, .2 lato B, .3 lato A
e così via.
Il metodo più rapido secondo voi qual'è ?
Le due reti devono comunicare come se fossero
connesse allo stesso switch, ovvero devo poter
pingare lato A l'ip 192.168.0.2 che si trova
sul B senza configurare nulla sul singolo client.
Ho due default gateway debian, uno per ciascuna rete.
Di conseguenza posso impostare un routing statico
direttamente sui singoli gw facendo puntare i
singoli IP al lato remoto del tunnel ma in caso di
risoluzione di 192.168.0.2 dal lato a, il gw non
dovrebbe nemmeno essere interrogato, dato che l'ip
di destinazione è sulla stessa subnet di quello sorgente.
Con un proxy arp dovrei risolvere in maniera relativamente
semplice giusto? E potrei anche aver la possibilità di
staccare una postazione e portarla nel secondo ufficio
senza dover reinstradare nulla, nel caso ci dovessero
essere spostamenti di personale.
In pratica, questa è la topologia:
192.168.0.1 => 192.168.0.200 => internet <= 192.168.0.210 <= 192.168.0.2
  ^^^^^^^        ^^^^^^^^^^                   ^^^^^^^^^^      ^^^^^^^^^
  client1        default gw                   default gw      client 2
come faccio a far comunicare i due estremi nel modo più trasparente
possibile?

 
[cut]
ti serve un bridge ethernet.
non ne ho mai messi in piedi quindi non ti so dare indicazioni, ma spero 
che il nome ti possa almeno servire come punto di partenza ^^
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 possibile?
http://openvpn.net/bridge.html
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 che il nome ti possa almeno servire come punto di partenza ^^
Uhm, dici un bridge tramite openvpn?
Adesso che ci penso, l'ho già fatto da un cliente.
Ho tirato su la VPN in tap e da ambo i lati ho messo
in bridge l'interfaccia tap con l'interfaccia fisica.
Forse dovrei riuscire a fare la stessa cosa con un
più elementare GRE, senza scomodare cifrature, il
traffico tra sedi non è importante che sia cifrato.
Esperienze nel mettere come estremo di un bridge un
estremo di un GRE?
Un Bridge over GRE in sostanza, qualche insidia?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 
http://openvpn.net/bridge.html
Si, infatti, l'ho anche già fatto.
E' venerdì anche per me.
La cifratura non è fondamentale, esiste
una alternativa più leggera che non
richieda una VPN a tutti gli effetti?
Se butta male, comunque, tiro su la vpn
e faccio il mio bel bridge. Se ben ricordo,
non devo nemmeno impazzire con il routing.
Configuro il bridge over vpn sui due gateway
ed i client si vedono in automatico.
L'ho fatto solo una volta. ( questa cosa qui :) )


 richieda una VPN a tutti gli effetti?
Quel che vuoi fare tu si chiama VPN. 
Quindi non puoi *non* usare una VPN.
Fabio

 Quindi non puoi *non* usare una VPN.
...volevo evitare di usare openvpn in favore
di qualche protocollo più semplice.
Comunque, si fa veramente prima a mettere in piedi
una VPN con sharedkey, fare il bridge e vivere felici.
In caso di spostamento di una postazione dalla sede A
alle sede B non dovrei nemmeno fare nulla per riconfigurare
così loro son belli felici ed autonomi.


 una VPN con sharedkey, fare il bridge e vivere felici.
se utilizzi IPSec, quest'ultimo introduce delle cryptoroute nella 
tabella di routing. Ovviamente se hai due sedi che malauguratamente 
hanno la stessa classe, sarà innaturale inserire una rotta valida.
Sempre in caso di IPSec, dovresti trovare un prodotto che riesca ad 
attivare una funzione chiamata "Nat Before VPN". Tramite questa 
funzione, puoi "prendere in giro" il tunnel cambiando classe su uno dei 
due peer senza stravolgere le reti ed in maniera trasparente.
ciao.

 due peer senza stravolgere le reti ed in maniera trasparente.
Grazie per il contributo.
Però, se devo mettere in piedi tutto sto mucchietto di roba, faccio
prima a tirar su openvpn e metterlo in bridge.
Fatta la VPN, non devo modificare nemmeno una singola regola di routing.


 prima a tirar su openvpn e metterlo in bridge.
punti di vista, io odio openvpn perchè mi toglie troppo tempo nella 
configurazione :)



Non per fare polemica ma...e invece IPsec? A me pare molto piu' ostico.
-- 
Cio' che si vede, e'.

 configurazione :)
Eh?
Saranno 8-10 righe di config in tutto.


ripeto, punti di vista. io trovo molto più semplice e coerente ipsec. 
mai un problema. con openvpn ho dovuto arrabattare soluzioni ogni volta.
ma probabilmente si tratta di mia defezione, ci mancherebbe :)


leggi sopra. più che altro ho spesso avuto problemi a posteriori, 
soprattutto se dovevo far passare delle soluzioni VoIP.
IMHO, preferisco ipsec a openvpn. come tu puoi preferire alfa romeo a 
fiat :)

 soprattutto se dovevo far passare delle soluzioni VoIP.
Che tipo di problemi? Nel caso si presentassero anche a me...
Comunque sia, capisco cosa intendi dire, tant'è che se leggi, ho
subito chiesto la possibilità di evitare una VPN vera e propria.
Mi sarebbe bastato un normalissimo tunnel.
Fortunatamente la soluzione è temporanea, solo qualche mese, attivo
la VPN, il cliente fa quello che deve fare poi smonto tutto.

 subito chiesto la possibilità di evitare una VPN vera e propria.
guarda, in ipsec puoi anche togliere la crittografia su header e data in 
entrambe le fasi... praticamente diventa una "rotta statica annunciata" 
"libera e felice, come una farfalla" [cit.] :)

Un Bridge over GRE in sostanza, qualche insidia?
Solo che ti servono kernel e iproute sufficientemente recenti (ma non
ricordo quanto) per poterlo fare.
http://blog.bofh.it/debian/id_379
Ovviamente devi fare la massima attenzione a tutte le questioni di MTU
e a limitare i broadcast a livelli ragionevoli.
-- 
ciao, |
Marco | The Internet is full. Go away.  -- Joel Furr

 e a limitare i broadcast a livelli ragionevoli.
Grazie, effettivamente erano valori ai quali non avevo pensato.
