[roby6812]

Ciao a tutti, sono nuovo e mi sono appena presentato nella sezione opportuna.
Vi scrivo perchè mi piacerebbe risolvere alcuni problemi di configurazione di OpenWrt. Premetto che ho serie lacune per quanto riguarda router e firewall per questo vi chiedo di concedermi osservazioni a volte da neofita.
Obiettivo: VPN con router openWrt-WireGuard che mi permetta di raggiungere i server della mia lan aziendale
Installato openWrt su un pc muletto per fare i test, configurata la rete FTTH gpon Aruba senza problemi e tirato su il firewall di default che pare funzionare perfettamente. Creata la rete interna nattata. Tutto pare funzionare perfettamente fino a qui, tuttavia se provo, collegandomi via ssh al router, a pingare le macchine della rete interna del router il ping non viene risolto. Viene risolto solo il ping della rete assegnata al router stesso e basta. Non ne capisco il motivo perchè se io pingo dal router non dovrei stare prima del firewall ma dopo il firwall, no? Sbaglio a ragionare?
Di conseguenza ho un'altra lan interna che chiameremo lan2, che fisicamente è connessa con una seconda nic, che si comporta nello stesso modo. In questo caso il comportamento è coerente con la prima lan e quindi mi aspetto che risolto il primo si risolva anche il secondo.

Passiamo ora ai problemi con WireGuard. Installato e configurato si connette perfettamente, certo poi non riesco a pingare le mie reti interne ma dato che non le pingo nemmeno dal router per ora non puo essere un problema. Tuttavia ho provato a mettere la lan2 non come rete interna ma come wan e in questa pericolosissima configurazione la vedo e mi è stata utile per fare un test di trasferimento file. La cosa strana che si verifica è la seguente: 2 linee gpon identiche tutte e tutte e due gestite da aruba. speed test per verificare le velocità delle linee con risultati 900/280 per entrambe le linee. Client wireguard windows che si connette al server wireguard installato nel router. Ma mentre il download server-client sfiora correttamente i 280Mbit, l'upload dal client al server va a soli 70Mbit di media. Questa assimetria proprio non me la spiego anche perchè avevo provato in una rete locale e con la stessa configurazione ed avevo ottenuto un gigabit pieno sia in download che in upload.

Questo è il mio problema e capisco che devo risolverlo per step, e prima di tutto bisogna risolvere la questione dei ping alle lan interne credo.

Per intanto grazie a tutti
roberto

[roby6812]

Aggiornamento:
Ho parzialmente risolto i problemi del ping all'interno della stessa rete.
Per quanto riguarda la lan1 i problemi risiedevano tutti nei firwall di windows. Disabilitato il firwall le macchine le si raggiunge sia via ssh dal router sia da tutte le macchine client che sono connesse in vpn.
Invece la lan2 aveva un problema diverso. Per mio errore l'indirizzo assegnato alla nic era tipo 192.168.100.0/32 dove invece doveva essere un 192.168.100.0/24. In questo modo risolve il ping di tutta la rete via ssh dal router stesso, tuttavia non sono ancora riuscito ancora a far vedere tale rete ai client via vpn. La cosa strana è che la nic della lan1 e quella della lan2 sono configurate uguale ma una va e una no. ogni idea sul perchè non vada è ben accetta.
Successivamente resterà da risolvere l'assimetria di upload/download che si genera dentro la vpn.

Un saluto a tutti

[roby6812]

Dunque ho un indizio sul perche' sembra non funzionare la lan2. l'unica differenza che c'e' tra la lan1 (che riesco a pingare) e la lan2 (che non pingo) e' che la lan1 ha assegnato un gateway. Nella lan2 non c'e' gateway, quindi mi sa che un pacchetto proveniente da altra rete non sa dove andare credo se non c'e' un gateway. Il punto e' che preferirei restasse senza gateway. Ora mi chiedo e vi chiedo se posso dire al router un qualche cosa affinche' ci pensi lui ad instradare correttamente i pacchetti. Francamente faccio fatica a comprendere come sia possibile che riesca a pingare tutti gli indirizzi di lan2 dal router, tutti gli indirizzi delle nic del router dai client vpn compreso l'ip della nic di lan2 e non gli indirizzi attivi dell' intera rete lan2.

[fabiobassa]

in effetti la tua precisazione

Premetto che ho serie lacune per quanto riguarda router e firewall

giustifica anche la seconda affermazione

Francamente faccio fatica a comprendere come sia possibile che riesca a pingare tutti gli indirizzi di lan2 dal router, tutti gli indirizzi delle nic del router dai client vpn compreso l'ip della nic di lan2 e non gli indirizzi attivi dell' intera rete lan2.

Il routing alla fine è abbastanza intuitivo ma sicuramente all 'inizio ci si  puo' sbattere contro e rimanere perplessi.
Vediamo dunque alcuni punti:

Nella lan2 non c'e' gateway, quindi mi sa che un pacchetto proveniente da altra rete non sa dove andare credo se non c'e' un gateway. Il punto e' che preferirei restasse senza gateway

Esattamente e la spiegazione la trovi un poco piu sotto.
in effetti una macchina potrebbe avere anche sviariati gateway, nel qual caso nessuno di essi dovrebbe essere un DEFAULT GATEWAY ovvero il gateway da cui uscire come default verso la rotta 0.0.0.0 ( cioe tutto in mondo esterno). Il nic2 lo puoi tranquillamente lasciare senza gateway e dunque su quel nic scorazzaerai SOLO nella lan interna senza uscire su internet , ma di questo gia ti sei accorto da solo

Ora mi chiedo e vi chiedo se posso dire al router un qualche cosa affinche' ci pensi lui ad instradare correttamente i pacchetti

il router è basato su openwrt dunque puoi inserire a mano delle rotte e SOPRATTUTTO delle regole di masquerading e questo ti facilita le cose.
supponiamo ( sto inventando..) che il nic1 abbia ip sulla macchina 192.168.1.1 e che il nic2 abbia ip sulla macchina172.2.3.1 e che entrambe le subnet siano  /24  ( 254 ip disponibili) per cui tutte le tue macchine A VALLE DEL NIC1  avranno un ip del tipo 192.168.1.xxx e quelle A VALLE DEL NIC2  avranno un ip del tipo 172.2.3.xxx.
Quando dal CLIENT VPN esterno ti colleghi alla macchina server VPN , il tuo ip sorgente sara qualcosa del tipo che so ( invento anche qui) 6.5.3.4:qualche strana porta (6.5.4.3:5555).
 questo ip è un ip del MONDO ESTERNO, ovvero di quel famoso 0.0.0.0. Bene fin qui spero ci siamo !

Dall'esterno puoi pingare nell 'ordine:
ip della vpn ( risiede sulla macchina stessa)
ip del nic1 192.168.1.1 ( risiede sulla macchina stessa)
ip del nic 2 172.2.3.1 ( risiede sulla macchina stessa) MA NON LA SUA SUBNET MENTRE dalla macchina stessa puoi pingare OVVIAMENTE tutta la subnet 172.2.3.xxx perche è una lan... non hai bisogno di alcun gateway appunto.
Non dimentichiamo che per fare si che il pacchetto da un ip di lan 2 ( 172.2.3.xxx ) torni verso il mondo esterno (6.5.4.3:5555) , hai bisogno di un gateway  verso 0.0.0.0 e tu... sul nick 2 NON LO HAI !
Per ottenere ch i pacchetti girino tra un nick e un altro innanzitutto devi avere ip_forward attivato:

Codice: [Seleziona]

cat /proc/sys/net/ipv4/ip_forward  ti dovrebbe restituire 1 . Se ti restituisce 0 zero momentaneamente lo puoi attivare a uno con

Codice: [Seleziona]

echo 1 > /proc/sys/net/ipv4/ip_forwardLa sintassi che adesso scrivero' vale per linux, da un po di tempo non metto mani su openwrt , ma dovrebbe funzionare lo stesso.
da una shell puoi provare a dare

Codice: [Seleziona]

iptables -t nat -I POSTROUTING -o "NOME DEL NICK2" -j MASQUERADE
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPTdevi sostituire nome del nick2 SENZA virgolette col reale nome del nick 2 ottenuto dal comando

Codice: [Seleziona]

ifconfigche so.. sara eth1 oppure enps qualcosa.. insomma mettilo li
con questo comando in pratica un pacchetto che arriva da 6.5.4.3:5555 destinato a 172.2.3.100 ip interno della lan 2 apparirà come se avesse sorgente 172.2.3.1 ed essendo sorgente un ip interno non avra' bisogno di un gateway verso 0.0.0.0 per uscire ( piccola bugia... il suo gateway sara 172.2.3..1 )

Ultimissima cosa:
con openwrt per "istruire" i client vpn che a valle del router esistessero delle subnet PRIVATE ci stava da dare uno statement "IROUTE ".
Non so wireguard come ragiona ma assicurati che i client vpn SAPPIANO che a valle del server vpn esistono due distinte subnets:
192.168.1.xxx
172.2.3.xxx

Spero di essere stato sufficientemente chiaro nella esposizione ma putroppo il routing ha bisogno di poco poco di dimestichezza altrimenti è una spina nel fianco

[roby6812]

Grazie 1000 Fabio, dalla tua spiegazione credo di aver capito il problema. Se ho capito bene il problema il ping arriva alla rete interna ma non sa come tornare indietro, giusto?
Comunque  se gli do i comandi che mi hai suggerito funziona. Per precisazione il secondo comando deve essere cambiato in

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

perche' "state" e' deprecato. da quanto ho letto pare che nftables abbia sostituito iptables.

Bene ora raggiungo e vedo le reti interne, tuttavia ho fatto una seconda scoperta. Se prima da client windows a server presente nella rete interna in azienda avevo una velocita di 280 Mbit in download e 70 in upload, ora ottengo solo 140 Mbit in download e sempre 70 in upload. E' come se la riassegnazione degli indirizzi ip sui pacchetti abbiano una forte influenza diretta sulle prestazioni. Se e' cosi forse ora e' anche un po piu chiaro perche' c'era questa assimetria anche prima. Forse i pacchetti in upload fanno un giro ancora piu complesso e le prestazioni calano. Ma a questo punto mi chiedo, come posso configurare il tutto affinche' possa impattare il meno possibile sulle prestazioni?

[fabiobassa]

@roby6812

Per precisazione il secondo comando deve essere cambiato in

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Eh si, molto dipende dalla versione che ci sta. comunque se funziona segno che avevamo beccato il problema, era un blocco sul routing.
Adesso ci dovrebbe essere un metodo per rendere quelle modifiche permanenti al reboot mediante iptables-persistent

Ma a questo punto mi chiedo, come posso configurare il tutto affinche' possa impattare il meno possibile sulle prestazioni?

Non puoi !
 Il tunnel vpn ha SEMPRE un MTU maximum transfer Unit piu piccolo della connession su cui è instaurato
Tipicamente un link è 1500 ... un ppoe è 1492

Il payload è sempre accompagnato da un Header (intestazione) di dimensione pari a 5 byte. Quindi di per sè l'efficienza del protocollo ATM è pari a:
eff_ATM=48/(48+5)=90.57%

Questo è un esempio di mtu su ppoe ATM e addirittura un mtu su vpn puo scendere anche a 1350 o addirittura meno ( mtu è negoziato da wireguard e dunque ci sta poco da fare li , se lo si mette troppo alto inizia a frammentare e perdere pacchetti)
Aggiungi che la macchina sta facendo un bel po di lavoro di masquerading e tabelle di Nat da tenere in piedi
A mio modestissimo avviso, gia sarei ultra contento che hai quelle prestazioni , ma questa è opinione personale

[roby6812]

Eh si, molto dipende dalla versione che ci sta. comunque se funziona segno che avevamo beccato il problema, era un blocco sul routing.
Adesso ci dovrebbe essere un metodo per rendere quelle modifiche permanenti al reboot mediante iptables-persistent

E si il problema lo hai beccato subito e ti ringrazio molto.
lo segnalo per tutti quelli che usano OpenWrt. E' facile inserire comandi manuali di iptables con OpenWrt. Scheda firewall, ultimo tab e fa tutto lui anche al riavvio.

Non puoi !
 Il tunnel vpn ha SEMPRE un MTU maximum transfer Unit piu piccolo della connession su cui è instaurato
Tipicamente un link è 1500 ... un ppoe è 1492

Ok. Ma allora perche' se io trasferisco su una macchina collegata nella lan1 e quindi provvista di gateway ottengo un download di 280mbit e un upload di 70 Mbit? Anche in questo caso l'MTU di ppoe e' di 1492. Lo chiedo solo per capire. Inoltre avevo fatto anche un altro test. Avevo messo la lan2 fuori dal firewall giusto per test e cioe' l'avevo messa come wan e la vedevo senza gateway. In questo caso trasferivo sempre a 280Mbit in down e 70 in up. E poi mi chiedo perche' c'e' questa assimetria. Non dovrebbero trasferire in uguel modo sia in up che in down?

Questo è un esempio di mtu su ppoe ATM e addirittura un mtu su vpn puo scendere anche a 1350 o addirittura meno ( mtu è negoziato da wireguard e dunque ci sta poco da fare li , se lo si mette troppo alto inizia a frammentare e perdere pacchetti)
Aggiungi che la macchina sta facendo un bel po di lavoro di masquerading e tabelle di Nat da tenere in piedi
A mio modestissimo avviso, gia sarei ultra contento che hai quelle prestazioni , ma questa è opinione personale

Certo capisco infatti MTU standart di wireguard e' 1420. Comunque, proprio per fare tutti questi test, ho montato il tutto su una macchina che spinge per evitare ogni collo dovuto alla capacita di calcolo della macchina. Immagina che e' una macchina che ha sempre fatto editing video per cui ram e processore dovrebbero essere adeguati per evitare colli di bottiglia. Sbaglio a pensarla cosi?
Aggiungo anche un altro dato. Prima di decidere con che codice fare la vpn ho cercato per bene i vari pareri e ho scoperto che wireguard era quella piu aggiornata che garantiva le migliori performance. Deciso che dovevo usare quella volevo testarne le performance escludendo le problematiche internet. Ho quindi configurato una vpn interna e saturavo una gigabit piena sia in down che in up. Ora passavo attraverso wireguard che usa MTU 1420 ma non ho subito rallentamenti rispetto ad una gigabit. E' vero che ora si aggiunge la pppoe a 1492 ma, forse proprio perche' non ci capisco nulla di reti, mi pare una prestazione un po troppo bassa per poter attribuire tutto all'MTU alla luce della prova su rete interna che ti ho descritto ora. Non voglio mettere in dubbio nulla e nessuno io voglio capire, perche' avevo trovato qualcuno che sollevava la questione MTU sulle vpn ed e' per questo che ho voluto testarmela su una rete interna creando due reti distinte collegate solo con wireguard. Da ignorante in materia,quale sono, ne avevo concluso che probabilmente incideva si ma a livelli piu alti di flusso dati per cui mi son detto "andiamo avanti". Cosa non ha tenuto in considerazione il mio modo di ragionare?

[roby6812]

.

[fabiobassa]

mi sa che ci devi andare sopra.. modifica... e cancelli tutto lasciando solo un punto . o uno smile 
Ad eliminare del tutto non ho idea come si faccia

Per quanto riguarda le differenti velocita non saprei dirti, so solo che le vpn sono comode si ma comunque un piccolo collo di bottiglia lo creano