Saro’ lamentato aalungamente, discusatemi.
Questa la mail ricevuta ieri con carattere di URGENZA:
abbiamo bisogno di un trouble shooting, la connessione non funziona.
Ecco l’output del telnet effettuato sulla porta 10443:
14:53:43.337249 webmail1.posta.PORCO.it.35869 > fecoll48.10443: S 1792424435:1792424435(0) win 24820 (DF)
14:53:43.337282 fecoll48.10443 > webmail1.posta.PORCO.it.35869: S 1317604646:1317604646(0) ack 1792424436 win 5840 (DF)
14:53:43.338622 webmail1.posta.PORCO.it.35869 > fecoll48.10443: P 1:17(16) ack 1 win 24820 (DF)
14:53:43.338635 fecoll48.10443 > webmail1.posta.PORCO.it.35869: . ack 17 win 5840 (DF)
14:53:43.338639 webmail1.posta.PORCO.it.35869 > fecoll48.10443: P 17:19(2) ack 1 win 24820 (DF)
14:53:43.338645 fecoll48.10443 > webmail1.posta.PORCO.it.35869: . ack 19 win 5840 (DF)
14:53:43.338885 fecoll48.10443 > webmail1.posta.PORCO.it.35869: P 1:605(604) ack 19 win 5840 (DF)
14:53:43.338897 fecoll48.10443 > webmail1.posta.PORCO.it.35869: F 605:605(0) ack 19 win 5840 (DF)
Saluti,
Roberto.
=======
Noi rispondiamo cosi’:
Non so quali siano gli indirizzi ip, al di la di questo, tutto funziona no?
Il problema e’ evidentemente applicativo, il firewall ti fa passare e il routing e’ corretto.
=======
e LUI NO.. PERCHE’ LUI NE SA EH.
Scusate ma l’output è relativo al telnet
(la domanda era :”Roberto puoi chiedere di fare, dal server 213.230.128.226 un telnet alla porta 10443 dell’ip 10.6.128.107 e darmi l’output?”)
il flusso del servizio è in HTTPS.
QUINDI PER LUI NON FUNZIONA
e NOI RISPONDIAMO PORCO IL TUO DIO INFORMATICO CHE TI HA MESSO LI:
Francesco,
tanto per capire bene. Il servizio e’ in HTTPS sulla porta 443 o sulla porta 10443?
se il servizio e’ sulla porta 443 allora abbiamo bisogno di una prova di telnet verso quella porta, se al contrario (come penso) la porta e’ la 10443, lo snoop di Roberto evidenzia come la comunicazione tra il server e il client sia completa a livello TCP, Gli apparati Firewall non agiscono a livello applicativo, cio’ significa che se riuscite a fare un telnet su quella porta (ovviamente basta la risposta connect visto che il telnet non e’ un applicativo HTTPS) allora significa che tra il client e il server la comunicazione e’ completa. Almeno possiamo dire questo fino al livello 5 della scala ISO/OSI, i livelli superiori al 5 sono competenza dell’applicativo e quindi controllabili solo dal responsabile dell’applicativo.
MA LUI ANCORA NIENTE EH… E’ COLPA NOSTRA.
e allora risponde
spiacente ma non concordo
l’applicativo entra in gioco quando non gestisce i flussi/input che gli arrivano
se il tcp dump è stato fatto correttamente, all’applicativo non arriva nulla (il trace è vuoto) e quindi correttamente la piattaforma non risponde nulla.
la connessione a livello TCP non basta per la corretta fruizione del servizio ovvero la comunicazione tra client e server la definirò completa quando ci sarà connettività HTTPS (anche se non correttamente gestita dall’applicativo)
CHE CAZZO VUOL DIRE???? COSA e’ FLUSSI/INPUT???? COSA e’ IL TRACE????
CONNETTIVITA’ HTTPS????? CHE CAZZO SIGIFICA COGLIONE:
al che LEZIONE DI INFORMATICA.
mi spiace che non concordi, e allora cerchiamo di arrivarci con la teoria.
Stiamo parlando della comunicazione tra il client A e il server B. Tale comunicazione agisce attraverso la connettivita’ IP su protocollo TCP su porta 10443 (che sia HTTPS o smtp o FTP al firewall puo’ importare nulla a meno di controlli a livello applicativo che cmq non effettuiamo).
Analizziamo quindi i vari livelli
lasciamo un attimo stare il livello 1 e 2 della scala ISO/OSI dato che uno e’ connettivita’ fisica (il cavo di rete che sembra funzionare) e l’altra connettivita’ logica (MAC Address e ARP request) che anche queste vanno.
a livello ip (livello 3 ISO/OSI) come puoi vedere i due server si raggiungono, dato che esistono sul client i pacchetti di ritorno (cio’ implica che il routing e la connettivita’ quindi siano corretti), spero converrai.
a livello TCP (livello 4 ISO/OSI) la comunicazione e’ evidenziata dalle flag
come vedi il pacchetto 1 e’ il SYN, il 2 e’ il SYN-ACK del server (che significa che la porta 10443 ha risposto alla connect)
il pacchetto 4 e’ il PUSH del client, i pacchetti 4 6 sono gli ack del server, e il 7 e’ il push del server, dopodiche’ il server manda un FIN (il client a questopunto continua i suoi ack che evidentemente ancora non erano arrivati con i pacchetti 9 e 10 e poi risponde con il FIN-ACK al server e il server risponde un ack.
Questo e’ un flusso TCP completo.
Dentro ogni ack (e ogni push) esiste una parte del pacchetto chiamata parte dati dove realmente i dati transitano.
Il Firewall si ferma qui.. non controlla la parte DATA del pacchetto. Cio’ implica che se avessimo un problema di firewall la comunicazione verrebbe interrrotta gia’ a questo punto, mentre come vedi e’ completa.
Cio’ implica che la comunicazione se non funziona non e’ completa a livello applicativo (livelli 5/6/7 della scala ISO/OSI).
Questo significa che dovreste controllare le richieste HTTP (e non TCP/IP) che arrivano sul client come risposta, e vedrete che troverete qualche anomalia.
Spero sia chiara la spiegazione
PORCO DIO. LUI CONTINUA EH.. MICA CAPISCE CHE e’ UN POVERO IGNORANTE, MESSO LI A RUBARE SOLDI ALLA COMUNITA’ PORCO IL SUO TELNET.
Dalla mail di Cipolleta (wget effettuate con successo) sembra che non vi siano anomalie sul sw in collaudo.
Non ho mai detto che era colpa del firewall ma semplicemente che la connettività HTTPS non c’e’
(il Telnet e la connettività TCP sono condizioni necessarie ma non sufficienti)
Stiamo facendo ulteriori verifiche.
INTANTO GIA’ CHE HAI UN AMICO CHE SI CHIAMA CIPOLLETTA HAI PERSO.
ma poi PORCO DIO PERCHE’ SCRIVI A ME E MI FAI PERDERE TEMPO.
DIO E’ UN POSTO BRUTTO, CHI CI CREDE PUZZA.
