Newsgroup: it.comp.os.linux.iniziare
Titolo: openvpn lato client

Vorrei provare un servizio gratuito chiamato ultravpn, da
quanto ho capito permettono di stabilire una connessione vpn al
loro server.
http://tinyurl.com/yaa7qvb
Devo approfondire meglio, ma mi pare di capire che a me non resta
che configurare openvpn sul mio sistema come client per accedere
al loro server con nome utente e password.
� una cosa complicata?
Avreste per caso qualche dritta o link da suggerire?
grazie in anticipo.  :-)

io ho provato un cosa simile...
hamachi
http://www.hamachi.it/old/
semplice


Ti ringrazio per il suggerimento, controller�.
Nel frattempo ho visto questo link:
http://www.zeroshell.net/openvpn-client
mi pare di aver capito che basti openvpn
installato e configurato per collegarsi al server vpn di cui ho
l'indirizzo e la porta in ascolto, ad esempio:
remote 
zeroshell.example.com
 1194
da mettere nel file /etc/openvpn/openvpn.conf
Tra l'altro vedo che c'� un file di esempio in quella dir che tra
le varie voci dice:
-----------------------------------------------------------------
# This option defines the IP or DNS name of the other side of
# your VPN
# connection.  This option is needed if you are making client or
# P-t-P 
# connections.  If you are the server, use "local" instead.  This
# may
# be specified as a domain name or IP address.
#remote 
vpn.server.org
-----------------------------------------------------------------
poi dovrebbe servire il certificato (lo so � un po' generico
probabilmente):
-----------------------------------------------------------------
# Certificate Authority file 
# This file must be identical on all hosts that connect to your
# VPN
#ca certs/ca.crt
-----------------------------------------------------------------
Questo non ho ben capito ma immagino andr� preso dal servizio cui
facevo riferimento. Mettono a disposizione un installer per
windows, e anche un pacchetto per mac. Da quanto ho capito
leggendo si dovrebbe prendere il paccheto mac, decomprimerlo e
dentro dovrebbero esserci due files da copiare nella directory di
configurazione di openvpn...devo ancora veder meglio
sinceramente, ma se non sbaglio si tratta di una chiave.
Fine della configurazione.
Dopodich� vedo dal link sopra, che per connettersi alla vpn basta
il comando:
openvpn --config zeroshell.ovpn
col giusto file di configurazione ovviamente.
A quel punto dice che dovrebbe venire richiesto utente e
password... io speravo che questo avvenisse solo la prima volta
immagino ci sia poi la possibilit� di non dovrla immettere ogni
volta. Francamente non mi intendo di chiavi e certificati...
In ogni caso tutto sto discorso per fare presente che potrebbe
essere questa la strada giusta. Quando provo e sicuramente
qualcosa non funzioner� come da copione, mi rifar� vivo, speriamo
con una domanda meno generica.  ;-)

 con una domanda meno generica.  ;-)
Allora, spulciando nel forum di supporto di ultravpn, ho ottenuto
3 files:
StealthyUltraVPN.conf
UltraVPN.conf
UltraVPN.crt
Tutti sono stati spostati in /etc/openvpn.
Inoltre i files ".conf" sono stati editati opportunamente in modo
da utilizzare il certificato corrispondente:
ca /etc/openvpn/UltraVPN.crt
Non ho ben capito di preciso a cosa servissero i due diversi
files di configurazione, ma ho notato che il primo "stealth"
utilizza protocollo tcp, mentre il secondo udp.
Fatto questo ho provato a collegarmi (vi risparmio tutto il log,
metto solo gli errori finali):
---------------------------------------------------------------
# openvpn --config ./UltraVPN.conf
[...]
Fri Oct  9 18:46:19 2009 [ludwig] Peer Connection Initiated with
                                                      x.x.x.x:24
Fri Oct  9 18:46:21 2009 SENT CONTROL [ludwig]: 'PUSH_REQUEST'
                                                    (status=1)
Fri Oct  9 18:46:21 2009 PUSH: Received control message:
  'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
   x.x.x.x,dhcp-option DNS y.y.y.y,route 10.9.0.1,topology
   net30,ping 10,ping-restart 120,ifconfig 10.9.24.10 10.9.24.9'
Fri Oct  9 18:46:21 2009 Options error: unknown
                          --redirect-gateway flag: bypass-dhcp
Fri Oct  9 18:46:21 2009 Options error: Unrecognized option or
     missing parameter(s) in [PUSH-OPTIONS]:5: topology (2.0.9)
Fri Oct  9 18:46:21 2009 OPTIONS IMPORT: timers and/or timeouts
                                                       modified
Fri Oct  9 18:46:21 2009 OPTIONS IMPORT: --ifconfig/up options
                                                       modified
Fri Oct  9 18:46:21 2009 OPTIONS IMPORT: route options modified
Fri Oct  9 18:46:21 2009 OPTIONS IMPORT: --ip-win32 and/or
                                 --dhcp-option options modified
Fri Oct  9 18:46:21 2009 Note: Cannot open TUN/TAP dev
              /dev/net/tun: No such file or directory (errno=2)
Fri Oct  9 18:46:21 2009 Note: Attempting fallback to kernel 2.2
                                              TUN/TAP interface
Fri Oct  9 18:46:21 2009 Cannot allocate TUN/TAP dev dynamically
Fri Oct  9 18:46:21 2009 Exiting
===============================================================
Da come ho capito io, il server ad un certo punto mi invia dei
messaggi di controllo, a cui il mio capo della connessione non sa
cosa rispondere.
Ho cercato in rete sul primo errore (redirect-gateway), ma non
ho capito bene di cosa si tratta e dove mettere le mani per
agiustare le cose.
Spero possiate darmi qualche dritta. ;-)

 Spero possiate darmi qualche dritta. ;-)
Dunque, gli errori restano, per� un errore era la mancanza del
modulo tun caricato, quindo dopo averlo caricato con "modprobe
tun" ottengo:
==============================================================
Sat Oct 10 14:34:26 2009 [ludwig] Peer Connection Initiated with
 
87.98.173.225:24
Sat Oct 10 14:34:27 2009 SENT CONTROL [ludwig]: 'PUSH_REQUEST'
                                                       (status=1)
Sat Oct 10 14:34:27 2009 PUSH: Received control message:
    'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
                                                          94.23.3'
Sat Oct 10 14:34:27 2009 Options error: unknown
                             --redirect-gateway flag: bypass-dhcp
Sat Oct 10 14:34:27 2009 Options error: Unrecognized option or
        missing parameter(s) in [PUSH-OPTIONS]:5: topology (2.0.9)
------------
Un breve commento a questo primo pezzo di log:
in rete non ho ancora trovato nulla circa il mancato
riconoscimento del flag --redirect-gateway. Tuttavia questo
errore non mi suona bene per nulla...
Invece il fatto che non riconosca il paramentro "5 topology", pare
sia dovuto alla versione di openvpn: la mia sarebbe 2.0.9 mentre
forse all'altro capo della connessione gira una versione pi�
avanzata con funzionalit� che la mia non supporta.
Nonostante questi errori rimasti, dal log pare poi che qualcosa
venga portato a termmine:
===============================================================
Sat Oct 10 14:34:27 2009 OPTIONS IMPORT: timers and/or timeouts
                                                       modified
Sat Oct 10 14:34:27 2009 OPTIONS IMPORT: --ifconfig/up options
                                                       modified
Sat Oct 10 14:34:27 2009 OPTIONS IMPORT: route options modified
Sat Oct 10 14:34:27 2009 OPTIONS IMPORT: --ip-win32 and/or
                                 --dhcp-option options modified
Sat Oct 10 14:34:27 2009 TUN/TAP device tun0 opened
Sat Oct 10 14:34:27 2009 /sbin/ifconfig tun0 10.9.8.46
                                 pointopoint 10.9.8.45 mtu 1500
Sat Oct 10 14:34:27 2009 NOTE: unable to redirect default gateway
               -- Cannot read current default gateway from system
Sat Oct 10 14:34:27 2009 /sbin/route add -net 10.9.0.1 netmask
                                  255.255.255.255 gw 10.9.8.45
Sat Oct 10 14:34:27 2009 Initialization Sequence Completed
-----------------------------------------------------------------
Insomma in soldoni � stata tirata su l'interfaccia tun0 con
indirizzo 10.9.8.46.
Certo quella nota "NOTE: unable to redirect ecc ecc" non suona
bene...
--------------------------------------------------------------------
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.212.x.x  P-t-P:10.6.6.6  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:411 errors:1 dropped:0 overruns:0 frame:0
          TX packets:447 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:68415 (66.8 KiB)  TX bytes:46593 (45.5 KiB)
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-
                                                         00-00-00-00-00
          inet addr:10.9.8.46  P-t-P:10.9.8.45  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  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:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.9.0.1        10.9.8.45       255.255.255.255 UGH   0      0        0 tun0
10.9.8.45       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.6.6.6        0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
----------------------------------------------------------------------------
Ecco. Per� il punto � che non so bene come verificare se funziona
o no.
Ho provato a collegarmi ad una pagina in rete per capire quale
fosse l'ip con cui mi presentavo e risulta sempre l'ip del mio
isp, quindi la connessione a quel sito non passa per la vpn.
Secondo me c'entra parecchio la nota circa il default gateway che
non riuscirebbe a redirigere.
Dal canto mio ho provato qualche manovra manuale:
per esempio ho cancellato il default gateway e aggiunto un nuovo
tun0:
route del default
route add default gw tun0
Ma non ho ottenuto nulla, ad esempio il collegamento ad un sito
non funziona...
Vorrei provare a redirigere tutto il traffico internet sulla vpn.
Dai log sopra, dall'output di ifconfig e route ecc. Avreste
qualche dritta da darmi?

 bene...
Dopo diverse ricerche ho trovato che quel messaggio deriva
dall'aver impostato redirect-gateway nel file di configurazione.
Tolto quello la nota scompare.
Ho l'impressione di essere riuscito a creare il tunnel.
Ma il problema a questo punto sembra essere:
"Come instradare il traffico internet nel tunnel?"
Mi farebbe veramente molto comodo un aiuto.  :-|
Se vi occorrono altre informazioni per darmi una mano, non
esitate a chiedere...

 "Come instradare il traffico internet nel tunnel?"
In teoria e' proprio cio' che "redirect-gateway" dovrebbe fare. Dovresti 
installare una versione recente di openvpn (2.1rc20 e' l'ultima) per 
escludere che il problema sia la tua versione che e' vecchia. Se non puoi, 
puoi provare a simulare manualmente cio' che farebbe redirect-gateway, ossia 
semplificando:
(dopo che il tunnel e' up) crei una route specifica verso l'IP pubblico 
dell'host remoto che termina il tunnel
# ip route add a.b.c.d/32 dev ppp0 via x.y.z.w
dove a.b.c.d e' l'IP dell'endpoint remoto del tunnel, ppp0 e' l'interfaccia 
che da su Internet, e x.y.z.w e' l'IP del tuo ISP (se ce l'hai).
Poi cancelli la route di default:
# ip route del default dev ppp0 via x.y.z.w
(sempre sostituendo ppp0 e x.y.z.w come sopra)
e la ricrei che punta al tunnel:
# ip route add default dev tun0 via 10.9.8.45
Occhio che quando il tunnel viene chiuso le cose non ritornano 
automaticamente come erano prima (cosa che accadrebbe se usassi redirect-
gateway), quindi e' meglio che ti fai uno script up.sh che esegue le tre 
operazioni di cui sopra e un altro script down.sh che ripristina le cose 
come erano, e poi li metti nella configurazione come script da eseguire 
nelle direttive "up" e "down" rispettivamente.

 nelle direttive "up" e "down" rispettivamente.
Mmmm, per fare questo devo mettere mano megllio al manuale,
intanto proverei manualmente. Grazie di nuovo e a presto!  :-D

 intanto proverei manualmente. Grazie di nuovo e a presto!  :-D
Vedo che l'IP della VPN che ti viene assegnato e' diverso da quello che 
avevi postato prima, che potrebbe significare che cambia ogni volta che ti 
connetti.
Allora potresti fare una cosa del genere (assumendo che l'IP 10.6.6.6 del 
tuo ISP sia fisso):
------------------------
#!/bin/bash
# up.sh
ip route add a.b.c.d/32 via 10.6.6.6 dev ppp0
ip route del default via 10.6.6.6 dev ppp0
ip route add default via "$5" dev tun0
------------------------
#!/bin/bash
# down.sh
ip route del default via "$5" dev tun0
ip route add default via 10.6.6.6 dev ppp0
ip route del a.b.c.d/32 via 10.6.6.6 dev ppp0
------------------------
e nel file di configurazione metti
up /path/to/up.sh
down /path/to/down.sh

 down /path/to/down.sh
Capito.
Il problema � per� come togliere i dubbi su quale sia
effettivamente l'ip del servizio che viene usato.
Propongo come prova di scegliere uno dei due indirizzi e
pingarlo, ricavandone l'ip numerico.
Noto quello, commento l'altro indirizzo, e metto l'ip ricavato
nella direttiva remote.
Aggiungo gli script e metto le direttive up e down ecc.
Vediamo un po' cosa salta fuori.
Ma alla fine per testare che la connessione esce dalla vpn come
si dovrebbe fare? Io mi collego ad un sito per vedere il mio ip,
maci sono modi pi� eleganti?
Grazie ancora allora, poi facccio sapere.

 Vediamo un po' cosa salta fuori.
No, c'� qualcosa che non funziona nello scriptino up.sh
Allora l'ho tolto dalla configurazione e ho provato a
dare a mano il comando ip e vedo lo stesso errore:
# ip route add 87.98.x.x/32 dev ppp0 via 10.6.6.6
RTNETLINK answers: File exists
87.98.x.x � l'ip remoto del servizio che offre la vpn.
10.6.6.6 � l'ip che dovrebbe collegarmi all'isp attraverso
l'interfaccia ppp0.
RTNETLINK ... b�, cercher� info. Se gi� hai intuito il problema o
se vuoi loutput della connessione con gli scriptini attivi che �
fallita dimmi pure.
Ciao e grazie di nuovo in ogni caso  :-)

 maci sono modi più eleganti?
Fai un traceroute verso qualche indirizzo remoto e vedi. Oppure ti colleghi 
a uno dei vari siti whatismyIP e verifichi che l'IP che appare sia diverso 
da quello che appare quando ti colleghi normalmente col tuo provider. 

 fallita dimmi pure.
Si' se puoi postare il log e' piu' semplice fare troubleshooting.

 l'a.b.c.d.
Ho forse scoperto un altro metodo. Se attivi l'interfaccia di management 
(che pero' non se se esiste nella 2.0) puoi dare il comando "state" per 
ottenere una riga del tipo
1255291465,CONNECTED,SUCCESS,172.22.1.3,a.b.c.d
dove a.b.c.d e' l'IP remoto. Pero' come detto non so se la versione 2.0 
implementa l'interfaccia di management. Inoltre e' da verificare cosa 
succede quando viene chiamato down.sh, suppongo che tale informazione non 
sara' piu' disponibile.

 Si' se puoi postare il log e' piu' semplice fare troubleshooting.
Into ecco il file di configurazione, alla fine per fare una prova
ho escluso gli idirizzi multipli mettendo nel "remote"
direttamente l'ip numerico.
=========================================
# cat /etc/openvpn/StealthyUltraVPN.conf
client
dev tun
proto tcp
hand-window 15
remote-random
#redirect-gateway
remote 87.98.164.142 443
#remote 
stealthy.ultravpn.fr
 443
#remote 
stealthy.ultravpn.net
 443
resolv-retry infinite
nobind
# Try to preserve some state across restarts.
persist-key
persist-tun
ca /etc/openvpn/UltraVPN.crt
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
# Set log file verbosity.
verb 3
auth-user-pass
# execute scripts at up and down
up /etc/openvpn/up.sh
down /etc/openvpn/down.sh
=============================================
Ok, ora vediamo il log (ho tagliato ilprimo pezzo):
================================================================
[...]
Mon Oct 12 00:17:10 2009 [ludwig] Peer Connection Initiated with
 
87.98.164.142:443
Mon Oct 12 00:17:11 2009 SENT CONTROL [ludwig]: 'PUSH_REQUEST'
                                                       (status=1)
Mon Oct 12 00:17:12 2009 PUSH: Received control message:
    'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
              208.67.222.222,dhcp-option DNS 208.67.220.220,route
        10.7.0.1,topology net30,ping 10,ping-restart 120,ifconfig
                                         10.7.51.246 10.7.51.245'
Mon Oct 12 00:17:12 2009 Options error: unknown
                            --redirect-gateway flag: bypass-dhcp
Mon Oct 12 00:17:12 2009 Options error: Unrecognized option or
      missing parameter(s) in [PUSH-OPTIONS]:5: topology (2.0.9)
Mon Oct 12 00:17:12 2009 OPTIONS IMPORT: timers and/or timeouts
                                                        modified
Mon Oct 12 00:17:12 2009 OPTIONS IMPORT: --ifconfig/up options
                                                        modified
Mon Oct 12 00:17:12 2009 OPTIONS IMPORT: route options modified
Mon Oct 12 00:17:12 2009 OPTIONS IMPORT: --ip-win32 and/or
                                  --dhcp-option options modified
Mon Oct 12 00:17:12 2009 TUN/TAP device tun0 opened
Mon Oct 12 00:17:12 2009 /sbin/ifconfig tun0 10.7.51.246
                                pointopoint 10.7.51.245 mtu 1500
Mon Oct 12 00:17:12 2009 /etc/openvpn/up.sh tun0 1500 1544
                                    10.7.51.246 10.7.51.245 init
RTNETLINK answers: No such process
RTNETLINK answers: File exists
Mon Oct 12 00:17:12 2009 script failed: shell command exited with
                                                  error status: 2
Mon Oct 12 00:17:12 2009 Exiting
=================================
Ecco che da quell'errore simile a prima col tentativo manuale.
Ovviamente gli scripts sono copiaincollati da quelli sufferiti.
Comunque a scanso d'equivoci:
===================
# cat up.sh down.sh
#!/bin/bash
# up.sh
ip route add 
87.98.164.142/32
 via 10.6.6.6 dev ppp0
ip route del default via 10.6.6.6 dev ppp0
ip route add default via "$5" dev tun0
#!/bin/bash
# down.sh
ip route del default via "$5" dev tun0
ip route add default via 10.6.6.6 dev ppp0
ip route del 
87.98.164.142/32
 via 10.6.6.6 dev ppp0
===================================================
Non saprei...se ci capisci qualcosa sono tutto orecchi! :-D
Ma quindi l'ip privato che mi assegna il mio isp (tra l'altro
dinamico perch� cambia ad ogni riconnessione) non � coinvolto nel
nuovo instrafamento...
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.212.92.30  P-t-P:10.6.6.6
			 Mask:255.255.255.255
in questo caso mi riferisco a 10.212.92.30. Questo col tunnel non
c'entra pi� nulla? chiedo non vedendolo appparire nelli script up.sh.
Inoltre... non mi � chiaro cosa sia quel "$5" nello script,
potresti fare un po' di luce sulla faccenda?

 faccenda?
Guarda nel log come viene invocato lo script up.sh:
/etc/openvpn/up.sh tun0 1500 1544 10.7.51.246 10.7.51.245 init
$5 e' 10.7.51.245, ossia l'indirizzo VPN dell'endpoint remoto, che e' quello 
che deve diventare il default gateway.

 deve diventare il default gateway.
Capit, grazie.
Nel prossimo post metto il log come accordato.

 Nel prossimo post metto il log come accordato.
Senza tunnel:
---------------
# ip route show
10.6.6.6 dev ppp0  proto kernel  scope link  src 10.212.76.15 
127.0.0.0/8
 dev lo  scope link 
default dev ppp0  scope link 
# ifconfig 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.212.76.15  P-t-P:10.6.6.6  Mask:255.255.255.255
----------------------------------------------------------------------
Con il tunnel avviato e per forza di cose senza lo script up.sh:
---------------
# ip route show
10.7.0.1 via 10.7.51.245 dev tun0 
10.7.51.245 dev tun0  proto kernel  scope link  src 10.7.51.246 
10.6.6.6 dev ppp0  proto kernel  scope link  src 10.212.76.15 
127.0.0.0/8
 dev lo  scope link 
default dev ppp0  scope link 
# ifconfig 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:10.212.76.15  P-t-P:10.6.6.6  Mask:255.255.255.255
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-
                                                          00-00-00-00-00  
          inet addr:10.7.51.246  P-t-P:10.7.51.245  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  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:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
------------------------------------------------
Ho tagliato qualcosina nell'ifconfig, ma ho lasciato integrali i
dettagli dell'interfaccia tun0.
Spero sia utile.
Aggiungo un pezzetto di log della connessione via openvpn:
---------------------------------------------------
Mon Oct 12 11:11:01 2009 TUN/TAP device tun0 opened
Mon Oct 12 11:11:01 2009 /sbin/ifconfig tun0 10.7.51.246
                          pointopoint 10.7.51.245 mtu 1500
Mon Oct 12 11:11:01 2009 /sbin/route add -net 10.7.0.1
                    netmask 255.255.255.255 gw 10.7.51.245
Mon Oct 12 11:11:01 2009 Initialization Sequence Completed
----------------------------------------------------------
Ok direi che � tutto. Grazie di nuovo.  :-)
$ ip route show
10.6.6.6 dev ppp0  proto kernel  scope link  src 10.212.76.15
127.0.0.0/8
 dev lo  scope link
default dev ppp0  scope link
[simplyjoe@slack-12 ~]$ ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:9446 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:15716776 (14.9 MiB)  TX bytes:15716776 (14.9 MiB)
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.212.76.15  P-t-P:10.6.6.6  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:85 errors:1 dropped:0 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:26476 (25.8 KiB)  TX bytes:8058 (7.8 KiB)

JohnnyNewbie wrote:

Ok, allora forse capisco perche' i comandi non funzionano. Prova ad usare 
questi script:
#!/bin/bash
# up.sh
ip route add 
87.98.164.142/32
 dev ppp0
ip route del default dev ppp0
ip route add default dev tun0
------------------------
#!/bin/bash
# down.sh
ip route del default dev tun0
ip route add default dev ppp0
ip route del 
87.98.164.142/32
 dev ppp0
--------------------------
(I "via" non sono strettamente necessari perche' sono tutti link point to 
point).

 point to point).
Ma quindi, l'errore se cos� si pu� definire era tutto l�...??
Ricapitolando:
la mia versione 2.0.9 non supporta il redirect-gateway.
cos� alla connessione col server non avviene automaticamente la
creazione di un nuovo default gateway.
Bisogna quindi farlo a mano o con degli script aggiuntivi.
I comandi sono:
ip route add 
87.98.164.142/32
 dev ppp0
ip route del default dev ppp0
ip route add default dev tun0
Chiss� che magari non serva a qualcuno tutta sta roba.
Insomma, non mi resta che ringraziarti molto per l'aiuto senza
cui non avrei combinato nulla.
Saluti!

 Ma quindi, l'errore se così si può definire era tutto lì...??
L'errore era dovuto alla sintassi pignola di "ip", come ho detto sopra.

 usi di solito.
Si certo, ho capito sei stato chiarissimo.
Tra l'atro ormai mi sono abituato ad usare bind in locale come
cache dns e per il mio uso va pi� che bene cos�.
Solo che con la connessione che uso attualmente ho avuto
l'impressione che in certe occasioni non funzioni come al solito,
invece i dns del provider vanno meglio.
Con la vpn attiva invece vedo che anche bind funziona bene, per
cui lo preferisco al provider.
In ogni caso lascio perdere troppi script, resolv.conf preferisco
gestirlo a mano.
Devo riportare invece un problemino. La mia connessione cade ogni
30 minuti. Ho notato che appena mi riconnetto (tirando su
nuovamente la ppp0) anche openvpn che stava ritentando invano una
riconnessione al server, riesce ad agganciarsi di nuovo, non devo
rieseguire l'autenticazione, quindi tutto liscio e tun0 torna in
piedi.
Per� il traffico non viene instradato su tun0 in automatico,
secondo me non viene eseguito lo script up.sh.
Lanciandolo manualmente invece passo nuovamente per la vpn.
Strano...
Sono abituato allo script che sta in /etc/ppp/ip-up che viene
eseguito ad ogni connessione ad internet via ppp.
Quando esattamente viene eseguito lo script up?
EDIT:
Ferma...spetta, ho dato un'occhiata al manuale. Penso di aver
capito che l'opzione --up-restart serva ad eseguire up.sh (nel
mio caso) anche ai ritentativi di openvpn...ora provo. Infatti la
tun0 ho controllato meglio, e resta in piedi (non funzionante
ovviamente) anche se la ppp0 � down (cio� quando mi cade la
connessione.
Penso che la direttiva da mettere nel file di configurazione sia
up-restart...ora provo.
saluti.

 up-restart...ora provo.
Per� c'� un problema, se il ritentativo avviene prima che abbia
riconnesso ppp0, lo scriptno up.sh che viene eseguito ritorna
errore in quanto appunto non trova l'interfaccia ppp0 e il
comando ip route ecc ecc, fallisce.
Questo comportamento porta all'uscita con errore del'intero
openvpn.
Penso che sia possibile aggiungere un "exit 0" alla fine dello
script per ovviare a questo fatto...far� sapere.

 script per ovviare a questo fatto...far� sapere.
No, non � quella la soluzione. Ma ora ho messo la versione
2.1.rc20 di openvpn e sto cercando di capire come fargli
instradare automaticamente il traffico sulla vpn senza dover
predisporre alcun script.

 opzioni che ti danno loro.
Ho compilato impacchettato ed installato la versione
openvpn-2.1.rc20 partendo dallo slackbuild di che volkerding ha
predisposto per la slackware 12.1. Mi sono limitato a cambiare la
versione nello script che era per openvpn-2.0.9.
Sembra andato tutto liscio e ho fatto l'upgrade del pacchetto.
Posto la configurazione con cui ho fatto la prova:
========================================
# cat /etc/openvpn/StealthyUltraVPN.conf
client
dev tun
proto tcp
hand-window 15
remote-random
remote 87.98.164.142 443
#remote 
stealthy.ultravpn.fr
 443
#remote 
stealthy.ultravpn.net
 443
resolv-retry infinite
nobind
# Try to preserve some state across restarts.
persist-key
persist-tun
ca /etc/openvpn/UltraVPN.crt
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
# Set log file verbosity.
verb 3
auth-user-pass
auth-nocache
# execute scripts at up and down
#up /etc/openvpn/up.sh
#down /etc/openvpn/down.sh
==========================
Ed ecco il log:
================================================================
Tue Oct 13 11:42:53 2009 [ludwig] Peer Connection Initiated with
87.98.164.142:443
Tue Oct 13 11:42:56 2009 SENT CONTROL [ludwig]: 'PUSH_REQUEST'
(status=1)
Tue Oct 13 11:42:57 2009 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
208.67.222.222,dhcp-option DNS 208.67.220.220,route
10.7.0.1,topology net30,ping 10,ping-restart 120,ifconfig
10.7.51.246 10.7.51.245' 
Tue Oct 13 11:42:57 2009 OPTIONS IMPORT: timers and/or timeouts
modified
Tue Oct 13 11:42:57 2009 OPTIONS IMPORT: --ifconfig/up options
modified
Tue Oct 13 11:42:57 2009 OPTIONS IMPORT: route options modified
Tue Oct 13 11:42:57 2009 OPTIONS IMPORT: --ip-win32 and/or
--dhcp-option options modified
Tue Oct 13 11:42:57 2009 ROUTE: default_gateway=UNDEF
Tue Oct 13 11:42:57 2009 TUN/TAP device tun0 opened
Tue Oct 13 11:42:57 2009 TUN/TAP TX queue length set to 100
Tue Oct 13 11:42:57 2009 /sbin/ifconfig tun0 10.7.51.246
pointopoint 10.7.51.245 mtu 1500
Tue Oct 13 11:42:57 2009 NOTE: unable to redirect default gateway
-- Cannot read current default gateway from system
Tue Oct 13 11:42:57 2009 /sbin/route add -net 10.7.0.1 netmask
255.255.255.255 gw 10.7.51.245
Tue Oct 13 11:42:57 2009 Initialization Sequence Completed
==========================================================
In pratica, non ottengo pi� gli errori di prima inerenti alcune
opzioni come il redirect-gateway che con questa versione del
software sembrano bene accette.
Tuttavia non avviene l'instradamento del traffico in modo
automatico verso la vpn.
E compare la sospetta nota:
"NOTE: unable to redirect default gateway -- Cannot read current
default gateway from system"
Penso proprio che il problema stia l�, ma non ne conosco le
cause. In rete ho visto che questo monito viene riscontrato anche
da altri, ma non ho capito molto sinceramente.
Mi viene in mente che mi sono scordato di postare anche le altre
info...e ora ho staccato la vpn...va b�, riattacco e posto
ifconfig e il solito "ip route show". Cambieranno gli indirizzi
ovviamente ma pazienza:
==================
# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.212.112.167  P-t-P:10.6.6.6  Mask:255.255.255.255
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-
                                                             00-00-00-00
          inet addr:10.7.51.246  P-t-P:10.7.51.245  Mask:255.255.255.255
# ip route show
10.7.0.1 via 10.7.51.245 dev tun0
10.7.51.245 dev tun0  proto kernel  scope link  src 10.7.51.246
10.6.6.6 dev ppp0  proto kernel  scope link  src 10.212.112.167
127.0.0.0/8
 dev lo  scope link
default dev ppp0  scope link
============================
Si vede come il default resti verso ppp0.
Insomma anche la versione nuova fa i capricci, almeno con
la configurazione che ho utilizzato

 da altri, ma non ho capito molto sinceramente.
Prova ad aumentare il livello di verbosita' nella configurazione, ad esempio 
con  "verb 6", e poi posta il log.

 esempio con  "verb 6", e poi posta il log.
Il suggerimento di cui sopra rimane valido, comunque penso di avere capito 
dove sta il problema. Guarda la tabella di routing che hai postato 
precedentemente:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
10.7.0.1        10.7.51.245     255.255.255.255 UGH   0      0        0 tun0
10.7.51.245     *               255.255.255.255 UH    0      0        0 tun0
10.6.6.6        *               255.255.255.255 UH    0      0        0 ppp0
loopback        *               255.0.0.0       U     0      0        0 lo
default         *               0.0.0.0         U     0      0        0 ppp0
E nota che i flag per "default" sono "U" solamente, non "UG" come accade di 
solito. Infatti la colonna "Gateway" e' vuota. E questo e' confermato anche 
dall'output del comando "IP route show" che avevi postato precedentemente:
default dev ppp0  scope link
Il che funziona perche' e' un link point to point, ma probabilmente confonde 
OpenVPN. Il mio sospetto e' che OpenVPN per riconoscere la route di default 
cerchi una riga che abbia una default route con device E gateway. Non 
trovandola, fallisce.
Posso pensare a due possibili metodi per provare a risolvere:
- (non sono sicuro che risolva) Compila OpenVPN col supporto per iproute2 
anziche' per i vecchi comandi ifconfig, route etc. Per fare questo, devi 
passare --enable-iproute2 allo script di configurazione ("configure") prima 
di compilare. In questo modo OpenVPN usera' il comando "ip" per le 
configurazioni anziche' i vecchi "route" e "ifconfig". Come detto, non sono 
sicuro che comunque cio' risolva.
- (piu' probabile che risolva) Vai a vedere negli script che tirano su 
l'interfaccia ppp0 (presumibilmente if-up.sh) e cerca il comando che viene 
usato per aggiungere la route di default (se c'e'). Intervenendo su quello 
dovrebbe essere possibile fargli creare la route in un formato "buono" per 
OpenVPN (ossia con l'indirizzo del gateway).

 gateway. Non trovandola, fallisce.
Ok mi sono deciso a googlare un po', e sembra che il problema sia proprio 
quello:
http://readlist.com/lists/lists.sourceforge.net/openvpn-users/2/11019.html
E la soluzione non sembra semplice. Confermo il mio suggerimento di 
"hackare" lo script che tira su l'interfaccia ppp0 per fargli creare una 
route col gateway.

 OpenVPN (ossia con l'indirizzo del gateway).
Nel caso dell'interfaccia ppp0 utilizzo due script, uno per la
inizializzazione del modem (nientaltro che uno script di chat) e
uno script di connessione per il demone pppd. Questo secondo
script richiama il primo al suo interno.
Il comando che utilizzo per connettermi �:
pppd call $pppdscript
dove pppdscript � lo script utilizzato.
Gi� che ci sono lo posto:
-----------------
/dev/rfcomm0 9600
connect '/usr/sbin/chat -v -f /etc/ppp/init.chat'
noauth
defaultroute
novj
novjccomp
mru 1500
mtu 1500
debug
-----
Quello che conta ai fini del routing penso sia unicamente
l'opzione "defaultroute" che se non ricordo male serve proprio
per creare un'instraddamento di defalut. Non chiedermi come
questo venga creato per�, perch� lo ignoro sinceramente.
Tuttavia, volendo si potrebbe ommettere quella opzione e lasciare
che pppd connetta solamente ad internet e tiri s� l'interfaccia
ppp0, ma senza creare la route di default.
Lo script /etc/ppp/ip-up potrebbe poi essere il posto giusto per
indicare il giusto comando per aggiungere la route di default
verso ppp0.
Forse se ormai ho inizio a capire il meccanismo potrebbe bastare
un:
ip route add default dev ppp0
Mettendo appunto questa riga nello script "ip-up" forse si
ottiene il risultato esiderato.
Spero di essermi spiegato e ti chiedo una conferma, intanto
provo.

 ottiene il risultato esiderato.
Hai capito bene. Solo che la riga deve essere
ip route add default dev ppp0 via 10.6.6.6
Quando ppp0 e' up con quest nuove impostazioni, posta l'output di "route" e 
di "ip route show". Se l'output di "route" ha il flag UG e/o "ip route show" 
mostra un gateway ("via 10.6.6.6"), dovremmo esserci. A quel punto riprova a 
lanciare il client OpenVPN (senza usare gli script up.sh e down.sh) e vedi 
come va.

> Al file di configurazione sia superfluo.
Scusa ho capito male io. Si', nel TUO file di configurazione e' inutile, 
visto che gia' te la manda il server.

 ottiene il risultato esiderato.
Ho provato:
mettendo nello script ip-up il comando sopra, non si ottiene
nulla di diverso, per� successivamente ho provato a pasticciare
un po', per fare qualche tentativo da ignorante in materia.
Posto un pezzo di shell:
============
# ip route del default
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref Use Iface
10.7.0.1        10.7.51.245     255.255.255.255 UGH   0      0   0 tun0
10.7.51.245     *               255.255.255.255 UH    0      0   0 tun0
10.6.6.6        *               255.255.255.255 UH    0      0   0 ppp0
loopback        *               255.0.0.0       U     0      0   0 lo
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref Use Iface
10.6.6.6        *               255.255.255.255 UH    0      0   0 ppp0
loopback        *               255.0.0.0       U     0      0   0 lo
# ip route add default gw via 10.6.6.6 ppp0
Error: either "to" is duplicate, or "gw" is a garbage.
# ip route add default via 10.6.6.6 ppp0
Error: either "to" is duplicate, or "ppp0" is a garbage.
# ip route add default via 10.6.6.6
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref Use Iface
10.6.6.6        *               255.255.255.255 UH    0      0 0 ppp0
loopback        *               255.0.0.0       U     0      0 0 lo
default         10.6.6.6        0.0.0.0         UG    0      0 0 ppp0
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref Use Iface
10.7.0.1        10.7.51.245     255.255.255.255 UGH   0      0 0 tun0
r28200.ovh.net
  10.6.6.6        255.255.255.255 UGH   0      0 0 ppp0
10.7.51.245     *               255.255.255.255 UH    0      0 0 tun0
10.6.6.6        *               255.255.255.255 UH    0      0 0 ppp0
loopback        *               255.0.0.0       U     0      0 0 lo
default         10.7.51.245     128.0.0.0       UG    0      0 0 tun0
128.0.0.0       10.7.51.245     128.0.0.0       UG    0      0 0 tun0
default         10.6.6.6        0.0.0.0         UG    0      0 0 ppp0
=====================================================================
Che cosa ho fatto:
- ho modificato llo script di connessione di pppd togliendo
  "defaultroute". Ho poi editato lo script da eseguire a
  connessione avviata ip-up aggiungendo il comando accennato nel
  mio post precedente.
- ho poi notato che non cambiava nulla rispetto a prima cio�
  nella tabella di routing non compariva alcun gateway esplicito.
  Inoltre openvpn non riusciva, come prima, a creare la nuova
  default route.
- Allora ho eliminato la route di default
- Ho spento openvpn e ricontrollato con il comando route, come si
  vede c'� solo ppp0 ma non ho pi� default route. Per la cronaca
  in quella situazione non si riesce neanche a navigare o altro
  via internet.
- Ho poi cercato un modo pi� esplicito per creare una default
  route e mi � parso interessante usare il flag "via" impostato
  sul link remoto 10.6.6.6, infatti ifconfig ricordo che dice:
  ppp0      Link encap:Point-to-Point Protocol  
            inet addr:10.212.88.117  P-t-P:10.6.6.6 Mask:255.255.255.255
 
  Come si vede dai tentativi pasticciati sopra, non conoscevo
  bene il comando giusto e ho ricevuto anche qualche errore, che
  per chi usa abitualmente questi tool sembrer� banale.
  Con un'occhiata pi� attenta al manuale e un po' di fortuna,
  finalmente il comando seguente sembra funzionare:
  ip route add default via 10.6.6.6
- Ho poi controllato la tabella di routing ed in effetti sta
  volta il gateway della defaulroute � esplicitato nell'indirizzo
  10.6.6.6 che rappresenta il link remoto al mio isp.
- Infine con questa situazione ho avviato openvpn, l'ho fatto a
  verbosit� ridotta "1", quindi non sto a postare tanti log,
  magari lo faccio dopo. Dico solo che la nota di prima non c'�
  pi� per cui direi che il server vpn sia riuscito ad indurre il
  mio client a creare la nuova route di default su tun0.
- come si vede sopra ricontrollando la tabella, la situazione
  risulta un po' pi� complessa...non so se � un bene o un male.
  Tuttavia, sembra funzionare e il solito sito mi rivela un ip
  francese.
Come osservazione devo ammettere che adesso la presenza di due
route di default, non saprei cosa comporti.
Un commento chiarificatore � sicuramente gradito.
Da parte mia provo a modificare lo script ip-up e
sconnetto-riconnetto tutto poi magari invio anche il log di
openvpn. Vediamo cosa ne esce.
Grazie ancora per la disponibilit� e chiedo scusa per la
lunghezza!  :-)

 openvpn. Vediamo cosa ne esce.
No, non fare piu' nulla, adesso sei a posto.

 No, non fare piu' nulla, adesso sei a posto.
Lo script /etc/ppp/ip-up � quello che permette di creare la route
di default verso l'interfaccia ppp0.
Se non lo modificassi inserndovi
ip route add default via 10.6.6.6
non posso praticamente pi� utilizzare internet!  ;-)
Forse tu avevi in mente gli scriptini up.sh e down.sh necessari
prima a openvpn...certo quelli non servono pi�...
Anzi forse, visto che ho un'altro problema un po' pi� specifico.
Ma spiego in un nuovo post per chiarezza.
Per quanto riguarda il comando sopra, vedo ora che nel tuo post
precedente mi avevi consigliato un comando simile:
ip route add default dev ppp0 via 10.6.6.6
sono equivalenti penso no?
A meno di non avere l'indirizzo 10.6.6.6 su un'altra interfaccia
di rete...dico bene?

 non posso praticamente più utilizzare internet!  ;-)
Ovvio. No io intendo: tieni lo script ip-up modificato con quella riga e sei 
a posto. Magari usa 
ip route add default dev ppp0 via 10.6.6.6
che e' piu' esplicito.
Ma non toccare piu' nient'altro! :)
In realta' volendo essere pignoli dovresti anche modificare l'if-down per 
eseguire il comando "ip route del" corrispondente. Ma non credo succedera' 
nulla se non lo fai, soprattutto se l'interfaccia ppp0 ce l'hai piu' o meno 
permanente.

 [...]
Vediamo di fare il punto:
--------------------
# cat /etc/ppp/ip-up
#!/bin/bash
export PATH=$PATH:/sbin
ip route add default dev ppp0 via 10.6.6.6
------------------------------------------
file di configurazione di openvpn (client)
------
client
dev tun
proto tcp
hand-window 15
remote-random
remote 
stealthy.ultravpn.fr
 443
remote 
stealthy.ultravpn.net
 443
resolv-retry infinite
nobind
# Try to preserve some state across restarts.
persist-key
persist-tun
ca /etc/openvpn/UltraVPN.crt
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
# Set log file verbosity.
verb 3
auth-user-pass
--------------
Log di connessione alla vpn:
----------------------------
Tue Oct 13 17:43:03 2009 [ludwig] Peer Connection Initiated with
87.98.173.225:443
Tue Oct 13 17:43:05 2009 SENT CONTROL [ludwig]: 'PUSH_REQUEST'
(status=1)
Tue Oct 13 17:43:06 2009 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS
94.23.39.201,dhcp-option DNS 213.251.133.164,route
10.13.0.1,topology net30,ping 10,ping-restart 120,ifconfig
10.13.150.138 10.13.150.137'
Tue Oct 13 17:43:06 2009 OPTIONS IMPORT: timers and/or timeouts
modified
Tue Oct 13 17:43:06 2009 OPTIONS IMPORT: --ifconfig/up options
modified
Tue Oct 13 17:43:06 2009 OPTIONS IMPORT: route options modified
Tue Oct 13 17:43:06 2009 OPTIONS IMPORT: --ip-win32 and/or
--dhcp-option options modified
Tue Oct 13 17:43:06 2009 ROUTE default_gateway=10.6.6.6
Tue Oct 13 17:43:06 2009 TUN/TAP device tun0 opened
Tue Oct 13 17:43:06 2009 TUN/TAP TX queue length set to 100
Tue Oct 13 17:43:06 2009 /sbin/ip link set dev tun0 up mtu 1500
Tue Oct 13 17:43:06 2009 /sbin/ip addr add dev tun0 local
10.13.150.138 peer 10.13.150.137
Tue Oct 13 17:43:06 2009 /sbin/ip route add 
87.98.173.225/32
 via
10.6.6.6
Tue Oct 13 17:43:06 2009 /sbin/ip route add 
0.0.0.0/1
 via
10.13.150.137
Tue Oct 13 17:43:06 2009 /sbin/ip route add 
128.0.0.0/1
 via
10.13.150.137
Tue Oct 13 17:43:06 2009 /sbin/ip route add 
10.13.0.1/32
 via
10.13.150.137
Tue Oct 13 17:43:06 2009 Initialization Sequence Completed
----------------------------------------------------------
Ed infine:
-------
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref Use Iface
10.13.150.137   *               255.255.255.255 UH    0      0   0   tun0
r24550.ovh.net
  10.6.6.6        255.255.255.255 UGH   0      0   0   ppp0
10.13.0.1       10.13.150.137   255.255.255.255 UGH   0      0   0   tun0
10.6.6.6        *               255.255.255.255 UH    0      0   0   ppp0
loopback        *               255.0.0.0       U     0      0   0   lo
default         10.13.150.137   128.0.0.0       UG    0      0   0   tun0
128.0.0.0       10.13.150.137   128.0.0.0       UG    0      0   0   tun0
default         10.6.6.6        0.0.0.0         UG    0      0   0   ppp0
# ip route show
10.13.150.137 dev tun0  proto kernel  scope link  src 10.13.150.138 
87.98.173.225 via 10.6.6.6 dev ppp0 
10.13.0.1 via 10.13.150.137 dev tun0 
10.6.6.6 dev ppp0  proto kernel  scope link  src 10.212.112.154 
127.0.0.0/8
 dev lo  scope link 
0.0.0.0/1
 via 10.13.150.137 dev tun0 
128.0.0.0/1
 via 10.13.150.137 dev tun0 
default via 10.6.6.6 dev ppp0 
-----------------------------
Quindi � tutto apposto, funziona tutto ecc ecc.
Anche se riguardando l'output di "ip route show", noto che il
default � rilevato su ppp0 attraverso l'indirizzo 10.6.6.6 ...
Quando invece mi aspetterei di trovarlo su tun0 ecc.
Tuttavia ho riscontrato che efettivamente mi presento con l'ip
francese.
Probabilmente � dovuto, come spiegavi prima, alla sovrapposizione
del default (grazie al flag "def1" dell'opzione redirect-gateway,
attiva lato server)...
Infatti dovrebbe essere questo il punto che indica il fatto che
il default attivo � in ralt� tun0:
0.0.0.0/1
 via 10.13.150.137 dev tun0
Nel prossimo post, cercher� di spiegare il problema che ancora
dovrei risolvere, pi� che altro per ottenere una situazione pi�
comoda....
Alla prossima. E grazie mille di cuore per tutto l'aiuto.  :-)

 
0.0.0.0/1
 via 10.13.150.137 dev tun0
Sono due. Quella e
128.0.0.0/1
 via 10.13.150.137 dev tun0 
sono due route che assieme coprono l'intero spazio di indirizzamento IP.
Nessuna delle due e' "default" nel senso classico del termine, ma messe 
assieme "sono come" avere una route di default.
Con la route verso 
0.0.0.0/1
 raggiungi tutti gli indirizzi IP fino a 
127.255.255.255, con la route verso 
128.0.0.0/1
 raggiungi tutti gli IP da 
128.0.0.0 a 255.255.255.255. (questo ovviamente in via teorica, visto che 
molti di quegli indirizzi non sono validi o non sono usati; l'importante e' 
il concetto che *assieme* le due route coprono l'intero spazio IPv4)
Leggi qualcosa riguardo agli indirizzi IP e subnet mask per maggiori 
informazioni.

 permanente.
...E qui casca l'asino..  :-D
Ecco, mi ricollego a questo post, visto che hai toccato il problema.
La mia beata connessione ha la scomoda abitudine di cadere
sistematicamente ogni 30 minuti (cos� ha deciso l'isp).
Quindi ogni 30 minuti devo riconnettermi. Per il momento
immaginiamo di effettuare a mano questa operazione:
circa ogni 30 minuti la connessione cade e manualmente quando mi
serve la ripristino.
Fin qui nulla di strano.
Ma se volessi tenere in piedi anche la vpn? � scomodo ogni volta
tirare su la connessione e poi riaccendere il tunnel vpn.
Mi chiedevo se fosse possibile fare in modo che il client openvpn
riagganciasse automaticamente il tunnel quando la connessione al
mio isp torna in piedi.
Vedo dal log che vengono eseguiti dei ritentativi nel caso in cui
(mi pare) il server vpn non risponda ad un ping di controllo
settato ad un certo intervallo temporale.
Per� ho constatato che questi ritentativi non vanno a buon fine
anche se la connessione � di nuovo in piedi.
Forse che sia nuovamente un problema di instradamento?
Magari dovuto alla assenza del comando appropriato nello script
ip-down....di cui accennavi poco sopra?
In pratica vorrei:
- connettermi a ppp0
- accendere il tunell ed instradare tutto su tun0
- Cade la linea, quindi non ho pi� ppp0
- riconnetto portando in piedi ppp0
- vorrei che il tunnel funzionasse di nuovo senza dover fermare e
  riavviare openvpn. Se p� fa?

   riavviare openvpn. Se pò fa?
In teoria penso di si' (anche se, ripeto, il problema e' a monte), ma 
bisogna vedere nei dettagli cosa accade esattamente quando va giu' la 
connessione ppp. Se non risolvi in altro modo (vedi sopra), posta il log di 
OpenVPN quando la connessione va via (magari con verb 4).

 OpenVPN quando la connessione va via (magari con verb 4).
Va bene, dopo faccio una prova simulando una disconnessione,
imposto gi� ora il log di openvpn a verb 4.
Va detto che trovare la giusta combinazione per tenere in piedi
automaticamente openvpn, non � molto utile solo a causa delle
politiche di gestione del mio isp. � anche necessario qualora si
volesse predisporre una postazione non presidiata che f�
"lavoretti" via internet. Connessioni come la mia ma anche via
56k o altre soluzioni su rete mobile, sono caratterizzate da una
certa instabilit� e se non si � davanti al monitor, capire come
automatizzare la riconnessione dei servizi necessari �
sicuramente un must.
A presto.  :-)

 imposto gi� ora il log di openvpn a verb 4.
Ho connesso, avviato openvpn in verbosit� 4 e disconnesso la
ppp0.
Qu� c'� l'ora in cui ho disconnesso
-----------------------------------------------------------
Oct 14 14:57:52 slack-12 pppd[16617]: Connection terminated.
Oct 14 14:57:52 slack-12 pppd[16617]: Exit.
-------------------------------------------
Lascio che il log di oenvpn si riempia un po' di messaggi e poi
riconnetto:
--------------------------------------------------------------------
Oct 14 15:02:04 slack-12 pppd[28799]: Connect: ppp0 <-->/dev/rfcomm0
Oct 14 15:02:05 slack-12 pppd[28799]: local  IP address 10.212.x.x
Oct 14 15:02:05 slack-12 pppd[28799]: remote IP address 10.6.6.6
----------------------------------------------------------------
Nel frattempo vediamo cosa ha scritto il log di openvpn dalla
prima connessione in poi....� molto lingo ovviamente:
----------------------------------------------------------
Wed Oct 14 14:55:33 2009 us=196113 Initialization Sequence
Completed
---------
=========================================================
              Disconnessione alle 14:57:52
=========================================================
--------------------------------------------------------------
Wed Oct 14 14:59:50 2009 us=762142 [ludwig] Inactivity timeout
(--ping-restart), restarting
Wed Oct 14 14:59:50 2009 us=762577 TCP/UDP: Closing socket
Wed Oct 14 14:59:50 2009 us=762678 SIGUSR1[soft,ping-restart]
received, process restarting
Wed Oct 14 14:59:50 2009 us=762731 Restart pause, 5 second(s)
Wed Oct 14 14:59:55 2009 us=763134 WARNING: No server certificate
verification method has been enabled.  See
http://openvpn.net/howto.html#mitm
 for more info.
Wed Oct 14 14:59:55 2009 us=763209 NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or
executables
Wed Oct 14 14:59:55 2009 us=763279 Re-using SSL/TLS context
Wed Oct 14 14:59:55 2009 us=763357 LZO compression initialized
Wed Oct 14 14:59:55 2009 us=763513 Control Channel MTU parms [
L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 14 14:59:55 2009 us=764254 Data Channel MTU parms [
L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 14 14:59:55 2009 us=764357 Local Options String:
'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize
128,key-method 2,tls-client'
Wed Oct 14 14:59:55 2009 us=764393 Expected Remote Options
String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize
128,key-method 2,tls-server'
Wed Oct 14 14:59:55 2009 us=764467 Local Options hash (VER=V4):
'69109d17'
Wed Oct 14 14:59:55 2009 us=764528 Expected Remote Options hash
(VER=V4): 'c0103fa8'
Wed Oct 14 14:59:55 2009 us=764582 Attempting to establish TCP
connection with 
87.98.164.142:443
 [nonblock]
Wed Oct 14 15:00:05 2009 us=774175 TCP: connect to
87.98.164.142:443
 failed, will try again in 5 seconds: Connection
timed out
Wed Oct 14 15:00:05 2009 us=774404 SIGUSR1[soft,init_instance]
received, process restarting
Wed Oct 14 15:00:05 2009 us=774467 Restart pause, 5 second(s)
Wed Oct 14 15:00:10 2009 us=775129 WARNING: No server certificate
verification method has been enabled.  See
http://openvpn.net/howto.html#mitm
 for more info.
Wed Oct 14 15:00:10 2009 us=775205 NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or
executables
Wed Oct 14 15:00:10 2009 us=775269 Re-using SSL/TLS context
Wed Oct 14 15:00:10 2009 us=775304 LZO compression initialized
Wed Oct 14 15:00:10 2009 us=775419 Control Channel MTU parms [
L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 14 15:00:45 2009 us=776188 RESOLVE: Cannot resolve host
address: 
stealthy.ultravpn.net
: [TRY_AGAIN] A temporary error
occurred on an authoritative name server.
Wed Oct 14 15:00:45 2009 us=776264 Data Channel MTU parms [
L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
[...]
=============================================
Questo per darti un'idea.
Ma direi che viene troppo lunga postare qui tutto il log.
Potremmo parlarne via mail, cio� magari ti mando il log via mail
e quello che ritieni importande lo postiamo poi anche qua...cosa
ne pensi?
Se invece gi� dal log sopra vedi cosa pu� eserci che non v� dimmi
pure, anche se il pezzo cruciale � quello dopo quando riconnetto
ad internet.

 Ma direi che viene troppo lunga postare qui tutto il log.
No posta pure. Tra l'altro hai omesso la parte piu' importante, che e' il 
log nel momento in cui ppp0 viene riconnessa.
Posta TUTTO il log, da qualche momento prima di disconnettere ppp0, fino a 
un po' dopo che l'hai riconnessa.

 un po' dopo che l'hai riconnessa.
Allora, il pezzo fino a poco dopo la disconnessione l'ho gi�
postato. Il seguente � quello relativo alla riconnessione
avvenuta alle 15:02 circa, come vedi anche dal post precedente.
---------------
Wed Oct 14 15:02:50 2009 us=792524 Restart pause, 5 second(s)
Wed Oct 14 15:02:55 2009 us=793141 WARNING: No server certificate
verification method has been enabled.  See 
http://openvpn.net
/howto.html#mitm for more info.
Wed Oct 14 15:02:55 2009 us=793234 NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or e
xecutables
Wed Oct 14 15:02:55 2009 us=793306 Re-using SSL/TLS context
Wed Oct 14 15:02:55 2009 us=793353 LZO compression initialized
Wed Oct 14 15:02:55 2009 us=793516 Control Channel MTU parms [
L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 14 15:02:55 2009 us=794490 Data Channel MTU parms [
L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 14 15:02:55 2009 us=794602 Local Options String:
'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_CLIENT,comp-lz
o,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Oct 14 15:02:55 2009 us=794635 Expected Remote Options
String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_SERV
ER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method
2,tls-server'
Wed Oct 14 15:02:55 2009 us=794684 Local Options hash (VER=V4):
'69109d17'
Wed Oct 14 15:02:55 2009 us=794728 Expected Remote Options hash
(VER=V4): 'c0103fa8'
Wed Oct 14 15:02:55 2009 us=794769 Attempting to establish TCP
connection with 
87.98.164.142:443
 [nonblock]
Wed Oct 14 15:03:05 2009 us=804154 TCP: connect to
87.98.164.142:443
 failed, will try again in 5 seconds: Connection
timed out
Wed Oct 14 15:03:05 2009 us=804358 SIGUSR1[soft,init_instance]
received, process restarting
Wed Oct 14 15:03:05 2009 us=804413 Restart pause, 5 second(s)
Wed Oct 14 15:03:10 2009 us=805130 WARNING: No server certificate
verification method has been enabled.  See 
http://openvpn.net
/howto.html#mitm for more info.
Wed Oct 14 15:03:10 2009 us=805206 NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or e
xecutables
Wed Oct 14 15:03:10 2009 us=805277 Re-using SSL/TLS context
Wed Oct 14 15:03:10 2009 us=805327 LZO compression initialized
Wed Oct 14 15:03:10 2009 us=805462 Control Channel MTU parms [
L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 14 15:03:45 2009 us=806165 RESOLVE: Cannot resolve host
address: 
stealthy.ultravpn.net
: [TRY_AGAIN] A temporary error o
ccurred on an authoritative name server.
Wed Oct 14 15:03:45 2009 us=806250 Data Channel MTU parms [
L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 14 15:03:45 2009 us=806346 Local Options String:
'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_CLIENT,comp-lz
o,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Oct 14 15:03:45 2009 us=806388 Expected Remote Options
String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_SERV
ER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method
2,tls-server'
Wed Oct 14 15:03:45 2009 us=806461 Local Options hash (VER=V4):
'69109d17'
Wed Oct 14 15:03:45 2009 us=806528 Expected Remote Options hash
(VER=V4): 'c0103fa8'
Wed Oct 14 15:04:20 2009 us=807166 RESOLVE: Cannot resolve host
address: 
stealthy.ultravpn.net
: [TRY_AGAIN] A temporary error o
Wed Oct 14 15:04:20 2009 us=807338 TCP/UDP: Closing socket
Wed Oct 14 15:04:20 2009 us=807456 SIGUSR1[soft,init_instance]
received, process restarting
Wed Oct 14 15:04:20 2009 us=807514 Restart pause, 5 second(s)
Wed Oct 14 15:04:25 2009 us=808134 WARNING: No server certificate
verification method has been enabled.  See 
http://openvpn.net
/howto.html#mitm for more info.
Wed Oct 14 15:04:25 2009 us=808211 NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or e
xecutables
Wed Oct 14 15:04:25 2009 us=808282 Re-using SSL/TLS context
Wed Oct 14 15:04:25 2009 us=808329 LZO compression initialized
Wed Oct 14 15:04:25 2009 us=808494 Control Channel MTU parms [
L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 14 15:04:25 2009 us=809693 Data Channel MTU parms [
L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 14 15:04:25 2009 us=809800 Local Options String:
'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_CLIENT,comp-lz
o,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Oct 14 15:04:25 2009 us=809842 Expected Remote Options
String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_SERV
ER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method
2,tls-server'
Wed Oct 14 15:04:25 2009 us=809911 Local Options hash (VER=V4):
'69109d17'
Wed Oct 14 15:04:25 2009 us=809974 Expected Remote Options hash
(VER=V4): 'c0103fa8'
Wed Oct 14 15:04:25 2009 us=810026 Attempting to establish TCP
connection with 
87.98.164.142:443
 [nonblock]
Wed Oct 14 15:04:35 2009 us=820152 TCP: connect to
87.98.164.142:443
 failed, will try again in 5 seconds: Connection
timed out
Wed Oct 14 15:04:35 2009 us=820348 SIGUSR1[soft,init_instance]
received, process restarting
Wed Oct 14 15:04:35 2009 us=820389 Restart pause, 5 second(s)
Wed Oct 14 15:04:40 2009 us=821133 WARNING: No server certificate
verification method has been enabled.  See 
http://openvpn.net
/howto.html#mitm for more info.
Wed Oct 14 15:04:40 2009 us=821204 NOTE: OpenVPN 2.1 requires
'--script-security 2' or higher to call user-defined scripts or e
xecutables
Wed Oct 14 15:04:40 2009 us=821257 Re-using SSL/TLS context
Wed Oct 14 15:04:40 2009 us=821291 LZO compression initialized
Wed Oct 14 15:04:40 2009 us=821407 Control Channel MTU parms [
L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Oct 14 15:05:15 2009 us=822208 RESOLVE: Cannot resolve host
address: 
stealthy.ultravpn.net
: [TRY_AGAIN] A temporary error o
ccurred on an authoritative name server.
Wed Oct 14 15:05:15 2009 us=822318 Data Channel MTU parms [
L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Oct 14 15:05:15 2009 us=822420 Local Options String:
'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_CLIENT,comp-lz
o,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Oct 14 15:05:15 2009 us=822464 Expected Remote Options
String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
TCPv4_SERV
ER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method
2,tls-server'
Wed Oct 14 15:05:15 2009 us=822539 Local Options hash (VER=V4):
'69109d17'
----------
Spero sia abbastanza per capire qualcosa di pi�...
Eventualmente fammi sapere.

 ccurred on an authoritative name server.
A causa del ping-restart, lui tenta nuovamente di risolvere il nome. Qui 
c'e' chiaramente un problema di DNS (e anche se non so come lo gestisci, 
sospetto casini anche li', ma non sono interessato). 
Il workaround terribile e' usare
persist-remote-ip
e 
resolv-retry 0
nella configurazione di OpenVPN in modo che lui non provi piu' a risolvere 
il nome del server.
Ma e' appunto un workaround. Potrebbe funzionare, ma visto che sei in una 
situazione che con un eufemismo si potrebbe definire "anomala", non penso 
che tu possa aspettarti che le cose funzionino tutte sempre come 
funzionerebbero in una situazione "normale". Se non vuoi problemi, fatti una 
connessione Internet stabile.

 Se non vuoi problemi, fatti una connessione Internet stabile.
Fosse cos� semplice...
Devo ammettere che la connessione via cell con offerte ordinarie
per utilizzo da PC (che quindi non hanno a che fare col wap) �
molto meno problematica. Solo che la mancanza di un buon piano a
buon mercato mi ha indotto a tappare i buchi con soluzioni
incasinate come questa.
D'altra parte non ho molte alternative visto che non sono coperto
da servizi decenti.
B� poi faccio sapere come sono andate le ulteriori prove.

 Ok dopo li provo.
Niente, non cambia nulla.
Cio�, non si riconnette automaticamente.
Mi sta venendo voglia di avviare openvpn alla connessione ad
internet e killarlo alla disconnessione.
In una situazione come quella sarebbe utile l'opzione --daemon,
ma c'� il problema della autenticazione che non viene richiesta
se il programma gira come demone (e giustamente)... Per� in
qualche modo il login lo devo fare.
A questo proposito ho visto l'opzione:
auth-user-pass [up]
dove [up] � un file contenente user e password su due righe
distinte.
Ho cos� provato, ma mi d� errore dicendo che bisogna configurare
il programma in fase di compilazione passando al configure una
particolare opzione che ora ho gi� scordato...va b�.
Non c'� qualche altro metodo tipo con certificati, che sappiate?
Ricordo che io uso utilizzo gi� un certificato scaricato insieme
al file di configurazione che proponeva ultravpn.
So che se si ha accesso al server vpn come admin � possibile
creare chiave privata e pubblica ed esportarla sul client...ma in
questo caso...non so. In rete non ho trovato granch� almeno nel
caso di ultravpn.
Avete qualche consiglio a portata di mano?