[Ninux-Calabria] CI on e problemi con tunnel

[Giuseppe De Marco]

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

Sappiamo che andava fatto, come strapparsi un cerotto.
Ai ragazzi che mi hanno telefonato ho detto loro di pazientare per
tutta la serata e di iscriversi, se non l'avessero già fatto, in ML
per essere aggiornati sulla manutenzione straordinaria che
periodicamente avviene sui supernodi.

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

Si, come quando sbatti con la testa contro un vetro e non riesci a
capire perchè non passi.
Se a l2 cerchiamo un peer e questo non è raggiungibile le richieste
ARP scadono e la connessione a seguire, con CI solo l'arp che risolve
l'AP funziona, tutto il resto è un buco nero.

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

Notato e comunicato il lista il 18 agosto, quando il primo tunnel andò
in produzione, donato.
Certo non ci credevamo finquando anche voi non ci avete minato la crozza :)

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

quì dovremmo modificare lo script di init, piuttosto che sporcare
sarebbe meglio un pull request all'autore del package.

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

Questa cosa mi frega la VPN quando vi accedo dall' ATM ma spero che il
portforward del router ATM possa funzionare in l3 e con le rotte
statiche... PErchè purtroppo questo non supporta le vlan, altrimenti
lo pluggavo in 10.87 e avevo risolto anche il DNAT verso openVPN. Ma
poi si vedrà.


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

per esterno non intendo la WAN NINUX ma la WAN ATM.
tornando a CI + Tunnel, ai problemi riscontrati, ecco il trobleshooting:

problema:
le autenticazioni TLS di openVPN falliscono.
soluzione:
al log del server appaiono connessioni da newSPIG e non dai peers,
bisogna rimuovere il nat su newspig altrimenti i certificati appaiono
falsificati al server.

problema:
il tunnel è stabilito ma non fà traffico.
soluzione:
controllare il default gw originario. Il tunnel è stato stabilito
perchè verso 10.87 ( il server openvpn), tramite il routing, è stata
stipulata la sessione ma, a tunnel avvenuto, il traffico tunnelato
viaggia attraverso il nostro default gw che se è irraggiungibile per
via della CI ci imbeonisce tutto "inspiegabilmente". Questo dipende
dalla logica interna di routing di openVPN, si può ovviare in diversi
modi: con gli script post-up o con le regole route all'interno del
client ( di fatto il client può eludere e ignorare i push delle route
dal server), sistemando come default gw l' AP, procastinando l'avvio
di openVPN, altre ed eventuali, l'importante è capire PERCHE' !

problema:
openvpn non stipula la connessione perchè il client lavora su 10.87 e
il server risponde su 172.17.87.
soluzione:
senza CI è possibile includere "option float 1" e consentire al server
di fare questo, con la CI invece e inaspettatamente, questo non
funziona. Dobbiamo sistemare l' interfaccia del server openVPN sull'ip
10.87, quello dal quale giungono le connessioni. Questa cosa
richiederà ulteriori analisi ma, allo stato attuale funzia.

Che dire ragazzi ?
Avevo ospiti a casa e mentre ci scolavamo diverse birre belghe e
guinness, tra una telefonata e l'altra, abbiamo migrato in CI.
E' sempre un piacere,
G