OpenPath
HiPath / HiCom => HiPath - 3000 / 5000 => Topic started by: Zanobini on November 27, 2012, 07:29:34 pm
-
Ciao a tutti, mi si è presentato questo problema da un nostro cliente. Il cliente ha tre stabilimenti Arezzo, Prato e Como. Un anno fa abbiamo sostituito le centrali samsung con le attuali H3000 in v8. La sostituzione è andata perfettamente bene le tre centrali si chiamavano perfettamente in trunk Ip CornetNQ. Qualche mese fa gli hanno proposto di sostiuire la loro rete con un'altra sono state rifatte le vpn e da allora tra Arezzo e Prato continuano a funzionare correttamente mentre Como non riceve e non chiama ne Arezzo ne Prato. Apenna faccio il numero mi dice "Al momento impossibile" e poco dopo "Linea Impegnata". Le prove che ho effettuato sono state: 1) provare a registrare un telefono IP di Prato a Como e funziona correttamente.
2) verificato la prima cosa ho provato a configurare il trunkip con protocollo SIP. (esito negativo)
3) configurato l'hg 1500 di como con indirizzo pubblico togliendo così di mezzo il firewall. (esito negativo)
4) ho preso una centrale nuova e verificato che configurandola a Prato funzionasse, l'ho portata a como e riconfigurata con gli indirizzi di Como ho avuto esito negativo. (Sulla solita Lan la nuova centrale con la centrale esitente il trunk funziona correttamente)
Dalle prove che ho fatto il problema è evidentemente sulla Rete,il tecnico che gestisce il firewall con le VPN mi assicura che la configurazione di quello di Como è identico a gli altri due. La domanda che mi pongo: allora dove può essere il probelma? Il provider?
Voi cosa mi suggerite? Grazie mille.
-
Alive monitor attivo? con che protocollo? icmp? Passa il ping?
In call-monitor la chiamata impegna il fascio voip?
Una bella sniffata (wireshark) sulla lan del hg di como per vedere cosa succede nella comunicazione voip?
-
Non credo che il fornitore (o i fornitori) di connettività abbia la possibilità di alterare (il traffico di) una VPN già instaurata.
Sei sicuro che chi ha predisposto e configurato le nuove VPN (con che topologia ? Hub and Spoke oppure Partial/Full Mesh) non abbia dubbi in merito (magari relativamente alle regole di Firewalling o di Routing) ?
Saluti, Kimera.
-
Come già detto il tecnico sembra non avere dubbi sulla programmazione.... il problema è che la la telefonia non va.... ed il cliente, a ragione, vorrebbe una soluzione ....... :(
-
Alive monitor attivo? con che protocollo? icmp? Passa il ping?
In call-monitor la chiamata impegna il fascio voip?
Una bella sniffata (wireshark) sulla lan del hg di como per vedere cosa succede nella comunicazione voip?
Alive monitoring ho provato sia attivato che disattivato, esito negativo. Il protocollo sia Cornet che Sip, esito negativo. Il ping funziona. il call monitoring non l'ho fatto. Ho fatto una sniffata ma non c'ho capito nulla. Se vuoi te la mando in privato.
-
Di per sè non è detto che tra due endpoints connessi tramite VPN debba necessariamente "funzionare" (ovvero dare una risposta positiva) il comando PING visto che nei Firewall che terminano tale Tunnel VPN si può selettivamente intervenire sul protocollo ICMP in modo che questo non attraversi il Tunnel stesso.
Io dubiterei proprio di chi dice di non aver dubbi...comunque con Wireshark un'idea precisa te la fai (e puoi mostrare il risultato del network sniffing anche a colui che ha predisposto i Tunnel VPN).
-
Se vuoi posso darci un occhiata, ma nella maggiorparte delle volte mi è stato più utile il call-monitor (se il problema era della centrale).
Hai provato anche uno santo riavvio?
-
Alive monitor attivo? con che protocollo? icmp? Passa il ping?
In call-monitor la chiamata impegna il fascio voip?
Una bella sniffata (wireshark) sulla lan del hg di como per vedere cosa succede nella comunicazione voip?
Alive monitoring ho provato sia attivato che disattivato, esito negativo. Il protocollo sia Cornet che Sip, esito negativo. Il ping funziona. il call monitoring non l'ho fatto. Ho fatto una sniffata ma non c'ho capito nulla. Se vuoi te la mando in privato.
il ping verso quale indirizzo lo hai fatto e lo hai fatto da un pc o dall' hg 1500?
per caso è cambiato il default gateway della sede di Como ?
Dato per assodato che prima del cambio della rete tutte e tre le sedi si chiamavano a vicenda e dopo invece no, non penso che il problema sia da ricercarsi nella configurazione della centrale di Como ma nella configurazione della rete. L'unica cosa che potrebbe essere legata alla centrale è la configurazione del default gateway sia del centralino che dell'Hg1500.
Hai provato da Siena a pingare l'indirizzo dell'hg1500 e del centralino di como ?
-
Siena?
Ma non erano Arezzo e Prato?
-
Siena?
Ma non erano Arezzo e Prato?
Sorry ho sbagliato città...
-
La configurazione della centrale non la metto in dubbio, oltretutto ha Como ho portato una nuova centrale che preventivamente avevo provato ad Arezzo. Quindi ho cambiato gli indirizzi e l'ho provata a Como. Esito negativo. Il default gateway non è, da tutte le sedi riesco a raggiungere sia il centralino che HG1500. Mettendo l'indirizzo IP della centrale telefonica al Pc pingo tutte le sedi e vengo raggiunto. quello che mi stranisce è che escudendo il firewall e quindi mettendo un indirizzo Ip pubblico alla HG1500 il risultato non cambia. Esito negativo.
-
La configurazione della centrale non la metto in dubbio, oltretutto ha Como ho portato una nuova centrale che preventivamente avevo provato ad Arezzo. Quindi ho cambiato gli indirizzi e l'ho provata a Como. Esito negativo. Il default gateway non è, da tutte le sedi riesco a raggiungere sia il centralino che HG1500. Mettendo l'indirizzo IP della centrale telefonica al Pc pingo tutte le sedi e vengo raggiunto. quello che mi stranisce è che escudendo il firewall e quindi mettendo un indirizzo Ip pubblico alla HG1500 il risultato non cambia. Esito negativo.
penso che i firewall delle varie sedi facciamo tra di loro delle vpn quindi se metti un indirizzo pubblico alla hg 1500 è giusto che non funzioni
-
...quello che mi stranisce è che escudendo il firewall e quindi mettendo un indirizzo Ip pubblico alla HG1500 il risultato non cambia. Esito negativo.
Scusa ma SE nella sede che manifesta il problema (Como) escludi, come dici, il Firewall per mettere al suo posto direttamente l'HG1500 (che dunque funge da Gateway verso le altre sedi per tutta la LAN che essa gestisce direttamente) significa, sottointendendolo, anche che la fai agire da terminatore VPN ? Io dubito (non è proprio una configurazione semplice da scambio al volo, soprattutto se nelle altre sedi hai altri Firewall e non usi le altre HG1500 come Firewall/Terminatori VPN)...altrimenti non vedo proprio come essa (nonostante tu le imposti un IP Pubblico sulla WAN) possa MAI instaurare una VPN box-to-box con gli altri Firewall coinvolti SE non è configurata per farlo.
Secondo me manca qualche dato congruente riguardo la topologia delle VPN...sono tre sedi con 3 HG1500 che fanno VPN tra loro o 3 sedi che hanno le VPN instaurate grazie a 3 Firewall/VPN terminator ? mi pare evidente la seconda ipotesi...qui c'è qualche cosa di anomalo sul (o sui) Firewall SE sei convinto al 100% che le configurazioni HiPath 3000/HG1500/LCR/CorNet-IP Trunks siano OK.
Saluti, Kimera.
-
penso che i firewall delle varie sedi facciamo tra di loro delle vpn quindi se metti un indirizzo pubblico alla hg 1500 è giusto che non funzioni
Esatto al 100%.
Saluti, Kimera.
-
Ciao a tutti, sono un collega di Zanobini e oggi abbiamo fatto quello che doveva essere l'intervento risolutivo. Io mi sono recato alla sede di Prato e Zanobini alla sede di como. Abbiamo fatto le seguenti prove.
1- telnettare la porta 12062 e 1720 da Prato verso Como, risultato negativo, con wireshark abbiamo visto che arrivano i pacchetti di invite che io invio da prato, ma il centralino non risponde, per cui deduco che è il centralino che scarta il pacchetto, cosa che però non fa se la stessa prova viene fatta dalla stessa subnet di como o da una quarta sede (in cui non c'è un centralino ma è stata usata per fare i test) locata in piemonte.
2- scollegato il centralino dalla rete, assegnato lo stesso indirizzo ip a un pc il quale è stato messo in ascolto con hyperterminal sulle porte 12062 e 1720, telnettato le porte da prato, risultato positivo, per cui è accertato che interrogando da prato l'indirizzo del centralino sulle porte che usa il centralino non ci sono restrizioni.
3- ipotizzato un problema di MTU, per cui tramite ping -l è stata testata la risposta del centralino utilizzando un packet size molto più grande del normale, nessun problema, il centralino risponde a ping lanciati con pacchetti anche di 15000 bytes, scartata anche questa ipotesi.
4- ipotizzato che il centralino possa avere dei problemi (è già stata sostituita 3 volte la hg1500 e una volta il centralino completo), risostituita anche oggi, esito negativo, stesso problema scarta gli invite provenienti da prato e da arezzo, non da locale.
5- Provato a cambiare l'ip address del centralino, esito negativo.
6- Provato a cambiare la porta del signaling, prima con un valore alto (15000) poi con un valore basso (442), esito negativo.
7- Provato a modificare la negoziazione della porta, prima auto, poi 100fdx, poi 10fdx, risultato negativo.
8- provato a cambiare il router della sede di como con un modello diverso (da tiplink a cisco), esito negativo.
9- Spostato l'hg 1500 di como e l'hg1500 di arezzo direttamente su indirizzo pubblico per escludere il firewall e la vpn, le 2 schede si vedono, si pingano ma stesso risultato negativo.
In 8 ore di continui test tutto fa pensare che il problema sia il centralino, ma il centralino è stato testato sulla sede di prato e da li verso arezzo funziona, spostato a como non va più.
Non ne usciamo.
Prego qualcuno che possa avere un'altra idea di farcela sapere, noi le abbiamo terminate...
Grazie a Tutti.
Ciao.
-
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
-
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).
-
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.
-
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.
-
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.
-
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.
Scusa, dovrei bere un caffè prima di risponderti (anche all'altro post)...ma mi viene di getto...SE l'unica cosa che cambi quando sposti il PBX da Prato (dove funziona da/per Arezzo) a Como sono gli IP per (ri)adattarli alla subnet di Como...allora c'è qualche cosa che non va con la parte logica o (1) nell'HG1500/HiPath 3000 o (2) nel Router (o nella ADSL) di Como.
Sul discorso delle porte che sono programmate per fare il Reject o il Drop dei pacchetti entranti bisognerebbe indagare (chi interviene: sempre l'HG1500 a Como o anche il Router a Como). Bevo il caffè poi mi faccio un disegno e vedo di elaborare mentalmente qualche cosa.
Saluti, Kimera.
P.S. Non per essere paranoico...o moderatamente tale...ci dici anche tutte le versioni coinvolte (APS HG1500/HiPath 3000) ? Qualche screenshot dei settings rotte e Network su HiPath 3000 e su HG1500 non guasterebbero per farsi una visione di partenza solida.
-
Grazie Kimera,
Intanto allego schema a blocchi del sistema, cercherò di farmi girare uno degli indirizzi pubblici verso la porta 443 degli hg di Como, di Prato e di Arezzo per avere accesso da remoto, chiaramente sul fw e sui router non ci possiamo entrare. Il router di como è comunque già stato provato a cambiare con un Cisco 877 configurato da me, adesso ci è stato rimesso il loro TP-Link TD8816.
Ti ricordo anche che abbiamo provato a mettere un pc configurato con lo stesso IP, la stessa Subnet e lo stesso Gateway, collegato alla stessa porta fisica del core switch, del HG1500, in ascolto sulle porte 1720 e 12062 e si raggiunge senza problemi.
Appena possibile posterò anche la configurazione dei 3 HG1500.
Grazie ancora e Saluti.
-
Se i default gateway nelle hg e nella centrale sono corrette in tutte le sedi secondo me il problema può essere solo nelle rotte delle vpn. Ma riesci ad accedere via web all'hg di altre sedi da quella di prato ?
-
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.
-
Grazie del suggerimento,
proverò a inserire delle rotte statiche sui 2 hg anche se ti garantisco che nessuna rotta statica è presente sui client delle 2 reti, anche perchè esiste un solo gw per sede e tutti gli indirizzi dei client sono distribuiti dal fw (DHCP server).
Ti farò sapere.
-
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.
-
Io non ho capito se da prato raggiungi via web le altre HG e i centralino con il managerE e viceversa ?
-
10 - ipotizzato il viaggio a Lourdes?
-
Dai Ale, almeno io li faccio risparmiare, ho proposto la benedizione nella chiesa locale.
-
[..]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".
-
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.
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.
-
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.
-
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.
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"
-
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.
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.
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...
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.
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.
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)?
-
[..]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ì!!
-
Lo so che lo sai...non l'ho scritto per te...l'ho scritto per fondare un ragionamento.
-
Lo so che lo sai...non l'ho scritto per te...l'ho scritto per fondare un ragionamento.
ma non l'hai scritto tu....
-
porca miseria...hai ragione...non ho nemmeno guardato se era mio l'intervento...è che ero così sicuro di star scambiando con te i miei pareri che sono andato dritto...aaaaaaaaaa sto diventando vecchio ragazzi miei!
Allora diventa: "Io lo so che lui sa che tu lo sai...l'ha solo scritto per fondare un suo ragionamento"...AAAAAAA
-
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.
-
Stando così le cose è evidente che l'unico imputato al banco è l'HG1500. Sarei curioso di fare un diff sui file di configurazione per vedere tra quella di Como e quella di Prato le differenze significative.
OK, HiPath HG1500 V8 (APS: HI-G15.85.006)...ignoro lo stato (APS) dei due HiPath 3000 V8.
Detto fatto (perdonatemi la formattazione):
diff -y --suppress-common-lines export_como.xml export_prato.xml
Ecco:
172.51.100.1</HostID> | 172.25.100.1</HostID>
02/07/2013 17:18:42</DateAndTime> | 02/07/2013 17:22:37</DateAndTime>
<I_HiPath3000_ID>3</I_HiPath3000_ID> | <I_HiPath3000_ID>1</I_HiPath3000_ID>
<gwHG1500SlotNumber>7</gwHG1500SlotNumber> | <gwHG1500SlotNumber>9</gwHG1500SlotNumber>
<IUTCTime>1360253923</IUTCTime> | <IUTCTime>1360254157</IUTCTime>
<SystemUpTime>32471</SystemUpTime> | <SystemUpTime>131486436</SystemUpTime>
<SystemDateAndTime>02/07/2013 17:18:43</SystemDateAndTime> | <SystemDateAndTime>02/07/2013 17:22:37</SystemDateAndTime>
<SystemIPAddress>172.51.100.1</SystemIPAddress> | <SystemIPAddress>172.25.100.1</SystemIPAddress>
<SystemName>Nodo COMO</SystemName> | <SystemName>Nodo PRATO</SystemName>
<SystemLocation></SystemLocation> | <SystemLocation>Prato</SystemLocation>
<ITraceStartedAt>02/07/2013 17:18:44</ITraceStartedAt> | <ITraceStartedAt>02/07/2013 17:22:38</ITraceStartedAt>
<PActionCurrentTime>1360257524</PActionCurrentTime> | <PActionCurrentTime>1360257759</PActionCurrentTime>
<PActionCurrentTime>1360257524</PActionCurrentTime> | <PActionCurrentTime>1360257759</PActionCurrentTime>
<PActionCurrentTime>1360257524</PActionCurrentTime> | <PActionCurrentTime>1360257759</PActionCurrentTime>
<PnodeID>1</PnodeID> | <PnodeID>2</PnodeID>
<PnodeID>2</PnodeID> | <PnodeID>3</PnodeID>
<PaccClientPassword> </PaccClientPassword> | <PaccClientPassword>4 43 22 56 4 43 21 176 1 131 244 208 5 11
<PCarNodeTabNodeId>1</PCarNodeTabNodeId> | <PCarNodeTabNodeId>2</PCarNodeTabNodeId>
<PCarNodeTabIPAdr1>172.25.100.1</PCarNodeTabIPAdr1> | <PCarNodeTabIPAdr1>172.24.100.1</PCarNodeTabIPAdr1>
<PCarNodeTabNodeId>2</PCarNodeTabNodeId> | <PCarNodeTabNodeId>3</PCarNodeTabNodeId>
<PCarNodeTabIPAdr1>172.24.100.1</PCarNodeTabIPAdr1> | <PCarNodeTabIPAdr1>172.51.100.1</PCarNodeTabIPAdr1>
<PCarCallAddrTabNodeId>1</PCarCallAddrTabNodeId> | <PCarCallAddrTabNodeId>2</PCarCallAddrTabNodeId>
<PCarCallAddrTabCallno>1</PCarCallAddrTabCallno> | <PCarCallAddrTabCallno>7</PCarCallAddrTabCallno>
<PCarCallAddrTabNodeId>2</PCarCallAddrTabNodeId> | <PCarCallAddrTabNodeId>3</PCarCallAddrTabNodeId>
<PCarCallAddrTabCallno>7</PCarCallAddrTabCallno> | <PCarCallAddrTabCallno>8</PCarCallAddrTabCallno>
<PIF1LANIPAddress>172.51.100.1</PIF1LANIPAddress> | <PIF1LANIPAddress>172.25.100.1</PIF1LANIPAddress>
<PIPDefaultRoute>172.51.1.254</PIPDefaultRoute> | <PIPDefaultRoute>172.25.1.254</PIPDefaultRoute>
Mi sono permesso di omettere i veri Nomi assegnati ai Nodi ed i MAC Addresses.
-
Pensa che io, in quel caso, avevo i problemi tra Verona e Romania...
Spostarsi per i vari debug era comodissimo... 8)
-
JaJaJa probabilmente una Romena val bene un SSH disattivato o un Port Forwarding (Web/Manager E) mai attivato! JaJaJaJa
-
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.
-
Allora, esaminando lo schema che è stato fornito e i diff tra Como e Prato e tra Prato ed Arezzo non sembra esserci alcuna anomalia (gli IP Addresses, le Subnet Masks e le Default Routes - Gateway - riportati nello schema sono congruenti con le impostazioni degli XML), ad esempio le CAR Tables indicano:
Nodo 3 (Como)
verso Nodo 1 Call 1xx
verso Nodo 2 Call 7xx
e gli IP dei Nodi 1 e 2 sono corretti (rispondenti a quelli indicati nello schema).
Nodo 1 (Prato)
verso Nodo 2 Call 7xx
verso Nodo 3 Call 8xx
e gli IP dei Nodi 2 e 3 sono corretti (rispondenti a quelli indicati nello schema).
Nodo 2 (Arezzo)
verso Nodo 1 Call 1xx
verso Nodo 3 Call 8xx
e gli IP dei Nodi 1 e 3 sono corretti (rispondenti a quelli indicati nello schema).
Noto che Como e Prato hanno un <PTraceLevel> "EVTLOG" settato a 3 che invece Arezzo l'ha settato a 0 (disattivato).
Mistero...Kezzenger...
Saluti, Kimera.
P.S.
HiPath HG1500 V8 R5.7.3 HI-G15.85.007-003 (25/10/2011) contro HiPath HG1500 V8 R5.6.0 HI-G15.85.006 (15/07/2011)...Kezzenger...HiPath 3000 V8 R7.1.0...Kezzenger!
-
...aggiungere le rotte statiche inutili sugli hg...
Per un mistero degno di Kezzenger ci vuole una soluzione degna di Kezzenger!! ;D
-
Ma tutti stanno puntando il dito sugli hg, ma i parametri di rete del hipath come sono.
Ip, mask, routing?
-
Ma tutti stanno puntando il dito sugli hg, ma i parametri di rete del hipath come sono.
Ip, mask, routing?
Ma infatti io in un post avevo scritto se si raggiungevano sia le hg che i centralini con il manager E... ma per me la cosa strana, se non ho letto male nei post precedenti , è che con l'hyperway funzionava tutto.
-
Ciao,
puoi trovare il piano di indirizzamento in allegato a pagina 2, cmq i centralini sono
Arezzo: HG 172.24.100.1 255.255.0.0, Centralino 172.24.100.2, gw 172.24.1.254 Prato: HG 172.25.100.1 255.255.0.0, Centralino 172.25.100.2, gw 172.25.1.254 Como: HG 172.51.100.1 255.255.0.0, Centralino 172.51.100.2, gw 172.51.1.254.
-
Ripeto. Da ogni sede si raggiunge senza problemi tutti i centralini con il manager E e si raggiunge la pagina di amministrazione dell'hg1500 di tutte le sedi sulla porta 443. Il problema è questo, il centralino di como scarta i pacchetti provenienti da Arezzo e da Prato, non li scarta se provenienti dalla sede di como stessa e da una quarta sede in piemonte. Ps. per rispondere a un post precedente, non si risolve niente neppure con le rotte statiche, non lo sapevo ma Lorenzo il mio collega aveva già provato a inserirle... Ci vorrà lo stregone..??
-
Mi sto quasi appassionando...sembra di leggere la sceneggiatura delle puntate di Lost...questa della quarta sede in Piemonte però mancava all'appello...e giusto per essere insistente...qualcuno può postare gli Screenshots della parte LAN/IP Routing/Firewall settata negli HiPath 3000 V8 ?
E vai...abbiamo tolto di mezzo anche le Static Routes...che infatti non avrebbero avuto motivo di esserci (sempre che i Firewall/Router deputati alle VPN facciano il loro sporco dovere).
Qualcuno si è chiesto se le VPN sono Hub-and-Spoke o cosa ? ed i Router delle 4 sedi fanno (tutti) NAT oppure no ? Sono come quello di Como come gestione degli IP Pubblici ? ...nello schema non sembra.
-
...ma per me la cosa strana, se non ho letto male nei post precedenti , è che con l'hyperway funzionava tutto.
Intendi dire "HyperWay di Telecom Italia (su accessi xDSL) IPrivate / IPrivate Full" ? ...dai...ammettiamolo...qui c'è lo zampino del Tronchetto della Felicità (anzi...di un suo dipendente...o di quello che resta del Tiger Team!).
Saluti, Kimera.
-
ho le configurazioni salvate,le posso postare...?
-
A tuo rischio e pericolo!
JaJaJaJaJa
Saluti, Kimera.
-
le configurazioni le ho già mandate a kimera. Ma a quanto pare non c'è nessun problema da quanto ho capito. Giusto?
-
Io ho controllato solo le configurazioni relative ai moduli HG1500 e come da diff postati (e non) non ho trovato stranezze o differenze significative tali da mettere in evidenza problemi di configurazione nei tre nodi (a parte aver notato che i nodi di Como e Prato hanno un <PTraceLevel> "EVTLOG" impostato a 3 mentre invece il nodo di Arezzo l'ha disattivato, impostato a 0).
Ammetto: devo ancora guardare i KDS dei nodi (forse perchè ho dato per scontato che ci fossero, lato HiPath 3000, meno probabilità di mal configurare il sistema); appena possibile lo faccio.
Saluti, Kimera.
-
Avete provato a configurare (lato HiPath 3000 via HiPath 3000 Manager E) su "Rete" --> "Routing" ANZICHE' le rotte come sono attualmente (dichiarando così le rotte capisco poi perchè la Subnet è dichiarata 255.0.0.0 anzichè essere 255.255.0.0...) ovvero, ad esempio per il Nodo di Como:
| N° | IP Address | Net Mask | Gateway |
| 1 | 172.0.0.0 | 255.0.0.0 | 172.51.1.254 |
| 2 | 172.0.0.0 | 255.0.0.0 | 172.24.1.254 |
| 3 | 172.0.0.0 | 255.0.0.0 | 172.25.1.254 |
così (dove quindi il Nodo di Como vede come Gateway per tutte le rotte non locali il suo unico Gateway che è il Firewall/Router deputato a gestire le VPN):
| N° | IP Address | Net Mask | Gateway |
| 1 | 0.0.0.0 | 255.255.0.0 | 172.51.1.254 |
e provare altrettanto negli altri Nodi ovviamente con le rispettive variazioni dell'indirizzo Gateway.
E l'MTU impostato su 1492 (bit) no ?
Saluti, Kimera.
-
Alla fine...se c'è una fine in questa vicenda...com'è andata?
Saluti, Kimera.