Openvpn - utenti rimangono appesi

Programmazione e Server Server
#1

Salve volevo chiedere se con OpenVPN 2.1.1 x86_64-redhat-linux-gnu qualcuno ha avuto il problma con l’interfaccia management cosi:

  1. Il client si disconnette con

Tue Dec 28 23:11:10 2010 TCP/UDP: Closing socket
Tue Dec 28 23:11:10 2010 C:\WINDOWS\system32\route.exe DELETE 10.8.0.0 MASK 255.255.255.0 10.8.0.13
Tue Dec 28 23:11:10 2010 Route deletion via IPAPI succeeded [adaptive]
Tue Dec 28 23:11:10 2010 C:\WINDOWS\system32\route.exe DELETE 192.168.9.0 MASK 255.255.255.0 10.8.0.13
Tue Dec 28 23:11:10 2010 Route deletion via IPAPI succeeded [adaptive]
Tue Dec 28 23:11:10 2010 Closing TUN/TAP interface
Tue Dec 28 23:11:10 2010 SIGTERM[hard,] received, process exiting
2) Il server gli risponde (o non gli risponde così)

Inactivity timeout (–ping-restart), restarting
SIGUSR1[soft,pin$oft,ping-restart] received, client-instance

In pratica i client, anche se si disconnettono, rimangono per tutti i programmi di controllo ancora collegati fino a che mi pare di capire il ping keepalive li sbatte fuori per inattività.
P.S. Fatemi sapere se avete bisogno dei file di configurazione per il server e per il client.
E non è molto elegante per chi come me deve controllare se le ragazze stanno lavorando o no. Mi pare strano che si siano messi tutti a fare gli straordinari.
Grazie in anticipo.

#2

Puoi settare lato client delle forzature sull’inattività dell’interfaccia TUN in modo da disconnettere forzatamente la connessione. Dal man di openvpn ho trovato questo:

--inactive n
    (Experimental) Causes OpenVPN to exit after n seconds of inactivity on the TUN/TAP device. 
The time length of inactivity is measured since the last incoming tunnel packet. 

--ping n
    Ping remote over the TCP/UDP control channel if no packets have been sent for at least n seconds 
(specify --ping on both peers to cause ping packets to be sent in both directions since OpenVPN ping packets are not echoed like IP ping packets). 
When used in one of OpenVPN's secure modes (where --secret, --tls-server, or --tls-client is specified), the ping packet will be cryptographically secure.

    This option has two intended uses:

    (1) Compatibility with stateful firewalls. The periodic ping will ensure that a stateful firewall rule 
which allows OpenVPN UDP packets to pass will not time out.

    (2) To provide a basis for the remote to test the existence of its peer using the --ping-exit option.
--ping-exit n
    Causes OpenVPN to exit after n seconds pass without reception of a ping or other packet from remote. 
This option can be combined with --inactive, --ping, and --ping-exit to create a two-tiered inactivity disconnect.

    For example,

    openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60

    when used on both peers will cause OpenVPN to exit within 60 seconds if its peer disconnects, but will exit after one hour if no actual tunnel data is exchanged.

Nella configurazione del server o client è settato magari il parametro --ping-restart?

#3

Io avevo impostato la strategia sul lato server così e credo a questo punto sia lì il problema:

The keepalive directive causes ping-like

messages to be sent back and forth over

the link so that each side knows when

the other side has gone down.

Ping every 10 seconds, assume that remote

peer is down if no ping received during

a 120 second time period.

keepalive 10 120

Su man openvpn le istruzioni sono queste:
–keepalive n m
A helper directive designed to simplify the expression of --ping
and --ping-restart in server mode configurations.

For example, --keepalive 10 60 expands as follows:

if mode server:
ping 10
ping-restart 120
push “ping 10”
push “ping-restart 60”
else
ping 10
ping-restart 60

E la questione è talmente “simplified” che mia ha nascosto un ping restart. Concordi?

#4

Io ho pensato al problema perché nel messaggio ti indica proprio la voce restart, quindi potrebbe essere quello il problema.
A mio parare il ping-restart serve per brevi disconnessioni e per limitare i problemi nel caso ci siano script che aprono connessione VPN automatiche e che durano molto tempo. Ma nel tuo caso sembra che sia persone che da casa si collegano al lavoro e quindi una persona esegue la connessione manualmente. Sarebbe utile sostituire il ping-restart con ping-exit mettendo magari il tiemout a 10 minuti

Che ne pensi? E’ un test fattibile?

#5

Questasera provo a cambiare uno script di una ragazza per test e poi ti dico.
Intanto una domanda di teoria generale per darmi una ragione. Il fatto che un programma come openvpn debba utilizzare un ping per sapere se una persona è connessa o no deriva per caso dal’utilizzo del protocollo UDP rispetto ad TCP? Effettivamente le porte UDP dovrebbero essere stateless, percui se interrogo il socket non vedo le porte della VPN CONNECTED ma LISTENING anche se effettivamente sono usate. Non essendoci la conferma ack e tutto il protocollo TCP il server è costretto ad usare ping. Può essere una spiegazione plausibile?

#6

A logica UDP come dici tu è stateless quindi ha bisogno di simulare del traffico per verificare che il canale sia aperto, quindi in teoria ti direi proprio di si.

#7

Quindi se sul lato server metto TCP come modalità di ascolto dovrebbe essere preciso negli attacchi e distacchi degli utenti perché (spero) il programma non deve come dici simulare ma /spero) si vada a vedere lo stato della porta a livello di protocollo alto TCP.
Ti dico questo perché nella valutazione costi/benefici, il ping-restart a leggere man dovrebbe servire nei casi in cui i client hanno IP dinamici. E le ragazze ce lo hanno.
Quindi

  1. Potrebbe essere una soluzione lasciare tutto così e cambiare solo il protocollo da TCP ad UDP?
  2. Quali sono i motivi per utilizzare UDP per default e non TCP in una cosa così delicata come VPN?
  3. E ancora. Quali sono i contro di usare TCP?
#8

Guarda io ti dico che ho sempre configurato nei miei test in TCP e funziona correttamente. Questo comportamento è la prima volta che capita e ci sono dei test da fare.
Per prima cosa la differenza sostanziale tra TCP ed UDP è il fatto che UDP è molto più veloce ed è molto meno pesante dal punto di vista del traffico perché TCP utilizza l’ack, ma i contro sono legato al fatto di poter perdere pacchetti. Il TCP quindi è più sicuro ed introduce il concetto di state quindi è più gestibile dal punto di vista dei controlli.

Secondo me conviene utilizzare tcp come viene fornito di default, perché come canale non mi sembra pesante, e non ti so dire però se i controlli di ping e keepalive sono legati solo a UDP (credo anche per TCP). Non vedo neppure delle controindicazioni per il TCP, anzi puoi verificare molto più agevolmente le sessioni aperte lato client e server.

Ma perché tu hai configurato la connessione in UDP?

Proviamo a lasciare la conf con UDP e modificando il ping-restart con ping-exit e poi verifichiamo con tcp cosa cambia.

#9

Sono rimasto alquanto deluso. Ho messo # su keepalive ed ho impostatola direttiva ping-exit 1, ma il ritardo con cui riconosce la disconnessione è più di un minuto, quindi ne deduco che quel parametro manco lo legge. Comunque almeno adesso su 4 attacchi e destacchi del client, ho avuto successi al 100% sul fatto che il server entro un tempo x che valuto intorno ai 5/6 minuti si accorge che il client non è più collegato.

Credo che alla fine proverò a mettere TCP, anche se credo mi ucciderà la banda. Ma questo solo quando metterò a posto snmp + mrtg su un altro thread di fedoraonline per comparare i due metodi. Infatti i client previsti sono almeno una decina ed ho una banda di upload scarsissima.

Una anomalia. Ho il file log strapieno di righe come questa:

ri Dec 31 20:03:30 2010 us=28037 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:31 2010 us=29987 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:32 2010 us=35058 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:33 2010 us=33133 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:34 2010 us=52322 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:35 2010 us=35149 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:36 2010 us=37037 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:37 2010 us=37955 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:38 2010 us=40030 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:39 2010 us=41129 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:40 2010 us=43081 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:41 2010 us=44029 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:42 2010 us=50928 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:43 2010 us=47032 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:44 2010 us=48055 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:45 2010 us=49981 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:46 2010 us=51060 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:47 2010 us=53040 MANAGEMENT: CMD ‘status 2’
Fri Dec 31 20:03:48 2010 us=54109 MANAGEMENT: CMD ‘status 2’

Può centrare qualche cosa?

#10

Secondo me il TCP è la soluzione migliore anche se la banda è ridotta. Comunque ho cercato un pochino su google e sembrano messaggi normali che sono da considerarsi come notice.

#11

Ho appena finito di configurare il sistema di monitoraggio snmp/mrtg. Lascio udp per due settimane, poi metto TCP per due settimane e ti passo i grafici.