Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ziotibia81

Pages: [1] 2 3
1
...aggiungere le rotte statiche inutili sugli hg...

Per un mistero degno di Kezzenger ci vuole una soluzione degna di Kezzenger!!  ;D

2
A dir la verità le possibilità di connettersi da remoto c'erano...
Però il cliente voleva qualcuno in loco a risolvere il problema...

Ho visto il diff e praticmante gli HG hanno la stessa configurazione salvo le ovvie differenze per i nodi e la rete.


3
Pensa che io, in quel caso, avevo i problemi tra Verona e Romania...

Spostarsi per i vari debug era comodissimo...  8)

4

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.


Normalmente è così...


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.


Il riferimento a iptables non è del caso specifico, è per "dovere di cronaca".
Il comportamento del firewall potrebbe essere ma in questo caso è irrilevante:

sono già state fatte prove per cui si vedono i pacchetti arrivare ad HG ma HG non risponde.
Quindi i firewall non centrano, i pacchetti sono transistati.
Poi la prova corretta sarebbe collegare un pc e l'hg ad uno stesso hub e verificare con un packet sniffer.
Penso sia stato fatto così
 

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)?

- Niente firewall su HG
- Versione V8 (il firmware esatto non me lo ricordo)
- come ho già detto sopra se i pacchetti arrivano ad HG e HG non risponde i firewall non centrano. I pacchetti sono arrivati quindi i firewall hanno fatto il loro lavoro.

5
Lo so che lo sai...non l'ho scritto per te...l'ho scritto per fondare un ragionamento.

ma non l'hai scritto tu....

6

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

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

7

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 ?


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.
 

8
[..]esiste un solo gw per sede e tutti gli indirizzi dei client sono distribuiti dal fw (DHCP server).[..]

Occhio che su alcuni firewall particolari esistono delle regole di sicurezza "strane" per cui accade questo:

- Il client richiede l'ip via dhcp
- il firewall rilascia l'ip e aggiunge una regola di forwarding che abilita il forwarding per i pacchetti aventi come MAC address sorgente il MAC a cui è appena stato rilasciato l'ip.
- La regola di forward viene aggiornata alla scadenza o al rinnovo del lease.

Quindi se prendi un pc "nuovo" gli metti un ip a mano non naviga. Poi prendi un pc che ha otteuto il DHCP, gli metti a mano lo stesso ip che hai usato per l'altro pc e questo naviga.

Però se è già stato verificato che i pacchetti arrivano ai rispettivi HG credo che sia il caso delle rotte "inutili".

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

10
Temevo questa risposta....  ;D

Vedo che riesco a fare.... Grazie Mille!

11
Gigaset S810 in entrambi i casi. (Non so perchè non gli hanno venduto la serie professional.... Ma non sono io il commerciale.)


12
...non mi sono spiegato bene...

Da un cliente ho una centrale Hipath 3550 V8.
La centrale ha un HG1500, è in rete e si sincronizza già con un server NTP.

Sui telefoni digitali vedo l'ora corretta.
Questa centrale ha 3 celle dect + CMI.
Sui cordless non mi sincronizza l'ora. Se a un telefono tolgo le batterie e lo riaccendo mi lampeggia 00:00 finchè non imposto l'ora a mano.

Su altri impianti, invece, ho il DECT IP. Su questi impianti imposto il server NTP sulla cella master e in automatico tutti i cordless si regolano l'ora e mostrano sul display l'ora corretta.

Questa cosa non funziona su Dect tradizionale o mi manca qualche impostazione da qualche parte?

13
Sincronizzazione orologio nel senso di ora sul display.

14
Salve a tutti,

con il sistema in oggetto è possibile far sicronizzare automaticamente l'orologio dei terminali?

Con Hipath cordless IP mi funziona questa cosa senza far nulla.
Con il Dect Light "tradizionale" invece no.

C'è qualche impostazione che mi è sfuggita?

15
Avete controllato che nei pc della rete non ci siano ci siano routes statiche aggiuntive al gateway di default?

sul pc che rispondeva al telnet mettendo l'ip del centralino sarebbe utile controllare il risultato del comando:

route print

A me una volta è successa una cosa simile:

Sede A - ip centrale 192.168.1.100 gw 192.168.1.254
VPN -> firewall -> internet -> firewall -> VPN
Sede B - ip centrale 192.168.2.100 gw 192.168.2.254

I sintomi erano pressochè uguali.
Ho provato ad aggiungere delle routes statiche sui 2 HG:

Sede A - aggiunta route rete 192.168.2.0 SN 255.255.255.0 gw 192.168.1.254
Sede B - aggiunta route rete 192.168.1.0 SN 255.255.255.0 gw 192.168.2.254

E tutto ha inizato a funzionare.
Tralantro la cosa non ha assolutamente senso se ci mettiamo a guardare le specifiche del protocollo ip,
ma sembrava quasi che la centrale scartasse i pacchetti provenienti da reti diverse non espressamente specificate nelle
regole di routing.

Pages: [1] 2 3