HiPath / HiCom > HiPath - 3000 / 5000

Problema trunk Ip in cornet o sip tra due centrali H3000

<< < (4/12) > >>

Davide_Baratelli:
mi puoi dare la mappatura degli indirizzi ip e le rotte delle varie sedi perchè io sono convinto che ci sia qualcosa che non va nelle rotte ...

ciao
Davide

Kimera:
Anzitutto manca uno schema chiaro della topologia di rete (logica più che fisica...essendo le sedi coinvolte solo due...quella fisica è abbastanza ovvia).

Due i casi: o ci sono delle VPN instaurate tra le due o più sedi, dunque delle VPN Box-To-Box giò instaurate da ciascun Router/Firewall in ciascuna sede verso ciascuna altra sede coinvolta OPPURE tali VPN non ci sono (e non vengono sostituite dalle VPN che le due HG1500 potrebbero fare) e le HG1500 sono (indirettamente) su IP Pubblico tramite i rispettivi Router/Firewall (NAT) <-- soprattutto visto il modo in cui avete fatto i test "...Spostato l'hg 1500 di como e l'hg1500 di arezzo direttamente su indirizzo pubblico...".

A questo punto:

(A) se con le VPN instaurate l'Host che si comporta in modo anomalo (fatto salvo che le VPN siano trasparenti al traffico da/per le sedi provate, quindi in entramb i versi sulla tratta provata...ed il Ping è solo uno dei test...dovreste spazzolare tutte le 65535 porte ad esempio con Nmap da sede 1 verso sede 2 e viceversa usando due Host che abbiano tutto il traffico incoming/outgoing (Firewall sull'Host disabilitato) libero oppure testando proprio (dal)le singole HG1500) è l'HG1500 di Como allora vorrei vedere, parametro per parametro (anche sulla parte Firewall della HG1500 e dell'HiPath 3000), le differenze tra il sistema di Como e quello di Prato.

(B) se SENZA le VPN instaurate (quindi i due sistemi su IP Pubblico statico) l'Host che si comporta in modo anomalo è sempre l'HG1500 di Como ricadiamo sempre nel test di cui sopra A PATTO che stavolta, non essendoci la VPN, i due Router che realizzano il NAT siano configurati in modo identico (così da poter partire con il test dicendo che i Router non sono).

(C) se (A) e (B) non danno degli esiti dai quali potete riscontrare il problema...potrebbero essere le due connessioni (xDSL) ?

Il tutto a patto che, come dice Baratelli, i settings IP e le varie Routes siano perfettamente stabilite nei due sistemi.

Saluti, Kimera.

Edit: avete provato con Nmap da Prato a Como e viceversa contro le rispettive HG1500 quando sono sotto VPN ? una porta risponde in vari modi (non solo Opened/Closed) a seconda di come il Firewall che la protegge (HG1500 ? Router/Firewall della sede ?) è programmato per proteggerla da pacchetti che possono giungere dalla LAN e dalla WAN...occhio anche qui).

Alessio Simetel:
Grazie Kimera,
Lo scan delle porte ha dato come risultato che l'unica porta che risponde se scansiono l'ip dell'hg1500 è la 443, questo sia se utilizzo l'indirizzo privato dietro il fw (172.51.100.1, 255.255.0.0), sia che se utilizzo direttamente l'indirizzo pubblico dietro il router (31.194.44.81). Lo strano che ho notato è questo. Se testo una porta che è realmente chiusa ottengo correttamente la risposta negativa, se scansiono le porte del hg (1720 o 12062) non torna indietro niente. Sniffando i pacchetti gli invite arrivano correttamente sull'hg di como che però, se il pacchetto proviene da Prato, non risponde. Se il pacchetto invece arriva dalla stessa subnet (172.51.10.254 255.255.0.0) o da un qualunque host della sede in piemonte (172.56.0.0 255.255.0.0) invece risponde. L'indirizzo dell'hg di  prato è 172.25.100.1 255.255.0.0, l'indirizzo dell'hg di arezzo è 172.24.100.1 255.255.0.0. I GW dei vari siti sono: PO 172.25.1.254, AR 172.24.1.254, CO 172.51.1.254. Ribadisco che in ogni sede c'è un unico router, ognuno di essi con la sola rotta statica di default 0.0.0.0 0.0.0.0, un unico fw, l'infrastruttura all'interno di ogni sede è tutta a livello 2 e che tutto il resto del traffico funziona correttamente, compreso quello interno tra le varie sedi per cui per me non può essere un problema di routing o di rotte, anche perchè lo sniffing dice che è il centralino che non risponde se il pacchetto proviene da quelle due particolari subnet. Oltretutto se al posto del hg sulla stessa porta dello switch, ci metto un pc con lo stesso indirizzo, la stessa subnet e lo stesso GW in ascolto sulle porte 1720 e 12062, lo raggiungo senza problemi e il pacchetto di risposta torna indietro. Io ci sto diventando matto, mi sono consultato anche con persone espertissime di reti (addirittura sono riuscito a coinvolgere un responsabile tecnico di un provider) che dai test eseguiti anche lui ha dichiarato che senza dubbio il problema è nel centralino, che però è già stato cambiato una volta interamente e altre 3 volte è stata sostituita l'hg, il centralino che è attualmente montato è stato prima testato sulla sede di prato verso arezzo e funziona.
Ho analizzato i pacchetti di ack che provengono da prato e quelli che provengono da locale, secondo me sono perfettamente identici, sia come header, come payload e come dimensione (592 byte), chiaramente variano solo gli indirizzi.
L'unica differenza che ho trovato tra le due sedi è che se faccio un test del MTU sull'indirizzo pubblico (sul privato tramite vpn non succede) è che su prato risponde anche se faccio un ping -l 1500, su como invece no, ma considerando che le macchine lavorano sul privato secondo me non c'entra niente.
Grazie a tutti.

Lucky:
Beh, direi che l' unico modo é vedere le configurazioni, con tutta la fantasia che uno possa avere credo che siamo arrivati al fondo del barattolo.

Direi disegnetto e files di configurazioni o garantire l' accesso da remoto, magari anche router e firewall, ma dubito che per questi te le diano.

Ciao

P.s.: ultima possibilità far benedire la centrale in chiesa.

Alessio Simetel:
La configurazione va bene sicuramente, considerando che il centralino che attualmente è montato a como è stato testato sulla sede di prato mettendolo in trunk verso arezzo e l'altro già esistente di prato e funzionava. Poi è stato caricato in macchina, portato a como, acceso, modificato solo gli indirizzi (da 172.25.100.2 a 172.51.100.1 e il gw da 172.25.1.254 a 172.51.1.254), attaccato al muro e non va.
In ogni caso la configurazione è stata rifatta non so quante volte... Ora a questo punto è molto semplice dire che è un problema della rete, anche perchè fintanto che utilizzavano una rete mpls tutto funzionava, dal momento che sono passati a una adsl con vpn ha smesso (solo su como, sulle altre funziona lo stesso), però dall'altra parte tutti i test portano a un problema sul centralino. Il router è stato cambiato con un modello diverso (da un tiplink a un cisco configurato da me), per cui escludo anche quello, il fw si occupa solo di fare la vpn e il nat ma comunque il problema c'è anche a monte del fw, il resto della rete è tutta a livello 2.
Forse l'unica soluzione sarà cambiare marca di centralino, ma rimarrà questo mistero.

Navigation

[0] Message Index

[#] Next page

[*] Previous page