[Ninux-Calabria] CI on e problemi con tunnel

Vincenzo Pirrone linuspax a gmail.com
Mer 5 Nov 2014 22:40:46 UTC


Apro un nuovo thread

Il 05/11/2014 12:52, Giuseppe De Marco ha scritto:
>
> Se hai notato siamo cmq degli animali empirici, pensavamo andasse di
> default invece abbiamo rimosso un NAT a newspig e modificato i default
> gw di tutti i router per fare viaggiare i dati all'interno del tunnel.

Siamo stati un po' sprovveduti, che ci serva di lezione per la prossima
volta. Però è stato figo smazzare insieme i problemi, giustamente siamo
una squadra

Per chi non c'era fisicamente o telefonicamente:
Come preannunciato ieri abbiamo abilitato la CI, operazione eseguita
forse con un po' troppa leggerezza visto che sono sorti subito problemi
con i tunnel.

> I casini li abbiamo notati quando inseriamo un gw che per CI non è
> disponibile in l2, essendo questo un default gw il kernel lo cerca in
> layer2 quindi giunge all' AP che non consente traffico l2 al difuori
> del peer con la station, la connessione non si stabilisce e va in
> timeout.

Ad esempio ecocasa usava come gateway 172.17.87.13 (verde), però con la
CI abilitata questo dava problemi perchè il collegamento con verde ora
avviene tramite routing su NewSpig.

Logicamente la mossa da fare era rimuovere il gateway, ma così facendo
si creano problemi al boot, perchè openvpn sia avvia prima che il router
abbia ricevuto le route da olsr, quindi non trovando la route per il
server vpn termina in errore.

> Che dire, unico default gw deve essere l'unico con il quale funziona
> il layer2, in questo caso l' AP, poi questo trova la strada sia
> dell'andata che del ritorno

In pratica:
ip route get $vpn_server | awk '{print $3;}'
Questo però potrebbe cambiare, la soluzione definitiva sarebbe tardare
l'avvio di openvpn, lasciamo questo trick per le prossime versioni di
NinucsWrt.

Un altro problema l'abbiamo avuto con i nodi che avevano tunnel con
capizzanux. Il server vpn di capizzanux a differenza di quello di verde
sta sul GR. Il server pur venendo contattato sul suo indirizzo interno
10.87.7.1 tendeva a rispondere con l'indirizzo esterno 172.17.87.9, e al
client la cosa non piaceva.
Abbiamo risolto forzando il server vpn a rimanere in ascolto solo su
10.87.7.1.

>
> Su capizzanux che è legacy è stata forzata l'interfaccia operazionale
> di openvpn su 10.87, prima mantenevo openvn server su tutte le
> interfacce perchè, specie ad Agosto, vi accedevo via WAN INTERNET per
> avere routing dentro ninux e per comodità preferivo non specificare.
> Adesso devo pensare ad un multihomed server o un secondo processo, ma
> prima devo completare i lavori del mio nodo.
>

Puoi mantenerlo su tutte le interfacce e impostare i client in modo da
farli connettere all'indirizzo esterno (172.17.87.9).
C'è un problema però se usiamo come endpoint vpn gli indirizzi della
classe 172.17.0.0/16, perchè openvpn assume erroneamente che il server
sia raggiungibile in l2 e si aggiunge una route statica verso l'endpoint.




-- 
Vincenzo Pirrone
Twitter: @spax_arm
PGP Key ID: 5CF5047D

-------------- parte successiva --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20141105/2622651c/attachment.pgp>


Maggiori informazioni sulla lista Calabria