ARGOMENTO:

Salve,
la questione nasce da un problema che ho rilevato sulla mia rete locale e riguarda il funzionalento del servizio di File Transfer Protocol tra due miei computer che stanno sulla stessa rete.
Il servizio viene espletato correttamente se indico al client di connettersi al server attraverso l'indirizzo privato del server, quindi quando i messaggi restano sulla lan e non interessano tratti WAN o internet che si voglia dire.
Se invece faccio accuisire ai due computer un indirizzo pubblico (pppoe) attraverso il quale per esempio navigare in internet e comunque accedere agli indirizzi che non fanno parte della mia lan (non attraverso NAT ma direttamente ogni computer con il suo ip pubblico) tutto funzionava egregiamente e riuscivo ad ottenere il servizio anche attraverso la internet (WAN) dando al client come indicazione l'indirizzo del server l'indirizzo pubblico; ho scritto riuscivo perche dopo un paio di giorni che trasferivo con successo i files attraverso la internet misteriosamente le cose sono cambiate e non sono piu' riuscito a far funzionare nulla, allora ho messo sotto monitoraggio i messaggi che arrivano e partono dai due computer ed alla fine grazie anche alle indicazioni di altra gente abbiamo ipotizzato che qualcuno abbia attivato delle ACL che operano in un qualche modo sule mie connessioni.
Ma le ACL quando riscontrano un deny dovrebbero semplicemente scartare un pacchetto e non inoltrarlo invece a me succede che il pacchetto viene inoltrato con 20 secondi di ritardo ed a me questo non pare essere un comportamento attribuibile alle Access Control List.
Metto delle figure che sono le sintesi dei tracciamenti, la prima e' il tracciamento su LAN dove con gli indirizzi privati e locali le cose vanno bene,





la seconda sono i tracciamenti ottenuti su server e client quando il servizio viene richiesto atraverso gli ip pubblici,






notate che il terzo messaggio che parte dal client messaggio contrassegnato con un asterisco non arriva subito al server ma arriva dopo 20 secondi, in quei venti secondi c'e' uno scambio di messaggi (quelli scritti in arancione di cui due sono droppati e sono i messaggi 15 e 18 emessi dal client e non arrivano al server, mentre arriva solo dopo 20 secondi quando ormai e' troppo tardi.
Quindi la mia domanda e': se e' come qualcuno ipotizza e cioe' che questo comportamento sia dovuto a delle ACL e quindi ad una parzializzazzione voluta al traffico secondo voi e' normale che invece di droppare direttamente gia' il primo pacchetto queste presunte ACL operino ritardando solo alcuni messaggi droppandone altri ed infine trasferirne solo uno dopo 20 secondi?
Vi ringrazio dei commenti e dei contributi che saprete dare in sintesi la questione e' come operano le ACL, droppano o ritardano, oppure le liste sono cosi lunghe =D o i filtri cosi complicati da richiedere 20 secondi per elaborare la richiesta =D?

Ci sono evoluzioni, adesso il difetto e' cambiato e tutto pare piu' evidente, considerate che gli orologi che hanno marcato i messaggi hanno una differenza di quindici secondi. Secondo me c'e' una qualche entita' in mezzo che modifica e ritarda i messaggi, difatti c'e' per esempio il messaggio di RST reset che non e' stato mai originato e se osservate il messaggio di FIN ed il relativo ack stanno solo da un lato, e' come se sia il client chem il server stessero dialogando con una terza entita', che sia questo un esempio di MAN IN THE MIDDLE che si e' guastato e funziona male?

Ciao Roberto,
bentornato

Qui il problema non riguarda in alcun modo le ACL: esse infatti, se fossero presenti, bloccherebbero o permettterebbero il traffico senza manipolazioni aggiuntive. Quello che invece mi sembra stia succedendo è legato piuttosto a questioni di congestione, ove quei pacchetti subiscono ritardi maggiori di altri. Ad esempio, nello weighted queueing della Cisco, si prediligono i pacchetti piccoli a dispetto dei grandi (l'FTP in questo senso ci starebbe a pennello). Ci sono veramente tanti modi per fare QoS, e sarebbe difficile capire quale sia realmente implementato senza avere sottomano la rete in questione. Diciamo però con assoluta certezza che, a prescindere dalle tecnologie implementate nel transito dal tuo PC al server, di sicuro ciò che avviene non è imputabile ad ACLs.

Un saluto,
Jody

Ci sono importanti novita' delle quali parlero' alla fine di questo post ma prima alcune considerazioni:
concordo con Jody sul fatto che una tale "modifica sistematica" dei messaggi tra client e server non sia il frutto dell'applicazione di un processo di ACCESS CONTROL LIST che, appunto come mi ricorda e conferma Jody, opera solo droppando (cancellando) i messaggi.
Non concordo con Jody quando ipotizza che tale comportamento strano si possa attribuire ad una sorta di weighted queueing della Cisco che dovrebbe giustificare un ritardo di circa venti secondi sull'inoltro di un messaggio di solo ACK molto breve (payload zero) (venti secondi!!), mentre tale weighted queueing della Cisco opera mettendo in coda a bassa priorita' i messaggi piu' lunghi e comunque l'effetto di una tale azione (ritardo di venti secondi)non e' sistematica ma e' dinamicamente legata al carico ed al traffico, poi la domanda che sorge spontanea e' anche questa: quale e' la dimensione fisica di un buffer che possa supportare e bufferizare 20 secondi di traffico se facciamo qualche conto ci vera' una dimensione molto grossa .
La novita' e' questa: sostituendo il modem telecom italia con uno reperito dai miei vecchi modem adsl usati in passato il problema scompare , tutto funziona perfettamente come dovrebbe.
Importante e che teniate presente che ambedue i modem sono configurati per operare solo in bridging mode, nel senso che, come ben sappiamo, i bridge (e switch) dovrebbero solo trattare i messaggi switchandoli sulla base degli indirizzi mac, mentre c'e' evidenza dai tracciamenti che in qualche modo la funzionalita' del modem telecom si "estende" (a mio parere impropriamente) ad analisi e trattamenti dei messaggi in transito al di fuori di quelle che sono le sue attribuzioni e competenze, insomma il modem telecom opera in ambiti nei quali non dovrebbe operare e per i quali e' stato predisposto da me. L'azienda telecom utilizza un sistema di telegestione con il quale puo' fare varie operazioni sul modem che a noi utenti non e' dato conoscere, e puo' anche aggiornare il firmware, tra le altre cose ho verificato che dopo i continui reclami fatti a telecom adesso il modem ha anche cambiato interfaccia utente e funzionamento e non mi consente piu' di predisporre il funzionamento in modalita' mista (BROUTER); la modalita' mista di brouting consente di avere sulla stessa lan sia un accesso ip attraverso un default gateway e NAT che anche contemporaneamente ad una sessione PPPOE quando il protocol type indicato nel campo type di livello 2 (ethernet) e' uguale a 0x8864, col passare del tempo, e ritengo in conseguenza degli aggiornamenti ATTUATI ATTRAVERSO LA TELEGESTIONE del firmware del modem, e' sparito dalle videate il pulsante che mi consente di attivare la funzionalita' di routing e di nat, insomma per me e' evidente che ci vuole un esorcista che scacci un qualche demonio che si e' impossessato del modem, e poi ci voglia un qualche buon guardiano che sorvegli che le operazioni di aggiormaneto del firmware del modem avvengano legittimamente e correttamente.

E' molto difficile fare un'analisi di una situazione complessa come questa via forum, tuttavia due aspetti possono guidarti per approfondire la questione:
1. Le ACL droppano o permettono, non ritardano
2. Per ritardare entra in gioco la QoS ed effettivamente con policy du Weight Fair Queue i pacchetti burst come FTP vengono ritardati, anche se 20 secondi di ritardi mi sembra un tempo anomalo.

un ritardo di 20 secondi e' da "galera all'antica" , comunque come ho scritto e' qualche impostazione sul moidem che viene fatta attraverso la telegestione, sostituendo il modem con uno stupido bridge tutto funziona come dovrebbe funzionare.
Col tempo vi faro' sapere, tanto io il problema l'ho risolto, resta solo indagare sul passatro remoto.
Grazie per aver considerato ed analizzato il fatto.