[Modfs] Sviluppo pacchetti e porting su altri router

[Stufo76]

Originariamente inviato da cionci

gnommo, i file di configurazione vanno bene quelli si stufo76.

grazie, felice di poter contribuire

C'è solo da aggiungere un altro comando "route" sulla configurazione del server per fare client-server fra due router con modfs.

ci avevo pensato, ma in realtà non credo sia una buona idea, per una serie di motivi.
nello scrivere la configurazione, ho immaginato l'utilizzo tipico di openvpn: sono in un internet café o al lavoro con il mio laptop windows, e voglio andare in vpn sulla mia lan.
con la mia configurazione il mio laptop raggiungerebbe l'intera mia lan, e viceversa, punto e basta, il che è proprio lo scopo che voglio ottenere.
se invece ruotassi anche i pacchetti lato server, ci sarebbe un grave problema di sicurezza: in tal caso, infatti, la mia lan sarebbe raggiungibile non solo dal mio client remoto, ma anche dall'interna subnet a cui il mio client remoto appartiene, e viceversa. in pratica si farebbe un vero e proprio bridge tra le due lan, e l'utilità di avere sul router un robusto firewall spi se ne va a quel paese.
certo, qualcuno potrebbe avere la necessità d'interconnetterre due router con le rispettive lan sicure e di cui si fida, ma qui poi ci sarebbe anche un problema di routing: infatti se entrambe le lan sono 192.168.0.0/24, come è di default, e io devo raggiungere un ip appartenente ad una delle due lan, come faccio a dirgli come ruotare i pacchetti? se poi c'è un indirizzo ip duplicato su entrambe le lan è ancora peggio, si creerebbe conflitto... in definitiva, a meno di ricorrere a complesse regole di routing, una delle due lan andrebbe per forza cambiata...
se invece sono connesso con il mio client ad una wifi o una lan pubblica, è statisticamente improbabile che il dhcp mi assegni la subnet 192.168.0.0/24, e il problema di routing non si pone.
in definitiva, secondo me, il gioco non vale la candela... che ne pensate?

[cionci]

Ma la cosa serve per poter connettere tra loro due router con Modfs. Altrimenti non c'è modo.
E' chiaro che si debba dare la possibilità di farlo. Ovviamente come parametro opzionale.

[Stufo76]

Originariamente inviato da cionci

Ma la cosa serve per poter connettere tra loro due router con Modfs. Altrimenti non c'è modo.
E' chiaro che si debba dare la possibilità di farlo. Ovviamente come parametro opzionale.

certo, ci mancherebbe altro. però secondo me l'utente potrebbe distrattamente abilitare il routing anche sul server quando è in una wifi pubblica... ciao firewall, la tua lan intera su internet... non è bello affatto.
comunque, volendo fare il bridge con due router, uno dei due dovrebbe per forza cambiare la subnet da quella di default 192.168.0.0/24, altrimenti il routing diventa un problema, e ciò può voler dire riprogettare una delle due lan. comunque fatto ciò basta aggiungere la regola di routing come hai detto tu, e il gioco è fatto.

[cionci]

Originariamente inviato da Stufo76

uno dei due dovrebbe per forza cambiare la subnet da quella di default 192.168.0.0/24,

Chiaro.

[cionci]

Poi ripensandoci, non è così facile aggiungere la route per errore, perché bisogna specificare network e netmask dell'altro end-point.

[Stufo76]

Originariamente inviato da cionci

Poi ripensandoci, non è così facile aggiungere la route per errore, perché bisogna specificare network e netmask dell'altro end-point.

anche questo è vero...





...e poi così facendo ci si potrebbe fare un bel lan party in vpn

[cionci]

Originariamente inviato da Stufo76

...e poi così facendo ci si potrebbe fare un bel lan party in vpn

Si potrebbero anche prevedere client multipli, ovviamente bisognerebbe sperimentare un bel po'

[Stufo76]

Originariamente inviato da cionci

Si potrebbero anche prevedere client multipli, ovviamente bisognerebbe sperimentare un bel po'

siamo qui apposta

a proposito, oggi dall'ufficio ho fatto un po' di test di performance.
ho provato prima ad utilizzare openvpn sul mio server linux, facendo solo ruotare al router la porta, e poi ho fatto un tipico upload di un file grosso da windows.
risultato: l'upload viaggiava a circa 16mbit, ovvero saturava a tappo la banda, e l'utilizzo della cpu, nonostante l'hw modesto (cpu geode lx 500mhz con 1000 bogomips) si attestava sotto il 10%.
poi ho messo la stessa configurazione sul router, e ho rifatto la stessa identica prova.
risultato: non più di 5 mbit, con la cpu del router a tappo
perciò secondo me ha poco senso provare a configurare più di un end-to-end, già con uno le prestazioni non sono proprio esaltanti

[cionci]

Strano, ci deve essere un bottleneck da qualche parte o una somma di ritardi. Perché io da rete interna trasferivo a 5 MB/s da una condivisione samba.

[Stufo76]

Originariamente inviato da cionci

Strano, ci deve essere un bottleneck da qualche parte o una somma di ritardi. Perché io da rete interna trasferivo a 5 MB/s da una condivisione samba.

rifai la stessa prova e controlla l'utilizzo della cpu del router: se durante il trasferimento non sale l'utilizzo di openvpn vuol dire che magari hai qualche regola di routing che ti fa saltare a piè pari la vpn, magari fai anche un traceroute per sicurezza.
quando ho provato io le performance erano quelle

[cionci]

Originariamente inviato da Stufo76

rifai la stessa prova e controlla l'utilizzo della cpu del router: se durante il trasferimento non sale l'utilizzo di openvpn vuol dire che magari hai qualche regola di routing che ti fa saltare a piè pari la vpn, magari fai anche un traceroute per sicurezza.
quando ho provato io le performance erano quelle

Ho verificato, avevo OpenVPN al 60% di CPU. Ora che ci penso magari non vorrei che i pacchetti prendessero un'altra route per tornare indietro, caso mai partissero con l'IP 192.168.7.1 della scheda di rete invece che con 10.8.0.1 della VPN.

[cionci]

Complice l'influenza...ho ricompilato OpenSSL 0.9.8q in modo shared. Ecco i comandi per fare la build:

./Configure threads linux-generic32 shared no-static zlib-dynamic
cross=mips-linux-
make CC="${cross}gcc" AR="${cross}ar r" RANLIB="${cross}ranlib"
make INSTALL_PREFIX=$(pwd)/_install install_sw

Spostare _install/lib nella directory usr/lib del compilatore
Spostare _install/bin nella directory usr/bin del compilatore
Spostare _install/include nella directory usr/include del compilatore
Spostare il resto in una nuova directory usr/ssl del compilatore

Ho ricompilato stunnel e openvpn...
Per il secondo:
./configure --host=mips-linux-uclibc --disable-lzo

Ho fatto nuovamente la prova con openvpn ed effettivamente utilizzava un'altra route per i dati ingresso perché le richieste partivano con l'ip della scheda di rete.
Ora ho messo come default gateway 10.8.0.1 sul PC ed effettivamente è molto più lento. Ho misurato circa 700 KB/s.

Considerate che il PC su cui ho provato è una macchina virtuale, quindi pensate a che giro fanno questi pacchetti

[Stufo76]

Originariamente inviato da cionci

Ho misurato circa 700 KB/s.

Sono più o meno i valori che ho misurato io e confermano quello che sospettavo: il collo di bottiglia è la cpu del router che va a tappo e non riesce a gestire la cifratura di un numero di pacchetti maggiore di quel limite.

[gnommo]

Originariamente inviato da Stufo76

Sono più o meno i valori che ho misurato io e confermano quello che sospettavo: il collo di bottiglia è la cpu del router che va a tappo e non riesce a gestire la cifratura di un numero di pacchetti maggiore di quel limite.

adesso vediamo il dual core del dgn3500 come si comporta

[Alpine]

che versione di openvpn state compilando?

vi da questo errore al configure?

configure: error: C preprocessor "mips-linux-uclibc-g++" fails sanity check

[cionci]

No, non abbiamo quell'errore. La versione è 0.8.9q. Il gcc che usiamo è il 4.3.3.

[Alpine]

Originariamente inviato da cionci

No, non abbiamo quell'errore. La versione è 0.8.9q. Il gcc che usiamo è il 4.3.3.

non trovo versioni di openvpn più vecchie della 1.2 http://openvpn.net/release/old/

il gcc fornito da linksys è il 3.4.2

[cionci]

Originariamente inviato da Alpine

non trovo versioni di openvpn più vecchie della 1.2 http://openvpn.net/release/old/

il gcc fornito da linksys è il 3.4.2

Ho sbagliato, credevo di OpenSSL...la versione di OpenVPN è la 2.1.4. Hai risolto i problemi che avevi ?
Quella versione di GCC è un po' vecchiotta

[Stufo76]

Dunque, sto procedendo con il test di openvpn, e già vi segnalo il primo bug
Premessa: come già verificato, la cpu del dgn2200 non regge un flusso di pacchetti superiore a circa 5mbit.
Analizzando il troughtput, mi sono accorto che c'era qualcosa di strano.
Infatti notavo "picchi" verso l'alto e il basso, come se venissero persi pacchetti.
Inoltre un paio di volte la vpn è temporaneamente "caduta", per poi ristabilire automaticamente il collegamento poco dopo.
Ho quindi abilitato il log verbose (verb 6) e mi sono accorto di numerosi messaggi del tipo "Replay-window backtrack occurred [x]" con x che saliva progressivamente da 1 in su.
Ho spulciato un po' i documenti, ed ho scoperto l'arcano.
Con la condifurazione standard (compresa quella che ho fatto io), openvpn utilizza la porta 1194 e il protocollo udp.
Nella maggior parte delle configurazioni è un bene utilizzare il protocollo udp, perché è più veloce, leggero ed efficiente e più "compatibile" con i firewall.
Il problema è che, se hai una adsl con una banda superiore ai famosi 5mbit di "limite" della cpu del router (io ad es. ho una 20mbit), ed hai una connessione remota con una banda di upload maggiore, il protocollo udp non funziona bene: infatti è un protocollo connectionless, ovvero lo scambio di dati tra mittente e destinatario non crea prima un circuito fisico o virtuale su cui instradare l'intero flusso di dati in modo predeterminato e sequenziale, e perciò non gestisce il riordinamento dei pacchetti né la ritrasmissione di quelli persi. Tant'è vero che di solito si utilizza per lo streaming di flussi audio/video, sui quali si può tollerare anche perdita oppure overflow di pacchetti.
In pratica il protocollo udp suddivide il flusso di dati in frame instradati singolarmente ed indipendentemente l'uno dall'altro, senza ack di ritorno e senza controllo della corretta sequenza di inoltro: questo non garantisce né l'effettiva consegna del singolo pacchetto né il rispetto della sequenza temporale corretta.
Quindi, avendo il router una capacità di gestire un numero di pacchetti inferiore a quanto gli trasmetto, inizia a ricevere un overflow di pacchetti con sequenza temporale sbagliata.
Openvpn ha un buffer (di default 64 pacchetti, incrementabile) per ovviare a questo problema, ma ovviamente funziona soltanto se l'overflow è temporaneo.
Se uploado un grosso file, qualsiasi dimensione del buffer imposto, prima o poi il buffer si riempie, openvpn comincia droppare pacchetti e il tunnel vpn cade.
Ho pensato quindi di provare con il protocollo tcp, che a differenza dell'udp è connection-oriented, e garantisce la corretta trasmissione (ed eventuale ritrasmissione) dei pacchetti anche in questo particolare caso.
Per il momento sembra funzionare, sperem...
Vi aggiorno quando completo i test, stay tuned

[Alpine]

Originariamente inviato da cionci

Ho sbagliato, credevo di OpenSSL...la versione di OpenVPN è la 2.1.4. Hai risolto i problemi che avevi ?
Quella versione di GCC è un po' vecchiotta

si risolto, ho compilato anche io openvpn , mi è bastato vedere cosa faceva lo script , avevo definito la variabile export CPP=$CROSS_COMPILE"gcc" modificandola in export CPP="" configure è andato liscio.

oggi mi hanno pure attivato l'adsl "miracolo",