Newsgroup: it.comp.os.linux.sys
Titolo: ip gre tunnel (un po' lungo)

Dunque... debian 3.0rc2, proprio non mi funziona. Se solo riuscissi
a pingare gli endpoint del tunnel , come sarebbe ragionevole,
saremmo gia' a buon punto (scontato che non si riesce nemmeno a
pingare le macchine da una lan all'altra...). Le interfacce tunnel sono
su, le route sembrano corrette. Provato anche a ridurre la mtu, niente.
Provato a scambiare fra le due macchine i gateway privati
172.16.200.[1|2] del tunnel gre per il raggiungimento delle lan, niente.
Ricapitoliamo:
- due macchine debian D1 e D2 con due schede di rete. iptables
disattivato. C'e' un'altra linux box in mezzo con due schede di rete
che simula l'internet. Di seguito gli script utilizzati sulle due
macchine, l'output di ifconfig e route. Se devo ricompilare il kernel
(ha il default 2.4.18-bf24) per l'adv. routing, ditemelo subito... non
mi chiedete di usare freeswan, per il momento mi occorre qualcosa di
semplice e immediato. ipip e vtun sono stati gia' provati.
Thanks a lot.   :-)
Macchina D1
eth0: ip pubblico a.b.c.d
eth1: 
192.168.1.254/24
Macchina D2
eth0: ip pubblico e.f.g.h
eth1: 
192.168.2.254/24
<begin>
# Script per D1
#!/bin/bash
modprobe ip_gre
ip link set netb down
ip tunnel del netb
ip tunnel add netb mode gre remote e.f.g.h local a.b.c.d ttl 255
ip link set netb up
ip addr add 
172.16.200.1/24
 dev netb
ip route add 
192.168.2.0/24
 via 172.16.200.1 dev netb
netb      Link encap:UNSPEC  HWaddr 
3D-6E-B5-E2-00-00-00-00-00-00-00-00-00-00-00
-00
           inet addr:172.16.200.1  P-t-P:172.16.200.1  Mask:255.255.255.0
           UP POINTOPOINT RUNNING NOARP  MTU:1476  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
a.b.c.y         *               255.255.255.248 U     0      0        0 eth0
192.168.2.0     172.16.200.1    255.255.255.0   UG    0      0        0 netb
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
172.16.200.0    *               255.255.255.0   U     0      0        0 netb
default         a.b.c.z         0.0.0.0         UG    0      0        0 eth0
<end>
Macchina D2:
<begin>
# Script per D2
#!/bin/bash
modprobe ip_gre
ip link set neta down
ip tunnel del neta
ip tunnel add neta mode gre remote a.b.c.d local e.f.g.h ttl 255
ip link set neta up
ip addr add 
172.16.200.2/24
 dev neta
ip route add 
192.168.1.0/24
 via 172.16.200.2 dev neta
neta      Link encap:UNSPEC  HWaddr 
3D-6E-B5-EA-00-00-00-00-00-00-00-00-00-00-00
-00
           inet addr:172.16.200.2  P-t-P:172.16.200.2  Mask:255.255.255.0
           UP POINTOPOINT RUNNING NOARP  MTU:1476  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:4 dropped:0 overruns:0 carrier:4
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
e.f.g.y         *               255.255.255.248 U     0      0        0 eth0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     172.16.200.2    255.255.255.0   UG    0      0        0 neta
172.16.200.0    *               255.255.255.0   U     0      0        0 neta
default         e.f.g.z         0.0.0.0         UG    0      0        0 eth0
<end>
bye G.L.
-- 
« E' assolutamente evidente che l'arte del cinema
  si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

 semplice e immediato. ipip e vtun sono stati gia' provati.
con che esito?
io ho messo on un paio di tunnell con vtun in tempo zero...
se serve, posso darti una mano con quello, ma tunnell gre, non ne ho mai 
configurati.
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
| (fake address in reply-to field!)
+-------

 configurati.
Yes, vtund mi e' sembrato sul momento il metodo piu' rapido.   :-)
Dunque, con vtund ho provato fino al punto, dopo diverse peripezie,
di arrivare al messaggio (non l'ho sotto mano in questo momento) in cui
mi diceva che la connessione era stata chiusa dal server. Cio' che mi
ha "infastidito" un po', a parte messaggi non proprio "esplanatori" sul
file di configurazione (ma comunque superati in qualche modo...) e' 
stato non riuscire di primo acchito a trovare i log (seppure esista la
dir /var/log/vtund). Pertanto, per il poco tempo che ci ho dedicato,
non capisco perche' all'ultimo il server mi mandi a quel paese... ;-)
Ho paura comunque che ci siano diversi problemi a monte, in primis il
fatto che in fase di installazione delle linux box debian ho risposto
negativamente alla domanda sulla creazione dei tun/ethertap devices (e
comunque sono andato di mknod su /dev con tun --> tun0 c 10 200, e
tapN c 10 16+N, anche se non so poi se sia in grado di creare cio'
che interessa a, come dire, livello di "ifconfig", cioe ' tap0, tun0,
e affini (chiaro che i moduli ipip e tun sono caricati). Per giunta,
sempre nella mia ignoranza, non saprei se "tun0" e "tunl0" siano la
stessa cosa...    :-\
Grazie per l'aiuto, Paolo. Come mi rispondi, riporto i file di confi-
gurazione di vtund, parte server e parte client.


 tcpdump sulle interfacce fisiche dice nulla?
Il tcpdump me lo devo fare al cervello, per verificare cosa
si passano i neuroni: 3 ore buttate per un errore idiota,
un 61 al posto di 62 in un indirizzo pubblico, in ambo i
lati della faccenda. m***a!!!. Ho bisogno urgente di ferie... :-(
Grazie a tutti, il problema contingente e' adesso risolto.
Possiamo anche continuare con vtund, giusto per curiosita'.
Per openvpn, in user space e molto portabile, e' interessante
anche per far comunicare macchine eterogenee, e senza utilizzare
protocolli proprietari. La provero' presto.  :-)


 
vabbč, ormai continuo tanto per fare...
:-)
con vtun, ho dovuto sacramentare un pň anche io...
prova a creare:
crw-rw---- 1 root root 10,200 May 15 20:25 /dev/net/tun
per quanto riguarda le cfg client e server, ho trovato sufficienti i 
commenti, con cui sono perfino (!) riuscito a mettere on un server con 3 
lan remote (un fantastico p133...).
l'unica cosa da tener presente, č che mentre per il server puoi usare una 
macchina senza ip pubblico con redirezione di singola porta, la cfg lato 
'client' č piů semplice se ha un ip pubblico o comunque la redirezione di 
tutto il traffico in ingresso.


 tutto il traffico in ingresso.
non cabire...   :-\
BTW, riporto di seguito le configurazioni, precedute dall'errore
che mi vien fuori. Sul server e' operativo vtund -s, sul client
il comando che vien dato e' "vtund -n camp <ip_pubblico>. Pare che
non riesca a creare tun0, o sbaglio?    :-\
vtund[407]: VTun client ver 2.5 01/23/2002 started
vtund[407]: Connecting to 62.110.181.226
vtund[407]: Session camp[62.110.181.226] opened
vtund[407]: File descriptor in bad state (77)
tun0: ERROR while getting interface flags: No such device
vtund[407]: Command [/sbin/ifconfig %% down] error 255
vtund[407]: Session camp[62.110.181.226] closed
vtund[407]: Exit
oniferi:/etc# SIOCSIFADDR: No such device
tun0: ERROR while getting interface flags: No such device
SIOCSIFDSTADDR: No such device
tun0: ERROR while getting interface flags: No such device
SIOCSIFMTU: No such device
vtund[408]: Command [/sbin/ifconfig %% 192.168.0.2 point] error 1
SIOCADDRT: Network is unreachable
vtund[408]: Command [/sbin/route add -net 192.168.1.0] error 7
/etc/vtund.conf, lato server:
--- begin ---
# vtund config file (server)
options {
   port 5000;            # Listen on this port.
   ppp           /usr/sbin/pppd;
   ifconfig      /sbin/ifconfig;
   firewall      /sbin/iptables;
   route         /sbin/route;
}
default {
   type tun;
   proto udp;
   compress no;
   speed 0;
#  keepalive yes;
}
camp {
   password prova;
   type tun;             # IP tunnel
   proto tcp;            # UDP protocol
#  comp  lzo:9;         # LZO compression level 9
#  encr  yes;           # Encryption
   keepalive yes;        # Keep connection alive
   up {
     ifconfig "%% 192.168.0.1 pointopoint 192.168.0.2 mtu 1450";
     route "add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.0.2";
     program "/usr/sbin/arp -sD 192.168.0.1 eth1 pub";
     };
   down {
     program "/usr/sbin/arp -d 192.168.0.1 -i eth1";
     ifconfig "%% down";
     };
}
--- end ---
/etc/vtund.conf, lato client:
--- begin ---
# vtund config file (client)
options {
   port 5000;            # Listen on this port.
   ppp           /usr/sbin/pppd;
   ifconfig      /sbin/ifconfig;
   firewall      /sbin/iptables;
   route         /sbin/route;
}
default {
   type tun;
   proto udp;
   compress no;
   speed 0;
#  keepalive yes;
}
camp {
   password prova;
   type  tun;            # IP tunnel
   proto tcp;            # UDP protocol
#  comp  lzo:9;         # LZO compression level 9
#  encr  yes;           # Encryption
   keepalive yes;        # Keep connection alive
   up {
     ifconfig "%% 192.168.0.2 pointopoint 192.168.0.1 mtu 1450";
     route "add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.0.1";
     program "/usr/sbin/arp -sD 192.168.0.2 eth1 pub";
   };
   down {
     program "/usr/sbin/arp -d 192.168.0.2 -i eth1";
     ifconfig "%% down";
   };
}
--- end ---
bye G.L.

Paolo opg wrote:
 > vabbè, ormai continuo tanto per fare...
 >
Anch'io vorrei continuare: metti che in futuro abbia bisogno
di una connessione crittata e sicura, che ip_gre non offre...
 > con vtun, ho dovuto sacramentare un pò anche io...
 > prova a creare:
 > crw-rw---- 1 root root 10,200 May 15 20:25 /dev/net/tun
Gia' fatto.
 > l'unica cosa da tener presente, è che mentre per il server puoi usare 
una macchina senza ip pubblico con redirezione di singola porta, la cfg 
lato 'client' è più semplice se ha un ip pubblico o comunque la 
redirezione di tutto il traffico in ingresso.
non cabire...
BTW, riporto di seguito le configurazioni, precedute dall'errore
che mi vien fuori. Sul server e' operativo vtund -s, sul client
il comando che vien dato e' "vtund -n camp <ip_pubblico>. Pare che
non riesca a creare tun0, sbaglio?
vtund[407]: VTun client ver 2.5 01/23/2002 started
vtund[407]: Connecting to <ip_pubblico>
vtund[407]: Session camp[<ip_pubblico>] opened
vtund[407]: File descriptor in bad state (77)
tun0: ERROR while getting interface flags: No such device
vtund[407]: Command [/sbin/ifconfig %% down] error 255
vtund[407]: Session camp[<ip_pubblico>] closed

/etc/vtund.conf, lato server:






/etc/vtund.conf, lato client:





bye G.L.


This message was cancelled from within Mozilla.

 Eheheh...capita, capita...:-)
Quando capita in modo cosi' eclatante, e' forse il momento di staccar
la spina...   :-)
bye G.L:

 
la porta su cui ascolta il server č fissa, quella del client no.
quindi, lato server, basta redirigere una singola porta.
lato client, devi redirigerne un pň di piů...


 lato client, devi redirigerne un pò di più...
Ancora, abbi pazienza, non riesco ad afferrare il succo della
questione...   :-(
Comunque, il problema sta a monte: che tun debba essere staticamente nel
kernel, e non come modulo? Ho gogglato e ho trovato un tuo post del
2003, a proposito di tun e vtund.


 non riesca a creare tun0, sbaglio?
Si, sembra di si.  Domanda: c'e` tun/tap universal driver nel kernel?
+++
PS.  Posso fare il subliminale anch'io?  Imho non ti conviene spendere
un  secondo di piu`  su vtund,  che mi  sembra abbia  -solo- svantaggi
rispetto a openvpn.
E` molto  meno mantenuto, ha  problemi con l'incapsulamento in  udp (e
tcp  over tcp  e`  Male(TM)[1], la  difficolta`  di configurazione  e`
esattamente la  stessa e  offre delle feature  in piu`  (feature delle
quali ci si innamora, come la negoziazione TLS della chiave).
[1] 
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
Se interessa ho  scritto un mini howto su come  usare la modalita` TLS
di  openvpn  che  comprende  anche la  creazione  della  Certification
Authority:	
http://ouz.ath.cx/docs/
-- 
Vuoi fare colpo su di lei con me?
Fai colpo su di lei con me! Fai colpo su di lei con me!
[Dr. Gonzo : Paura e delirio a Las Vegas]

 (e sparatele due pose con ovpn.lan, dai...;-p)
Ma tu allora mi stai tentando, eh ;-)
Bene, giusto per rendere merito anche a openvpn questa e` la topologia
di una lan virtuale privata che abbiamo costruito fra amici:
 
http://ovpn.dsy.it/topology/
Ogni nodo possiede una 10.X/16  (abbiamo voluto fare gli sborooooni ;-)
e su tutti i nodi che vedete gira ospf (grazie a quagga).
I tunnel punto  a punto, costruiti appunto con  openvpn (e tap device,
contrariamente  all'howto di  cui sopra)  e  sono delle  /30 prese  da
172.16/16.  Usando shared keys ogni  host avrebbe dovuto avere una key
per ogni singolo tunnel, con TLS invece la CA firma un certificato per
ogni host e gli host non devono scambiarsi nulla per fare i tunnel.
Comunque immagino che  col culo che ho entro 5 minuti  dal mio post il
mio pc scoppiera` al volo e io (32) spariro` dalla mappa  :-D
Se a qualcuno interessano maggiori dettagli chieda pure.
Ah, whip e`  il 24, quindi se vedete  che manca potete ragionevolmente
cazziarlo :-P


 rispetto a openvpn.
Le macchine sono state consegnate ieri al cliente...    :-)
Comunque, posso allestirne un altro paio di recupero per provare,
e lo faro' senz'altro.
Al di la' della fretta di trovare una soluzione, il tunnel ip_gre
si e' dimostrato utile, anche perche', passatemi i termini,
e' senza stato e connessione: il cliente ha l'abitudine di spegnere
i router alla fine del lavoro, causa extra-traffico inesistente
fra le due sedi (in orari assai improbabili) che gli e' stato
fatturato nel passato...    :-).
Non che non sappia che ogni vpn, appositamente configurata, puo'
ovviare senz'altro a tutte queste eventualita'.
Per il momento pero', anche considerando che non vi e' necessita'
di crittazione, va piu' che bene: overhead pressoche' nullo, e banda
del tutto simile a quella solita. L'unico "cruccio", ma e' solo una
mia pignoleria, e' stato il browsing netbios tramite wins: con la
versione di samba di woody stable, non c'e' stato verso... Con una
versione piu' recente, magari riesce.
Grazie dei link, approfittero' per approfondire.    :-)
