Newsgroup: it.comp.reti.locali
Titolo: Distinguere un vero datagramma HTTP

Da cosa si distingue un vero datagramma HTTP da un datagramma
qualsiasi sulla porta 80? Si puo` vedere dall'header o bisogna per
forza guardare il payload?
Sto cercando di attraversare un proxy/firewall con una VPN configurata
sulla porta 80. Con le prove in dial-up funziona benissimo, ma
attraverso la LAN non passa. :(
Probabilmente il proxy server non la riconosce come una vera
connessione HTTP e non si fa inciuciare, dal momento che non ci trova
dentro nessun URL. :)
Ma i software di HTTP tunnelling in circolazione riescono a forgiare
pacchetti indistinguibili, posto che il tunnel-server non sia bloccato
a monte sul firewall?
Grazie e saluti,
TheLuke

TheLuke ha scritto:

..scusa datagrammi a LVL di rete o a LVL di trasporto?Perche' e' 
quest'ultimo che definisce la porta e non il datagramma del LVL IP che 
ha solo l'indirizzo necessario per l'instradamento(+ altre informazioni).
Per il resto mi sembra arabo vista la mia poca esperienza.
Ciao M.

 ..scusa datagrammi a LVL di rete o a LVL di trasporto?Perche' e' 
Bhe, il problema e` proprio quello di stabilire a che punto i
pacchetti si differenziano in base al protocollo utilizzato, cioe` in
che ordine vengono incapsulati i vari elementi del pacchetto e quali
lo identificano (almeno in apparenza) come HTTP, piuttosto che FTP,
SMTP o altro.
Mi pare di ricordare che i datagrammi HTTP contengano da qualche parte
nell'header la scritta "Mozilla...ecc" o qualcosa del genenre, ma
potrei sbagliare. Inoltre dovrebbero contenere nel payload l'URL di
destinazione.
Poi dipende se negoziano una nuova connessione (SYN_TCP) o se
trasportano solo dati di una connessione gia` attiva.
Molto semplicemente, se il proxy server non riconosce una richiesta di
connessione come HTTP, non aprira` mai una relativa sessione in
uscita.
Ciao,
TheLuke

 forza guardare il payload?
L'header del pacchetto IP contiene il protocollo a livello 5 
a cui riportare il segmento; cioč TCP.
L'header del pacchetto TCP contiene la porta sorgente e la 
porta destinazione ma dalle sole intestazioni non puoi 
sapere cosa passa sulla tua porta 80.
Il problema delle NAPT box č che molti protocolli 
incapsulano nel payload informazioni che sono necessarie per 
una corretta traslazione del pacchetto (vedi ad esempio 
ICMP)... di conseguenza le implementazioni di NAPT (ad 
esempio MASQUERADE) *devono* saper parlare i protocolli 
applicativi.
Ora tu dici di dover attraversare un firewall che fa anche 
da proxy, non parli di NAPT; molti software comunque aprono 
i pacchetti a livello applicativo (guardano cioč il payload) 
per fare ciň che devono...
Tu hai un proxy o una NAPT?
E che proxy?
Ciao

 da proxy, non parli di NAPT;
Un po' in ritardo ma riprendo il thread. ;)
Si, ovviamente e` anche un NAPT, deve mappare una rete 10.x.x.x verso
Internet, quindi ha bisogno delle informazioni per traslare i
pacchetti correttamente.
L'unico modo quindi e` "forgiare" dei pacchetti HTTP consistenti, come
fanno ad esempio i software di HTTP tunnelling.
BTW, ora il "famoso" HTTP-Tunnel e` diventato solo a pagamento, ma
suppongo esistano in circolazione suite client-server per crearsi un
HTTP tunnel personale.
Saluti,
TheLuke