[Linuxtrent] Re: Idea per nuovo progetto: IP-Multiplexer
- From: Mattia Merzi <merzi@xxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Thu, 17 Apr 2003 09:13:14 +0200
Dopo aver sottoposto questo thread ad una delle ml del FerraraLUG
(e dopo averci dormito sopra) riassumo qui quanto e' stato discusso.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
On Tuesday 15 April 2003 15:41, Matteo Ianeselli wrote:
> Una cavalletta salita sulla tastiera di Daniele Nicolodi ha scritto:
> > Mi sa che é giunta ora che mi compri TCP/IP Illustrated...
>
> Guarda, l'idea di fondo non e` fantascienza.
>
> Supponiamo per semplicita` di non avere a che fare con la
> frammentazione (che complica le cose), e che di mezzo ci sia solo
> ethernet.
una semplificazione ammissibile, il gateway può eseguire la
deframmentazione sul traffico da internet e sulla LAN non
dovrebbe avvenire se non ci sono implementazioni bacate...
> Linux fa "masquerading" (PAT) delle connessioni TCP basandosi sul
> numero di porta: ricorda chi dall'interno ha fatto una certa richiesta
> verso l'esterno (ovvero segnandosi IP e porta sorgente), ripropone la
> richiesta con un indirizzo e un numero di porta sorgente modificato, e
> quando arriva indietro la risposta sulla stessa porta la rispara
> indietro modificando indirizzo di destinazione e porta rimettendoci
> quelli che erano stati modificati.
> Se non sbaglio, poi, il normale routing provvede ad instradare il
> pacchetto di ritorno sull'interfaccia giusta.
ok.
> Ora, supponiamo che il kernel si ricordi, oltre a porta e indirizzo IP
> originario, anche il MAC address e l'interfaccia di provenienza, e
> quando arrivano le risposte scavalchi il normale routing e riproponga
> direttamente sull'interfaccia di provenienza il pacchetto, con
> destinazione il MAC address, indirizzo IP e numero di porta salvati.
qui casca l'asino...
diciamo che A sia il computer che ha un IP qualunque sulla LAN e G
il gateway che instrada verso internet e fa la traslazione di
indirizzo.
Quando un'applicazione su A vuole connettersi con qualcosa che sta
su internet, diciamo con il server S, prima di tutto consulterà la
propria tabella di routing. Se S non è routabile semplicemente non
ci proverà nemmeno.
Siamo quindi ottimisti, e diciamo che nella tabella di routing di A
ci sia scritto: 127.0.0.1 sono io, tutti gli altri si raggiungono
tramite il gateway 1.2.3.4 (un indirizzo a caso).
A questo punto A si chiederà come si fa a raggiungere 1.2.3.4.
Se non è routabile (dev'esserci un'altra regola di routing)
allora non ci proverà nemmeno e siamo da capo.
Siamo di nuovo ottimisti e diciamo che esista una regola di routing
che dice che 1.2.3.4/NM è direttamente connesso sulla eth0 (NM è la
netmask, che diciamo che in questo momento non ci interessa).
Ora A cercherà di associare un MAC address all'indirizzo 1.2.3.4,
quindi con il protocollo ARP manderà un broadcast sulla LAN,
chiedendo "chi ha l'IP 1.2.3.4?".
Se siamo sfortunati risponderà B (un altro client sulla LAN)
dicendo "ce l'ho io, il mio MAC è MAC-B".
A si fiderà e cercherà di inviare i pacchetti successivi a B, che
naturalmente non avrà nessuna voglia di instradarli, quindi non
funzionerà un tubo.
Diciamo che non va così male, nessuno sulla LAN ha 1.2.3.4, allora
G vedendo il browser ed essendo istruito appositamente potrebbe fare
finta e dire "ce l'ho io, e il mio MAC è MAC-G".
A questo punto A inizia a mandare i pacchetti a G, il quale li
instrada e fa tutti i manini del caso come descritto sopra, così
la connessione TCP può instaurarsi e funzionare.
Però nel frattempo tutti gli altri PC sulla LAN avranno visto l'IP
di A e l'1.2.3.4, e li avranno segnati nella loro ARP cache.
Così che se A ha un indirizzo pubblico su internet, ora B non sarà
più in grado di raggiungerlo (pensando che sia direttamente connesso
sulla LAN e quindi non provando nemmeno a coinvolgere G).
Di più, siccome G deve rispondere alle richieste di risoluzione ARP
sempre e comunque (per qualunque coppia MAC richiedente e IP richiesto)
ne consegue che sulla LAN succederà un casino e le cache di tutti i
client si annoderanno come un piatto di spaghetti, con il risultato
che come minimo A non sarà in grado di vedere B e viceversa.
Notare come tutto questo sia indipendente dalla configurazione e
dalle capacità del gateway G. Purtroppo (per fortuna?) ethernet è
(almeno dal punto di vista logico) una rete broadcast e richiede la
collaborazione di tutti quanti coloro che vi si affacciano perchè se
uno inizia a comportarsi in maniera fuori standard tutti quanti si
disorientano.
Inoltre, indipendentemente da quello che può fare G, i client sulla
LAN hanno diversi parametri oltre all'IP (gateway, netmask, etc), che
devono essere configurati affinchè tali client possano funzionare.
> E se non capisco male (dal discorso sugli switch fatto qualche tempo
> fa) ci sono apparecchi in grado di "taggare" un frame ethernet
> proveniente da una certa porta di N porte, e di instradare verso
> quella stessa porta i frame di ritorno taggati con lo stesso tag.
falso.
non taggano niente e non ricevono nessun tag (nell'header 802.3 aka
ethernet non esiste nemmeno un bit a disposizione per trasportare
questo tag) semplicemente si segnano internamente la topologia man
mano che vedono passare i frame... si chiamano switch.
Commenti ?
Mattia.
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts: