[Ninux-Calabria] CI on e problemi con tunnel

Stefano De Carlo stefanauss a gmail.com
Gio 6 Nov 2014 00:11:14 UTC


Il 05 novembre 2014 23:40, Vincenzo Pirrone <linuspax a gmail.com> ha scritto:
> 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
>

Si, è stato figo e molto NOC Ninuxaro :)
Sprovveduti è una parola grossa, alla fine i problemi che hai elencato
non sono stati causati da un qualche concetto sistemico sfuggito al
radar ma dalle piccole discrepanze tra le configurazioni dei nodi
rispetto a quelle presunte dal NOC, cosa che può capitare in una rete
di 25 nodi realizzati da un team eterogeneo.

Riguardo ai due punti di cui sopra:
* Il NAT a NewSpig serve unicamente a Massimo, ma l'ho applicato al
forwarding sbagliato. My bad, ma a mia discolpa dico che la
documentazione del wiki OpenWrt chiarisce malissimo che il
masquerading va definito sull'interfaccia mascherata e non
mascherante. Come conseguenza tutto il traffico routato da newSpig era
nattato.
* Ogni nuovo nodo rischia di annunciarsi come gw per via
dell'abilitazione di default del plugin dyngw. Dovremo produrre dei
sane defaults per OpenWrt, al momento sono richieste troppe variazioni
manuali.

> 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.
>

Il primissimo dei problemi che abbiamo incontrato è che quando cambi
la awareness del L2 di un nodo, automaticamente invalidi la ARP cache
di almeno tutti i vicini. Ora lo sappiamo, dobbiamo svuotarla come
prima cosa dopo aver operato a L2 (e la CI è indubbiamente
l'intervento più pesante che potevamo fare in proposito).
Purtroppo OpenWrt non sembra avere un meccanismo per farlo. la applet
arp di busybox non ha il flag -d attivato, e la applet ip che noi
siamo costretti ad utilizzare al posto dei binario ip full (altrimenti
non ci sta openvpn-polarssl) non ha il subcommand neigh necessario per
dare

ip neigh flush all

L'unica sembra riavviare, o almeno /etc/init.d/networking restart


>> 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.
>

TODO: Confermare il fix applicando un dirty sleep e poi, se
confermato, cercare se esiste una soluzione più pulita che usi le
facilities di OpenWrt.

>> 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
>

Ok, ma ovviamente deve essere preferibile una soluzione (da trovare)
che eviti il default gw dove non serve e non ha senso, altrimenti si
rischia di immettere nel link wireless del traffico che sicuramente
andrà perso, cosa che sicuramente non aumenta le prestazioni dell'AP a
cui si è collegati.

> 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.
>

da
option local 0.0.0.0
a
option local $openvpnserver_HNA_address

>>
>> 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.
>>

Problema concreto. Figo, poi condividici le tue esperienze sul multihomed.

>
> 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.
>

Infatti, ed è anche un po' contro la logica dei servizi implementati
sugli host interni (aka HNA Networks).

Stefanauss.


Maggiori informazioni sulla lista Calabria