[Ninux-Calabria] CI on e problemi con tunnel

[Giuseppe De Marco]

Il 06 novembre 2014 01:11, Stefano De Carlo <stefanauss a gmail.com> ha scritto:
> Il 05 novembre 2014 23:40, Vincenzo Pirrone <linuspax a gmail.com> ha scritto:


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

quì voglio dire una cosa che ho toccato con mano.
Il NAT via luci è pericoloso perchè andando a vedere le regole è
estremamente generico, tutte le interfacce che fanno forward scorrono,
in serie, le chains NAT poste in -t nat postrouting_rules e sappiamo
bene che da una interfaccia può benissimo giungere un pacchetto
proveniente da un'altra rete, se questa interfaccia è il forward verso
il NAT, questa rete forwardata e in seguito nattata. Queste cose le ho
viste in produzione rendendomi conto di preferire NAT selezionati
sulle reti di provenienza -s 10.87.x.0/24 e non sul forward
dell'interfaccia.

Un'altra cosina riguardo a NAT e Luci:
se nessun NAT è abilitato nella UI del firewall openWRT non carica i
moduli di conntrack, quindi anche sistemando custom rules di nat non
si avrebbe alcun effetto:

soluzione:
carica il modulo in rc.local OR
metti il nat che poi rimuovi e rispecifichi meglio con una custom rules OR
crei una interfaccia DUMMY dove abiliti il NAT senza che alcun'altra
interfaccia abbia forward su esso OR
dite la vostra.



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

il dyngw lo sto rimuovendo a mano da tutti i ninucsWRT da agosto, è
ancora più pericoloso con la CI.


> 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

possiamo forse rimuovere le righe di
/proc/net/arp
oppure forzare la mano con un arping, che di fatto fa un effetto
simile a ip neighbours replace.
Se scoccia scrivere un reboot non fa male :)


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

lo sleep non mi entusiasma, meglio una regola all'interno della
configurazione del client.


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

se c'è tunnel abbisogna default GW, almomento. Il problema a monte è
la logica interna di routing di openWRT che se trova un default gw
adotta una logica se non lo trova ne adotta un'altra.

Nno abbiamo provato a aggiungere a redirect-gateway e def1 , sui
server openVPN, l'opzione local.
Ci sarebbero anche altre considerazioni. Noi possiamo pushare dal
server regole di routing ad-hoc, anche rimuovere routes sui client.
C'è una email in lista che ho scritto in agosto con alcuni esempi in
tutte le salse, devo recuperare la roba scritta per queste.

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

e ci mancazze