Indice del forum www.zeroshell.net
Distribuzione Linux ZeroShell
 
 FAQFAQ   CercaCerca  GruppiGruppi   RegistratiRegistrati 
 ProfiloProfilo  Log inLog in   Messaggi privatiMessaggi privati 

Net Balancer (2 WAN) e routing (ZS 1.0b13) [Fix ok, Fulvio?]

 
Nuovo argomento   Rispondi    Indice del forum -> Firewall. traffic shaping e net balancer
Precedente :: Successivo  
Autore Messaggio
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Gio Set 16, 2010 3:52 pm    Oggetto: Net Balancer (2 WAN) e routing (ZS 1.0b13) [Fix ok, Fulvio?] Rispondi citando

Salve,
ho letto nei forum del problema fra netbalancer e QoS ed ho letto il post di Fulvio in cui dice per per mancanza di tempo non ha integrato il patch di atheling nella b13, tuttavia premetto che nel mio caso il QoS non è attivo.

Ho 2 ADSL (IP statici) per sede di 2 provider diversi ed ho configurato 2 VPN (ciascuna sul proprio gateway) aggregate poi in BOND. Quello che succede è che attivando il net balancer in modalità "load balancing and failover", una delle due VPN fa fatica a connettersi e cade di continuo (anche 100 volte in 24 ore).
Questo problema delle VPN è riportato anche in alcuni post del forum per le versioni precedenti alla b13, tuttavia facendo ulteriori indagini ho scoperto che in realtà il problema non è dovuto alle VPN ma sta a livello più basso.
Infatti con il netbalancer attivo in modalità "load balancing and failover", lanciando dall'esterno 2 ping sui due indirizzi IP pubblici succede che uno risponde sempre mentre l'altro molto spesso smette di rispondere per diversi secondi (e quindi la relativa VPN cade). Con il netbalancer in modalità "failover" invece tutto funziona correttamente.

Da dentro la LAN il balancer sembra funzionare ma chiaramente questo problema ne impedisce l'utilizzo se sugli IP WAN si forniscono dei servizi (tipo le VPN ecc.).

Siccome la documentazione afferma che per il balancer non sono più necessarie ulteriori configurazioni (tipo le vecchie route statiche con 2 IP ecc.) mi chiedevo se si tratta di un bug.

Grazie e saluti.


L'ultima modifica di picov il Sab Set 25, 2010 1:03 pm, modificato 1 volta
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Ven Set 24, 2010 8:27 pm    Oggetto: Rispondi citando

Ok, ho indagato meglio il problema semplificando all'osso le configurazioni ed è venuto fuori che esso non è legato al netbalancer (che è stato disabilitato).

Il problema si verifica anche nella configurazione più semplice possibile con ZS installato su una macchina con 3 schede di rete, 1 LAN e 2 WAN su ADSL di due provider diversi.

LAN -> ETH00 -> IP_0
WAN1 -> ETH01 -> IP_1 con default gateway IP_GW1 (ADSL1 Teleunit 8IP statici, WLL su antenna)
WAN2 -> ETH02 -> IP_2 con default gateway IP_GW2 (ADSL2 Telecom 8IP statici)

Se il default gateway è impostato a IP_GW1 dall'esterno si pingano con successo sia IP_1 che IP_2.
Se invece il default gateway è impostato a IP_GW2 dall'esterno non si pinga IP_1 ma si continua a pingare IP_2.

Per indagare meglio ho usato iptraf su ZS ed ho scoperto che i ping arrivano quindi il problema sembrerebbe il ritorno. In particolare da iptraf vedo quanto segue:

Caso 1) Impostando il default gateway su IP_GW1
1.a) Ping dall'IP pubblico esterno IP_EXT verso IP_1 (ADSL Teleunit)
- ping req su ETH01 da IP_EXT su IP_1
- ping reply su ETH01 da IP_1 a IP_EXT
OK

1.b) Ping dall'IP pubblico esterno IP_EXT verso IP_2 (ADSL Telecom):
- ping req su ETH02 da IP_EXT su IP_2
- ping reply su ETH01 da IP_2 a IP_EXT
OK

Caso 2) Impostando il default gateway su IP_GW2
2.a) Ping dall'IP pubblico esterno IP_EXT verso IP_1 (ADSL Teleunit):
- ping req su ETH01 da IP_EXT su IP_1
- ping reply su ETH02 da IP_1 a IP_EXT
Non funziona (dalla macchina IP_EXT il ping fallisce)

2.b) Ping dall'IP pubblico esterno IP_EXT verso IP_2 (ADSL Telecom):
- ping req su ETH02 da IP_EXT su IP_2
- ping reply su ETH02 da IP_2 a IP_EXT
OK

Sembrerebbe che nel caso non funzionante (2.a) il reply alla richiesta che arriva dalla linea Teleunit viene rispedito sulla linea Telecom ma poi non arriva a IP_EXT (mentre il viceversa 1.b funziona).

Siccome la stessa identica cosa succede in un'altra sede che ha sempre gli stessi due provider ADSL, ho pensato che router Telecom in qualche modo bloccasse il ritorno del ping tuttavia la cosa sorprendente è che oggi ho provato la stessa configurazione su una terza sede con 2 ADSL ENTRAMBE Telecom e tutto funziona correttamente!!!

Qualcuno ha idea di cosa possa succedere o di come tracciare il problema?
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Ven Set 24, 2010 11:17 pm    Oggetto: Rispondi citando

Strano il comportamento che hai, una domanda.. ma se dai un ip table show cosa ti esce? (ed item ip table show 101 e 102 )
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Sab Set 25, 2010 8:07 am    Oggetto: Rispondi citando

Come ti dicevo ho semplificato al max la configurazione quindi tutte le catene del firewall sono su accept e senza regole.
Inoltre le tabelle di routing nella sede funzionante e quelle delle due sedi problematiche sono sovrapponibili (diversi IP a parte chiaramente).

L'unica differenza sono i provider ADSL e la mia impressione a questo punto è che ZS non sia nemmeno l'imputato (dovrei provare con un'altra distribuzione e vedere che succede).

Non so veramente che fare e nemmeno quale dei due provider chiamare per fare verifiche più approfondite.

Sarebbe possibile fare in modo che le connessioni in ingresso da una Wan siano obbligate a riuscire dalla stessa indipendentemente dal default gateway attivo?

Si accettano suggerimenti.
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Sab Set 25, 2010 9:42 am    Oggetto: Rispondi citando

ti ho chiesto se mi facevi dei comandi e mi mostravi l'output, ti spiego meglio...
dato che io ho il vizio di non leggere la documentazione e fò a modo mio, se poi non funziona mi riverso sulla documentazione.
Ti chiedevo l'output di quei comandi.

Il motivo è semplice, voglio capire se sono io che ho fatto bene a far quel che ho fatto (quindi impostare il source routing a mano), oppure non serve a niente quello che ho fatto Smile

Visto che all'inizio avevo anche io problemi (anche se non uso il loadbalancing ma solo il failover... salvo laregola per smistare i centralini voip sulla linea dedicata), probabilmente il tuto è dovuto a delle regole di sourcerouting che mancano in ZS ma che sono essenziali, in quanto iptables.. bello è caro, che fa anche il caffè.. su alcune cose o gli dai delle regole in più (inutilmente) oppure semplicemente le gestisci col source routing che io ritengo la via più semplice ed economica.

Tant'è che sui firewall ho il preboot configurato con queste due righe:
Codice:
# Impostazione routing
ip rule add from <ip_wan_ISP1> table 100
ip rule add from <ip_wan_ISP2> table 101


Ora il table 100 e il table 101 li ho presi da "ip rule show" e da "ip route show table 100" e "ip route show table 101".

Potrebbe darsi che il tuo problema e che ZS prova ad instradare i pacchetti in uscita di ISP1 verso ISP2 e viceversa.. e "normalmente" il source spoofing non è abilitato sui router dei ns provider (almeno questo in italia lo sappiamo fare Razz).

Fammi sapere se casomai ti sono stato d'aiuto Smile
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Sab Set 25, 2010 10:57 am    Oggetto: Rispondi citando

Ok, con il source routing si risolve tutto. Quello che entra da un'interfaccia riesce dalla stessa senza problemi.

Citazione:
Voglio capire se sono io che ho fatto bene a far quel che ho fatto (quindi impostare il source routing a mano), oppure non serve a niente quello che ho fatto Smile


Direi che hai fatto benissimo, cosi ti metti al riparo dalle impostazioni dei vari provider.

Citazione:
in quanto iptables... su alcune cose o gli dai delle regole in più (inutilmente) oppure semplicemente le gestisci col source routing che io ritengo la via più semplice ed economica.


Effettivamente mi stavo perdendo con il mangle ed il mark dei pacchetti in ingresso ma con il source routing è molto molto più semplice.

Citazione:
Tant'è che sui firewall ho il preboot configurato con queste due righe:
Codice:
# Impostazione routing
ip rule add from <ip_wan_ISP1> table 100
ip rule add from <ip_wan_ISP2> table 101

Ora il table 100 e il table 101 li ho presi da "ip rule show" e da "ip route show table 100" e "ip route show table 101".


Perfetto, l'unica avvertenza qui (per i lettori) è che i numeri delle tabelle non solo possono variare essendo legati al numero di gateway del balancer, ma se si traffica col balancer eliminano ed aggiungendo elementi vengono assegnati in modo COMUNQUE progressivo.
Mi spiego meglio:
il default gateway ha la tabella 100, poi aggiungendone altri questi prendono il 101, 102 ecc. Se però elimino la riga 1 del balancer (table 101) quando ne riaggiungo un'altro quel gateway prenderà la tabella 103 (quindi la 101 rimarrà vuota e non utilizzata).
L'indicazione di estrarli da "ip rule show" è essenziale e ci si deve anche ricordare di aggiornare le istruzioni dello script in pre boot se si è andati a trafficare con i gateways del balancer.

Citazione:
Potrebbe darsi che il tuo problema e che ZS prova ad instradare i pacchetti in uscita di ISP1 verso ISP2 e viceversa.. e "normalmente" il source spoofing non è abilitato sui router dei ns provider (almeno questo in italia lo sappiamo fare Razz).

Si, effettivamente il dedug con iptraf mostrava bene il problema: evidentemente il router ADSL1 (Teleunit) non esegue questo controllo mentre quello ADSL2 (Telecom) si.
Se vi state chiedendo come mai nella terza sede con 2 ADSL Telecom tutto funzionava, la risposta più probabile è che gli IP delle due ADSL vengono riconosciuti comunque come facenti parte della stessa rete Telecom e quindi possono uscire da una connessione all'altra.

Citazione:
Fammi sapere se casomai ti sono stato d'aiuto Smile


Più che di aiuto direi che mi hai salvato la giornata.
Grazie mille.

Speriamo che Fulvio implementi al più presto sia il tuo fix per i BOND, sia la possibilità di gestire il source routing i modo semplice dall'interfaccia web.
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Sab Set 25, 2010 11:49 am    Oggetto: Rispondi citando

picov ha scritto:
Ok, con il source routing si risolve tutto. Quello che entra da un'interfaccia riesce dalla stessa senza problemi.

Citazione:
Voglio capire se sono io che ho fatto bene a far quel che ho fatto (quindi impostare il source routing a mano), oppure non serve a niente quello che ho fatto Smile


Direi che hai fatto benissimo, cosi ti metti al riparo dalle impostazioni dei vari provider.

Più che dei provider, istrado come si deve i pacchetti.. anche perchè, se VPN1 deve viaggiare su ADSL1 e VPN0 deve viaggiare su ADSL0, nel mio scenario non voglio che se ADSL0 è intasata (stanno scaricando da emule a pala.. ad esempio), la VPN1 ne debba risentire, perchè il traffico uscente va a saturare ancor di più la banda su ADSL0.

Citazione:

Citazione:
Fammi sapere se casomai ti sono stato d'aiuto Smile


Più che di aiuto direi che mi hai salvato la giornata.
Grazie mille.

Speriamo che Fulvio implementi al più presto sia il tuo fix per i BOND, sia la possibilità di gestire il source routing i modo semplice dall'interfaccia web.

Son contento che t'ho salvato la giornata, almeno non ammattisci come ho fatto io per il BOND... che mi trovao il cliente che mi chiamava ogni 3x2 perchè quel mattacchione del BOND s'addormentava sulla linea più lenta e non tornava più Razz

Spero tanto anche io che Fulvio inserisca il fix per i Bond, almeno li facciamo funzionare a dovere, e perchè no.. un piccolo pannellino dove poter abilitare il sourcerouting sarebbe carino. Casomai stesso nella parte router dove diamo le rotte, un bel dropdown menu che fai "DST" o "SRC" così in una schermata ti vedi tutte le rotte già belle e pronte.
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Sab Set 25, 2010 12:32 pm    Oggetto: Rispondi citando

Tanto per continuare ad indagare, mi viene anche il dubbio che ZS tenti di gestire il routing correttamente ma forse c'è qualche problema nel mark dei pacchetti?

In effetti con le nuove regole per il source routing la situazione è questa:

root> ip rule
0: from all lookup local
32761: from SUBNET_ADSL_2 lookup 102
32762: from SUBNET_ADSL_1 lookup 101
32763: from all fwmark 0x65 lookup 101
32764: from all fwmark 0x66 lookup 102
32766: from all lookup main
32767: from all lookup default

Quello che vedo è che le due regole che seguono quelle inserite a mano, sono identiche (mandano sulle stesse tabelle) a condizione che i pacchetti vengano identificati come marchiati 0x65 e 0x66.

I riferimenti dentro iptables a quei mark sono questi e li dovrebbe aver creari il balancer.

root> iptables-save
# Generated by iptables-save v1.4.0 on Sat Sep 25 13:26:01 2010
*nat
:PREROUTING ACCEPT [139600:9939604]
:POSTROUTING ACCEPT [39508:2267900]
:OUTPUT ACCEPT [75546:6226956]
...
COMMIT
# Completed on Sat Sep 25 13:26:01 2010
# Generated by iptables-save v1.4.0 on Sat Sep 25 13:26:01 2010
*mangle
:PREROUTING ACCEPT [5903975:2778406237]
:INPUT ACCEPT [1876969:186765366]
:FORWARD ACCEPT [4050961:2612058208]
:OUTPUT ACCEPT [1657015:249897721]
:POSTROUTING ACCEPT [5705969:2861803399]
:NB_CT_POST - [0:0]
:NB_STAT - [0:0]
:NetBalancer - [0:0]
:OpenVPN - [0:0]
-A PREROUTING -j CONNMARK --restore-mark
-A PREROUTING -j NetBalancer
-A INPUT -j NetBalancer
-A OUTPUT -j NetBalancer
-A OUTPUT -j OpenVPN
-A POSTROUTING -m state --state NEW -j NB_CT_POST
-A POSTROUTING -j NB_STAT
-A NB_CT_POST -m realm --realm 0x66 -j MARK --set-mark 0x66
-A NB_CT_POST -m realm --realm 0x65 -j MARK --set-mark 0x65
-A NB_CT_POST -j CONNMARK --save-mark
-A NB_STAT -m mark --mark 0x66
-A NB_STAT -m mark --mark 0x65
COMMIT
# Completed on Sat Sep 25 13:26:01 2010
# Generated by iptables-save v1.4.0 on Sat Sep 25 13:26:01 2010
*filter
...

Che ne dite? Fulvio?
Top
Profilo Invia messaggio privato
ufoonline



Registrato: 03/07/08 22:16
Messaggi: 261

MessaggioInviato: Sab Set 25, 2010 12:53 pm    Oggetto: Rispondi citando

Se ricordo bene,quando indagai io all'epoca il problema è che ZS marca i pacchetti per ciò che riguarda il forwarding, e che quindi quando tenti di contattare ZS direttamente, le regole vanno ... a putten Razz


Ovvio che ti trovi le 2 regole uguali, una con l'ip e l'altra con l'fwmark.. perchè quella con l'fwmark serve proprio a fare la stessa cosa che facciamo noi lper il routing locale di zs.
Top
Profilo Invia messaggio privato
picov



Registrato: 16/09/10 09:01
Messaggi: 37

MessaggioInviato: Sab Set 25, 2010 3:49 pm    Oggetto: Rispondi citando

Allora ufoonline, visto che risolvi tutti i problemi approfitto per chiederti un parere anche su altre questioni aperte:

NAT sulle VPN
http://www.zeroshell.net/forum/viewtopic.php?t=2568

Prestazioni HTTP Proxy su ALIX -> disaccoppiamento HAVP e ClamAV
http://www.zeroshell.net/forum/viewtopic.php?t=2567
Top
Profilo Invia messaggio privato
Mostra prima i messaggi di:   
Nuovo argomento   Rispondi    Indice del forum -> Firewall. traffic shaping e net balancer Tutti i fusi orari sono GMT + 1 ora
Pagina 1 di 1

 
Vai a:  
Non puoi inserire nuovi argomenti
Non puoi rispondere a nessun argomento
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi votare nei sondaggi


Powered by phpBB © 2001, 2005 phpBB Group
phpbb.it