Apertura porte

Pubblicità
Stato
Discussione chiusa ad ulteriori risposte.
E

Enigmisth

Utente Attivo
Messaggi
705
Reazioni
20
Punteggio
60
Buongiorno,

Ho un server con un software che comunica con i client tramite le porte TCP 13000 / 14000 e UDP 15000 . Tra il server e i client ci sono solo degli switch, i firewall di windows e antivirus sono disattivati.

Devo capire SE il client riesce a usare le porte TCP e se il server riesce a usare la porta UDP. In caso non riesca devo aprirle.. le TCP credo che vadano, sono le comunicazioni dal server al client che falliscono tutte quindi credo che la UDP sia bloccata.

Sapete aiutarmi a capire come fare?!
 
da un ipsterno (potresti usare un cell con hspot)esegui da prompt-msdos "telnet ippubblico portatcp"....se si connette diventa tutto nero.
per l'udp dovrai usare un telnet Linux capace di usare udp
 
l'udp e quello che mi interessa di piu verificare. Puoi essere un pò più preciso sui passaggi da fare? ricordo comunque che sia server che client sono sulla stessa rete e c'è solo uno switch... quindi non so neanche che cosa possa bloccare la porta. Windows forse?
 
no scusa avevo frainteso volessi testare l'apertura delle porte dall'esterno del router, da internet per farla breve...se lo devi fare dalla rete interna esegui i comandi di cui parlo dai client, ma devi essere pratico di telnet e connessioni...
taso windws+r nella riga "esegui" scrivi cmd e invio
telnet ipdelserver 13000 e invio
se la schermata diventa nera la porta è reattiva
 
La porta sul client... quindi significa che riceve. E dal server posso mandare un pacchetto di test al client tramite cmd?
 
col client telnet di Windows no, ma con quelli *nix si....
chiedi qualcosa che necessita studio, puoi anche usare nmap, e specificare il -U ma ci sono tanti modi...puoi anche fare u netstat -na sul server per vedere lo stato della porta e vedere chi la gestisce...insomma chiedi qualcosa che necessita supporto
 
raulico ha detto:
no scusa avevo frainteso volessi testare l'apertura delle porte dall'esterno del router, da internet per farla breve...se lo devi fare dalla rete interna esegui i comandi di cui parlo dai client, ma devi essere pratico di telnet e connessioni...
taso windws+r nella riga "esegui" scrivi cmd e invio
telnet ipdelserver 13000 e invio
se la schermata diventa nera la porta è reattiva
Clicca per espandere...

telnet su windows 7 non funziona, mi dice che il comando non è riconosciuto. Ho provato anche ad avviare cmd come amministratore.
Ho provato anche ad usare Putty e collegarmi in telnet in direzione del server ma nulla

raulico ha detto:
col client telnet di Windows no, ma con quelli *nix si....
chiedi qualcosa che necessita studio, puoi anche usare nmap, e specificare il -U ma ci sono tanti modi...puoi anche fare u netstat -na sul server per vedere lo stato della porta e vedere chi la gestisce...insomma chiedi qualcosa che necessita supporto
Clicca per espandere...

Non può essere cosi difficile testare una post su :D
Facendo netstat -na sul server vedo la UDP 0.0.0.0:13000 e ok, il problema credo sia sul client. Eseguendo lo stesso comando non la vedo.

Il Firewall di Windows è disabilitato da servizio
 
telnet su windows 7 non funziona...
forse lo devi installare tra i componenti aggiuntivi di windows...di default non c'è...motivo della risposta di errore da cmd..vai su installazione-componenti aggiuntivi...
sei capace di creare un pacchetto per il test udp, penso di no...allora usa nmap che lo fa per te e studi solo come usarlo :-) (si capisce che sono pro-studio? :-)
non ti serve provare il client, in quanto la porta in uscita(lato client) non "dovrebbe" essere filtrata, ma dubito di tutto...
l'importante è che il server abbia reattività e quindi servizio sul protocollo interessato
 
Kaspersky security center lancia i comandi sul client tramite porta UDP 13000, quindi si sul server c'è attività su quella porta e il netstat -na lo conferma. Il problema e che i client non recepiscono per quello chiedevo il come controllare/aprire sul client la porta UDP.

Di certo non sto mettendo in dubbio che il tuo studio sia stato importante, dicevo solo che io devo testare una piccola cosa non fare una rete da zero.. non sono completamente a digiuno lavoro nel settore quindi penso di riuscirci con qualche indicazione sul come ^_^
 
attento a kaspersky, perché controlla lo stack e si prende in mano anche la gestione del firewall....è un buon antivirus, ma... anche se tra i migliori...
ahinoi con l'udp in quanto connectionless puoi fare poco, e nel client, per protocollo non serve la porta aperta, in quanto in risposta alla prima fase di connessione, il client propone risorse in base alle sue potenzialità.
la mia provocazione (bonaria spero) nasce dal fatto che ti ho dato degli spunti per poter eseguire un troubleshooting del problema, ora a te stabilire come muoversi e dove approfondire :-)

ps, il sorgente per l'installazione di kaspersky lo hai creato dalla console centrale???
se lo fai da lì, eviti la customizzazione sui client e ti ritrovi tutto gia impostato...però i client avranno poca libertà d'azione in quanto semi-blindato...
sto iniziando a capire dove hai il problema :-)
 
Ultima modifica:
Si certo il pacchetto è creato da console e contiene il client e il network agent. Su console ho dei criteri con tutte le impostazioni che comandano i vari client, il problema e che quando modifico il criterio la console propaga la modifica ai client su porta UDP 13000 ma l'attività rimane in stand by perchè i client non recepiscono.
Poi dopo un tot di tempo comunque si sincronizzano perchè il network agent, del client, è impostato per recuperare informazione tramite porte TCP a cadenza periodica.

Il firewall di windows è disabilitato da servizio, e quello di kaspersky è disabilitato da criterio. Sul server il netstat -na visualizza la porta 13000 mentre sul client no...

Comunque tu mi hai detto di usare nmap, sul server, e mandare un pacchetto sulla UDP corretto? ok mettiamo caso sia chiusa... può essere chiusa causa windows?
 
Ti possono dire tutte le inesattezze che vogliono, il protocollo UDP non è testabile se non con l'applicazione che lo usa, telnet non lo fa, nmap dice che lo testa usando un trucco ma non ci riesce.

Non è cattivaria ma essendo un protocollo senza sessione, non c'è modo, solo l'applicativo sul client sa se gli è arrivato qualcosa.

Se sul client non c'è un processo in listen sulla 13000 ovviamente non riceve nulla.

Ci deve essere un processo (di solito) 0.0.0.0:13000 in listen.
Se non c'è, il programma applicazione o non è attivo o non è nella condizione di ricevere, o non gli è stato detto di farlo, perchè semplicemente non ha fatto la OPEN.

Non ho capito l'attività sul server sulla 13000, se la porta è in listen non c'entra nulla, se la porta è in uscita si.

La frase:
propaga la modifica ai client su porta UDP 13000 ma l'attività rimane in stand by perchè i client non recepiscono.

non può funzionare così, nel protocollo UDP uno manda e basta, non può sapere (da protocollo) se l'altro è vivo, sta ricevendo o ha ricevuto, per saperlo o si usa un socket tcp a parte per il controllo del traffico udp, o tramite una risposta/messaggio separato dal client.
 
Ultima modifica:
Se la documentazione è corretta, e se la varie personalizzzioni sono congrue (presumo che le porte siano cambiabili) ripeto:

Se col comando netstat -ln sul client non si vede mai la porta 13000, vuol dire che nessuno la ha aperta.

Come e se il programma gestisce "il ricevuto" non lo so, di solito le porte udp vengono usate dove si preferisce un protocollo più efficente del tcp e dove non serve avere un check sul ricevuto, se no tanto valeva usare una porta tcp.
 
Ultima modifica:
Stato
Discussione chiusa ad ulteriori risposte.
Pubblicità
Pubblicità
Indietro
Top