HiPath / HiCom > HiPath - 3000 / 5000

Problema trunk Ip in cornet o sip tra due centrali H3000

<< < (7/12) > >>

Kimera:

--- Quote from: ziotibia81 on February 12, 2013, 09:56:23 am ---Ho parlato con un altro installatore e mi ha confermato che anche lui, in casi simili, è stato costretto ad inserire delle rotte statiche (ripeto, teoricamente totalmente inutili essendoci un solo GW) sugli HG.
--- End quote ---

Non capisco: quando si programma un IP Trunking nelle HG1500 appartenenti a sedi interconnesse tramite una VPN (nello specifico: VPN Box-To-Box instaurate dai rispettivi Firewall, Firewall che fungono da (Default) Gateway per ciascuna delle HG1500 in questione) GIA' nella programmazione dei Trunk si inseriscono (ad incrocio) gli IP di ciascun nodo remoto...quindi le "rotte" sono GIA' (in qualche misura) dettate (...altrimenti l'HG1500 della Sede A non saprebbe di dover riversare il suo traffico IP/VoIP verso l'HG1500 della Sede B e viceversa...).

Se dovesse essere necessario esplicitare una rotta statica (quindi sul Routing) dell'HG1500 oltre a quella che si crea quando si programma l'IP Trunking significherebbe che i due Firewall non sono programmati (la loro VPN non è programmata) a dovere.

O sbaglio il ragionamento ?

D'altra parte ho il caso sotto gli occhi di un PC nella LAN della Sede A (IP Statico/Subnet Mask/Default Gateway per la Sede A) connesso ad un Firewall Netgear ProSafe FVS318 in VPN Box-to-Box con un'altro Firewall ad esso gemello installato presso la Sede B dove ho un'altro PC con le medesime impostazioni ovviamente inerenti alla Sede B (quindi, ovviamente, LAN differenti come nel tuo caso).

Tra le altre cose (a "complicare" lo scenario) ci sono di mezzo i Router di Telecom Italia per le due rispettive ADSL Alice Business che fanno NAT (1 solo IP Pubblico Statico disponibile) e sui quali ho fatto il puro e totale Port Forwarding tra le loro WAN e le WAN dei rispettivi Firewall (che ovviamente sono connesse alle LAN dei rispettivi Router)...quindi la configurazione è: PC - Firewall - Router - Router - Firewall - PC. Nulla di trascendentale. Nessuna Rotta Statica nei PC.

ziotibia81:

--- Quote from: Kimera on February 13, 2013, 09:35:42 am ---
Non capisco: quando si programma un IP Trunking nelle HG1500 appartenenti a sedi interconnesse tramite una VPN (nello specifico: VPN Box-To-Box instaurate dai rispettivi Firewall, Firewall che fungono da (Default) Gateway per ciascuna delle HG1500 in questione) GIA' nella programmazione dei Trunk si inseriscono (ad incrocio) gli IP di ciascun nodo remoto...quindi le "rotte" sono GIA' (in qualche misura) dettate (...altrimenti l'HG1500 della Sede A non saprebbe di dover riversare il suo traffico IP/VoIP verso l'HG1500 della Sede B e viceversa...).

Se dovesse essere necessario esplicitare una rotta statica (quindi sul Routing) dell'HG1500 oltre a quella che si crea quando si programma l'IP Trunking significherebbe che i due Firewall non sono programmati (la loro VPN non è programmata) a dovere.

O sbaglio il ragionamento ?


--- End quote ---

Sbagli in parte il ragionamento e in parte è corretto.

Lascia perder per un attimo gli ip "incrociati" sui trunk degli HG.

In una situazione normale accade questo:

Un pc deve instradare un pacchetto, se la destinazione è nella sua rete (controllo tramite sn mask), instrada il pacchetto diretto.
Se non è nella sua rete cerca un rotta statica per instradare, se non è nelle rotte statiche usa il GW di default.
Tralaltro il gw di default in teroia non esiste perchè un una rotta statica verso tutte le destinazioni. Vedi un "route print" su qualunque pc.

Negli HG, invece, accade una cosa strana specialmente nella parte voip:

HG deve instradare un pacchetto, la destinazione non è nella sua rete, per instradarlo usa la catena delle rotte statiche e poi il default GW.
I pacchetti di ritorno (per chi conosce iptables: stato connessione RELATED, ESTABLISHED) vengono instradati secondo la catena già "scovata" per l'invio.

Quando HG riceve un pacchetto, per la prima volta (per chi conosce iptables: stato connessione NEW) e il pacchetto proviene da una rete diversa, HG in alcuni casi non risponde.
Se invece la rete di provenienza è presente tra le rotte statiche allora risponde.

Ora il motivo esatto non lo so...

le ipotesi sono due:

A) Siemens ha messo volutamente questa cosa come controllo di sicurezza
B) E' un bug: hg riceve il pacchetto, cerca di rispondere ma non trova una via su cui instradarlo.

Tralatro questa cosa non è valida sempre. esempio che è successo a me:

Due sedi in VPN con cornet ip e alcuni pc connessi in vpn con softclient SIP.

Sede A 192.168.60.x
Sede B 192.168.70x
pc in vpn 192.168.250.x con Sede A

le due sedi avevano un solo gw di default, i pc di più avendo una VPN sul pc ma non centra.

I pc si registravano (e funzionavano) correttamente sulla sede A, Sede A e Sede B non si connettevano in cornet.
Aggiunte le rotte statiche sui due HG per le due sedi (straripeto assolutamente inutili in teoria) e tutto ha preso a funzionare.

Forse questo problema c'è solo con le connesisoni TCP (trasporto del cornet se non sbaglio) mentre con le UDP (SIP) no.
Oppure è proprio stato fatto come controllo di sicurezza solo sui trunk per. Non lo so.
 

Davide_Baratelli:

--- Quote from: ziotibia81 on February 13, 2013, 10:15:29 am ---
--- Quote from: Kimera on February 13, 2013, 09:35:42 am ---
Non capisco: quando si programma un IP Trunking nelle HG1500 appartenenti a sedi interconnesse tramite una VPN (nello specifico: VPN Box-To-Box instaurate dai rispettivi Firewall, Firewall che fungono da (Default) Gateway per ciascuna delle HG1500 in questione) GIA' nella programmazione dei Trunk si inseriscono (ad incrocio) gli IP di ciascun nodo remoto...quindi le "rotte" sono GIA' (in qualche misura) dettate (...altrimenti l'HG1500 della Sede A non saprebbe di dover riversare il suo traffico IP/VoIP verso l'HG1500 della Sede B e viceversa...).

Se dovesse essere necessario esplicitare una rotta statica (quindi sul Routing) dell'HG1500 oltre a quella che si crea quando si programma l'IP Trunking significherebbe che i due Firewall non sono programmati (la loro VPN non è programmata) a dovere.

O sbaglio il ragionamento ?


--- End quote ---

Sbagli in parte il ragionamento e in parte è corretto.

Lascia perder per un attimo gli ip "incrociati" sui trunk degli HG.

In una situazione normale accade questo:

Un pc deve instradare un pacchetto, se la destinazione è nella sua rete (controllo tramite sn mask), instrada il pacchetto diretto.
Se non è nella sua rete cerca un rotta statica per instradare, se non è nelle rotte statiche usa il GW di default.
Tralaltro il gw di default in teroia non esiste perchè un una rotta statica verso tutte le destinazioni. Vedi un "route print" su qualunque pc.

Negli HG, invece, accade una cosa strana specialmente nella parte voip:

HG deve instradare un pacchetto, la destinazione non è nella sua rete, per instradarlo usa la catena delle rotte statiche e poi il default GW.
I pacchetti di ritorno (per chi conosce iptables: stato connessione RELATED, ESTABLISHED) vengono instradati secondo la catena già "scovata" per l'invio.

Quando HG riceve un pacchetto, per la prima volta (per chi conosce iptables: stato connessione NEW) e il pacchetto proviene da una rete diversa, HG in alcuni casi non risponde.
Se invece la rete di provenienza è presente tra le rotte statiche allora risponde.

Ora il motivo esatto non lo so...

le ipotesi sono due:

A) Siemens ha messo volutamente questa cosa come controllo di sicurezza
B) E' un bug: hg riceve il pacchetto, cerca di rispondere ma non trova una via su cui instradarlo.

Tralatro questa cosa non è valida sempre. esempio che è successo a me:

Due sedi in VPN con cornet ip e alcuni pc connessi in vpn con softclient SIP.

Sede A 192.168.60.x
Sede B 192.168.70x
pc in vpn 192.168.250.x con Sede A

le due sedi avevano un solo gw di default, i pc di più avendo una VPN sul pc ma non centra.

I pc si registravano (e funzionavano) correttamente sulla sede A, Sede A e Sede B non si connettevano in cornet.
Aggiunte le rotte statiche sui due HG per le due sedi (straripeto assolutamente inutili in teoria) e tutto ha preso a funzionare.

Forse questo problema c'è solo con le connesisoni TCP (trasporto del cornet se non sbaglio) mentre con le UDP (SIP) no.
Oppure è proprio stato fatto come controllo di sicurezza solo sui trunk per. Non lo so.

--- End quote ---

le rotte statiche e il defautl gateway servono per indicare verso che destinazione mandare i pacchetti... non per valutare da chi arrivano. nell' header del pacchetto c'è l'indirizzo del mittente e del destinatario con le rispettive porte . se l'indirizzo del destinatario non  è nella stessa sotto rete viene inviato o al default gateway oppure se presente una rotta statica di quella sotto rete al suo gateway ....
Per quanto riguarda la differenza tra tcp e udp la differrenza è solo a livello di trasmissione dei pacchetti... TPC controlla la reale ricezione del pacchetto da parte del destinatario e non fa il riodino dei pacchetti  ed è per questo che è usato nella trasmissione della voce (sip e non sip) ma anche di tutti le trasmissioni "real-sensitive"

Kimera:

--- Quote from: ziotibia81 on February 13, 2013, 10:15:29 am ---Un pc deve instradare un pacchetto, se la destinazione è nella sua rete (controllo tramite sn mask), instrada il pacchetto diretto.
Se non è nella sua rete cerca un rotta statica per instradare, se non è nelle rotte statiche usa il GW di default.
Tralaltro il gw di default in teroia non esiste perchè un una rotta statica verso tutte le destinazioni.
--- End quote ---

OK, capisco.

Ma quando si definisce una rotta (statica) verso una Subnet che non è la Subnet cui fa parte l'Host su cui tale rotta viene definita (sia che essa sia la Default Route sia che essa sia una nuova Route)...si deve sempre definire sempre un "Next-Hop-Router" che altri non è che il Gateway per tale rotta...altrimenti i pacchetti destinati alla nuova Subnet gestita da tale rotta non potrebbero essere instradati.

Oppure si può definire una rotta statica che usi come Next-Hop una interfaccia fisica specifica (eth0, seriale, ecc.) senza definire un Gateway IP.


--- Quote from: ziotibia81 on February 13, 2013, 10:15:29 am ---Negli HG, invece, accade una cosa strana specialmente nella parte voip:

HG deve instradare un pacchetto, la destinazione non è nella sua rete, per instradarlo usa la catena delle rotte statiche e poi il default GW.
I pacchetti di ritorno (per chi conosce iptables: stato connessione RELATED, ESTABLISHED) vengono instradati secondo la catena già "scovata" per l'invio.

Quando HG riceve un pacchetto, per la prima volta (per chi conosce iptables: stato connessione NEW) e il pacchetto proviene da una rete diversa, HG in alcuni casi non risponde.
Se invece la rete di provenienza è presente tra le rotte statiche allora risponde.

Ora il motivo esatto non lo so...
--- End quote ---

Ma questo è il comportamento tipico di un Firewall che ha la funzionalità di "Stateful Inspection"...il tuo riferimento ad Iptables non è infatti fatto a caso. O tale Inspection viene fatta dalla HG (?) oppure da uno dei due Firewall (o da entrambi).

OK, se non ci sono rotte statiche (come tutti presumiamo) definite nelle due HG, esse instraderanno tutti i pacchetti destinati alle Subnet "aliene" (non le proprie) al loro rispettivo Default Gateway...che è anche il Default Gateway e si ritorna al caso base.


--- Quote from: ziotibia81 on February 13, 2013, 10:15:29 am ---le ipotesi sono due:

A) Siemens ha messo volutamente questa cosa come controllo di sicurezza
B) E' un bug: hg riceve il pacchetto, cerca di rispondere ma non trova una via su cui instradarlo.
--- End quote ---

Oltre al Router/Firewall che instaura la VPN non è che sull'HG c'è il Firewall attivato ? Che versioni hanno queste benedette HG1500 ?

Edit 1: in effetti la parte di Routing compete alle rotte mentre la parte di Firewalling è quella che fa l'analisi del traffico IP che transita (o che vuole transitare "attraverso" il - o i - Firewall coinvolti)...

Edit 2: non è che uno dei due Firewall (o entrambi) deputati a realizzare la VPN siano "Stateful Inspection" (sarebbe quasi normale) oppure eseguano controlli (ACL ?) specifici e differenti tra loro (inerenti MAC Address/IP sorgente/destinazione o altro)?

ziotibia81:

--- Quote from: Davide_Baratelli on February 13, 2013, 10:44:05 am ---
[..]le rotte statiche e il defautl gateway servono per indicare verso che destinazione mandare i pacchetti... non per valutare da chi arrivano. nell' header del pacchetto c'è l'indirizzo del mittente e del destinatario con le rispettive porte . se l'indirizzo del destinatario non  è nella stessa sotto rete viene inviato o al default gateway oppure se presente una rotta statica di quella sotto rete al suo gateway ....[..]

--- End quote ---

Lo so benissimo!!!
Ma sembra che gli HG non ragionino così!!

Navigation

[0] Message Index

[#] Next page

[*] Previous page