Da MAC Address a IP Address

[nuovoUtente86]

Originariamente inviato da lupin 3rd

come di router non se ne parla?

di router non se ne parla, o meglio (per essere più corretti), se ne parla nella misura in cui l' host specifico genera traffico diretto ad internet, alis viene effettuata una richiesta al gateway

forse non ti è molto chiara la comunicazione all' interno di una rete come avviene:

veramente pensi di poter disquisire con me (o insegnare) di reti... no non ci siamo, ma andiamo avanti, giusto per fare due risate.

nel momento in cui devo comunicare con un pc all' interno della rete locale devo sapere il suo indirizzo mac perchè il sistema operativo dovrà partire dal livello più alto fino a quello data-link in cui metterà l'indirizzo mac di destinazione...dopo di che consegnerà i frame data-link alla scheda di rete che si occuperà di trasmetterli tramite il cavo di rete in segnali binari;quando i pacchetti arrivano al router questo prende l' indirizzo ip di destinazione e fa il confronto con la subnetmask,in particolare fa l' operazione di end fra i bit...se il valore dell' end è lo stesso della subnet mask convertita in binario,allora l' ip di destinazione appartiene alla rete locale,viene trovata la corrispondenza nella arp cache ,il router converte in frame e questi vengono inviati al pc di destinazione;se invece l'ip non appartiene alla rete locale,il router(nel caso di una rete domestica)invia il pacchetto al router dell' isp e poi questo verrà instradato in base agli algoritmi di routing;lo scopo del pc di sapere il mac del pc di destinazione è quello nel caso in cui in una rete non c'è un router ma solo uno switch;in questo caso lo switch legge il mac di destinazione del frame e lo inoltra alla rispettiva porta;è cosi che funziona soprattutto perchè in molti casi per risparmiare il lavoro ai router nelle reti locali vengono usati gli switch come smistatori(in modo che al router giungano solo i pacchetti destinati all' esterno)...

Analizziamo quello che dici, ovvero che ogni pacchetto, sia esso destinato ad un indirizzo locale che remoto, viene inviato al router e da questi consegnato poi all' host specifico (o inoltrato ad un altro router). No le cose non funzionano esattamente cosi.
Quando un pacchetto ip è pronto per essere inviato, si effettua l' anding (ne hai sentito parlare, senza capire bene il momento e il posto in cui viene effettuato) tra l' indirizzo ip destinazione e la maschera di rete dell' interfaccia di uscita. Se il match è positivo si effettua una seziona arp (avente come obiettivo del mapping l' ip destinazione) al fine di ottenere l' indirizzo fisico della macchina per potergli consegnare il frame. Se,viceversa, il confronto fallisce, occorre (in questo caso si) fare capo al gateway che provvederà all' inoltro dei pacchetti attraverso reti remote.
Il tuo ragionamento astruso, ha inoltre 3 buchi clamorosi:
-mancherebbe il modo di indirizzare fisicamente il router
-le reti punto-punto, hubbed e switched non funzionerebbero senza la presenza di un router
-la presenza di un router/gateway è trasparente agli host (l' impostazione default gateway è ininfluente) che conoscono solo la propria subnet.
Per cui, in defnitiva, la arp cache di un router contiene i mapping di quegli host che hanno (o hanno avuto al timeout) connessioni attive sulla internet.
Ma andiamo avanti

è quello nel caso in cui in una rete non c'è un router ma solo uno switch;in questo caso lo switch legge il mac di destinazione del frame e lo inoltra alla rispettiva porta;è cosi che funziona soprattutto perchè in molti casi per risparmiare il lavoro ai router nelle reti locali vengono usati gli switch come smistatori(in modo che al router giungano solo i pacchetti destinati all' esterno)...

switch e router non sono dispositivi intercambiabili a piacere, e senza fare troppe discussioni, lo si può vedere dalle definizioni formali : uno switch è un dispositivo datalink in grado di dividere i domini di collisione, un router (livello rete) segmenta i domini di broadcast.

adesso,a parte il fatto che io ho provato ad avviare wireshark sul pc fisso e ad inviare un file al portatile e ho sniffato solo pacchetti smb e arp e quindi nessun pacchetto rarp,mi spieghi poi a cosa servirebbe in tutto il discorso che ti ho detto il protocollo rarp?

come volevasi dimostrare non sai cosa vuol dire supportare un protocollo, nonostante lo abbia spiegato nel post precedente. Significa semplicemente che producendo una richiesta a quel protocollo, ne riceverò (eventualmente) risposta o almeno lo staack è in grado di processare la richiesta stessa. Ciò non vuol dire che sulla rete transiti obbligatoriamente quel tipo di traffico. Per altro su una rete switched il rarp non è sniffabile in quanto circola in unicast.

e anche avendo un piano di indirizzamento statico mi spieghi come faresti a risalire al mac anche a pc spenti? al max potresti usare le entry del dhcp server sempre che questo renda visualizzabile l' associazione ip locale-mac

qui in networking non c' entra nulla, è solo questione di logica : se ho assegnato tutti gli ip tranne uno, a meno di overlapping e spoofing, l' ip utilizzato sarà l' unico disponibile.

[nuovoUtente86]

e giusto per essere precisi

end fra i bit...se il valore dell' end è lo stesso della subnet mask

l' operazione binaria si chiama and e non end (fine). Inoltre il risultato prodotto dall' anding tra destination ip e subnet mask è confrontato con il subnet address e non con la maschera (e del resto non avrebbe senso).

[Spectrum7glr]

Originariamente inviato da nuovoUtente86

Il protocollo rarp,che fa parte del livello datalink, è obbligatorio per chiunque implementi uno stack TCP/IP, in quanto costituisce il mezzo inverso alla risoluzione arp.

occhio che non è propriamente così: il RARP non è l'InARP (che tra l'altro è roba da frame realy)...il RARP serve ad uno scopo differente che è quello di ricavare il proprio IP a partire dal MAC e la richiesta viene esaudita se e solo se sulla rete c'è un server che tratta questo genere di richieste (nessun host "comune" risponde ad una rarp request: l'host fa la richiesta ed un server se dipsonibile risponde).

[nuovoUtente86]

Originariamente inviato da Spectrum7glr

occhio che non è propriamente così: il RARP non è l'InARP (che tra l'altro è roba da frame realy)...il RARP serve ad uno scopo differente che è quello di ricavare il proprio IP a partire dal MAC e la richiesta viene esaudita se e solo se sulla rete c'è un server che tratta questo genere di richieste (nessun host "comune" risponde ad una rarp request: l'host fa la richiesta ed un server se dipsonibile risponde).

Quello che dici è corretto ma è solo uno degli utilizzi del RARP, ovvero nelle vecchie implementazioni in assenza dei server DHCp si utilizzavano i server RARP, in cui ogni host privo di ip ne chiedeva il mapping con una richiesta a codice 3. Ma in ogni caso, seppur obsoleto, il protocollo resto obbligatorio per la suite TCP/IP. Tra l' altro l' rfc stabilisce che, a discrezione dell' implementazione, le reply rarp e arp possano essere considerate equivalenti e quindi messe nella medesima cache.

[Spectrum7glr]

Originariamente inviato da nuovoUtente86

Quello che dici è corretto ma è solo uno degli utilizzi del RARP, ovvero nelle vecchie implementazioni in assenza dei server DHCp si utilizzavano i server RARP, in cui ogni host privo di ip ne chiedeva il mapping con una richiesta a codice 3. Ma in ogni caso, seppur obsoleto, il protocollo resto obbligatorio per la suite TCP/IP.

non dico che quello sia l'unico utilizzo possibile del RARP...dico solo che tra i suoi utilizzi non è conteplata la risoluzione inversa di un arp (se non il proprio: un PC che implementa il RARP* non risponde alle rarp request e si limita a farle), quindi obbligatorio o meno che sia non è utilizzabile per risolvere il quesito del nostro amico

*tra l'altro chi risponde al RARP risponde fornendo l'indirizzo IP del richiedente e non fornendo l'indirizzo IP proprio.

[nuovoUtente86]

Originariamente inviato da Spectrum7glr

non dico che quello sia l'unico utilizzo possibile del RARP...dico solo che tra i suoi utilizzi non è conteplata la risoluzione inversa di un arp (se non il proprio: un PC che implementa il RARP non risponde alle rarp request e si limita a farle), quindi obbligatorio o meno che sia non è utilizzabile per risolvere il quesito del nostro amico

ed invece qui sbagli, perchè è utilizzabile in quanto chi implementa rarp non si limita solo alle richieste, ma deve rispondere con un reply 4 (secondo alcune implementazioni in broadcast) qualora conasca il mapping (ovvero la macchina stessa, se ovviamente ha già l' ip assegnato in altro modo, ed eventualmente chi ha il dato in arp cache). Ovviamente il pacchetto di richiesta va costruito adeguatamente.

[nuovoUtente86]

tra l'altro chi risponde al RARP risponde fornendo l'indirizzo IP del richiedente e non fornendo l'indirizzo IP proprio

certo risponde fornendo l' ip mappato sul target MAC.

[Spectrum7glr]

Originariamente inviato da nuovoUtente86

ed invece qui sbagli, perchè è utilizzabile in quanto chi implementa rarp non si limita solo alle richieste, ma deve rispondere con un reply 4 (secondo alcune implementazioni in broadcast) qualora conasca il mapping (ovvero la macchina stessa, se ovviamente ha già l' ip assegnato in altro modo, ed eventualmente chi ha il dato in arp cache). Ovviamente il pacchetto di richiesta va costruito adeguatamente.

il pacchetto richiesta potrà anche essere costruito adeguatamente ma se leggi la sezione motivation sulla RFC 2390 (InARP) ti accorgi che RARP non è implementato con quell'utilizzo...il RARP era stato proprosto come candidato per la risoluzione inversa ma poi si è preferito seguire un'altra strada (anche perchè il THA in base alla RFC 903 non è il destinatario diretto della richiesta: è poco efficiente sfruttare un protocollo che richiede un broadcast quando conosciamo il mac del destinatario) per cui allo stato attuale è molto probabile che un server RARP (ammesso che esista sulla rete: cosa tutt'altro che scontata nel 2010) nemmeno tratti una richiesta in cui il SHA è diverso dal THA.

[nuovoUtente86]

Originariamente inviato da Spectrum7glr

il pacchetto richiesta potrà anche essere costruito adeguatamente ma se leggi la sezione motivation sulla RFC 2390 (InARP) ti accorgi che RARP non è implementato con quell'utilizzo...il RARP era stato proprosto come candidato per la risoluzione inversa ma poi si è preferito seguire un'altra strada (anche perchè il THA in base alla RFC 903 non è il destinatario diretto della richiesta: è poco efficiente sfruttare un protocollo che richiede un broadcast quando conosciamo il mac del destinatario) per cui allo stato attuale è molto probabile che un server RARP (ammesso che esista sulla rete: cosa tutt'altro che scontata nel 2010) nemmeno tratti una richiesta in cui il SHA è diverso dal THA.

Concordo sul fatto che possa essere poco efficiente utilizzare un protocollo la cui ultima revisione è datata 1984, ma continui a dire che non funziona, quando non è cosi, seppur se uno degli utilizzi principi (mostrati nel 930) del protocollo è di natura totalmente differente. Ed il perchè funziona risiede proprio nel fatto che non è prevista alcuna verifica di corrispondenza tra target e sorgente.

[Wolfhwk]

Ma di quali dispositivi si parla? Di cisco Catalyst forse?
Se di questo si tratta posso fornire la procedura con linea di comando...
In effetti i catalyst renderebbero superfluo il wireshark e altre utility.

[nuovoUtente86]

Originariamente inviato da Wolfhwk

Ma di quali dispositivi si parla? Di cisco Catalyst forse?
Se di questo si tratta posso fornire la procedura con linea di comando...
In effetti i catalyst renderebbero superfluo il wireshark e altre utility.

ma puoi farlo solo in un caso, di cui si è già parlato ovvero quando venga generato traffico unicast verso un' interfaccia IP del dispositivo, di cui si va a vedere la arp table.

[Spectrum7glr]

Originariamente inviato da nuovoUtente86

ma puoi farlo solo in un caso, di cui si è già parlato ovvero quando venga generato traffico unicast verso un' interfaccia IP del dispositivo, di cui si va a vedere la arp table.

bè, se hai un catalyst, puoi anche mettere una porta in modalità mirroing/promiscua (SPAN credo si chiami in casa Cisco) ed (al limite) tutto il traffico che attraversa lo swith può essere buttato fuori sulla porta in questione...con sw come wireshark a quel punto puoi riuscire a beccare l'ip incriminato. Ovvio che rischi di mandare lo switch in blocco, però in condizioni di carico normali è un'operazione perfettamente possibile.

[nuovoUtente86]

Originariamente inviato da Spectrum7glr

bè, se hai un catalyst, puoi anche mettere una porta in modalità mirroing/promiscua (SPAN credo si chiami in casa Cisco) ed (al limite) tutto il traffico che attraversa lo swith può essere buttato fuori sulla porta in questione...con sw come wireshark a quel punto puoi riuscire a beccare l'ip incriminato. Ovvio che rischi di mandare lo switch in blocco, però in condizioni di carico normali è un'operazione perfettamente possibile.

Lo si può fare, in maniera non difficile anche con poisoning, ma si tratta in ogni caso di sniffare esternamente allo switch. Per poterlo fare amministrativamente è necessario che ci siano interfacce IP coinvolte attivamente.

[Spectrum7glr]

guarda per me è arabo ...io mi sono limitato a dire che con un catalyst (o switch con funzionalità similari) è una cosa possibile .

Rimangono due dubbi:
1)l'utente che ha cominciato il thread si sta curando minimamente delle risposte?
2)che cavolo fa un dispositivo con un ip fuori dal range della sottorete?comunicare con altri dispositivi non può... non è che magari sulla rete c'è un qualche cavolo di dispositivo assolutamente innocuo (come uno switch managed) che semplcemente è mal configurato (è stato lasciato a default su una sottorete differente)?

[nuovoUtente86]

Originariamente inviato da Spectrum7glr

guarda per me è arabo ...io mi sono limitato a dire che con un catalyst (o switch con funzionalità similari) è una cosa possibile .

Rimangono due dubbi:
1)l'utente che ha cominciato il thread si sta curando minimamente delle risposte?
2)che cavolo fa un dispositivo con un ip fuori dal range della sottorete?comunicare con altri dispositivi non può... non è che magari sulla rete c'è un qualche cavolo di dispositivo assolutamente innocuo (come uno switch managed) che semplcemente è mal configurato (è stato lasciato a default su una sottorete differente)?

L' Ip in questione dovrebbe interdersi appartenente alla subnet. In ogni caso, tutto questo discorso (quindi di tecniche piu o meno funzionanti) nasce dal supporre che la macchina che ha interesse a stare nascosta non produca richieste ARP (altrimenti basterebbe analizzarle, essendo le stesse in broadcast e conteneti il mapping ip-mac della sorgente), il che è alquanto strano normalmente in quanto può verificarsi perchè :
- l' host non produca traffico unicast
- abbia tutti i mapping degli altri host settati in maniera statica
-utilizzi raw packet

[Baboo85]

Si' gente ma quindi? Stavo leggendo il topic ma nessuno ha dato una risposta...

Se uno conosce il mac address, come si risale all'indirizzo ip? Chiedo COME, perche' sono sicuro al 99,999% che il modo c'e'...

[nuovoUtente86]

Originariamente inviato da Baboo85

Si' gente ma quindi? Stavo leggendo il topic ma nessuno ha dato una risposta...

Se uno conosce il mac address, come si risale all'indirizzo ip? Chiedo COME, perche' sono sicuro al 99,999% che il modo c'e'...

La risposta è proprio nel post precedente : se il client in questione non ha interesse a nascondere la propria presenza

richieste ARP (altrimenti basterebbe analizzarle, essendo le stesse in broadcast e conteneti il mapping ip-mac della sorgente)

[Dumah Brazorf]

Apri il prompt del dos.

arp -a

[Baboo85]

Originariamente inviato da Dumah Brazorf

Apri il prompt del dos.

arp -a

Mmmmh bello, ma non e' abbastanza. Mi serviva per un indirizzo mac esterno col quale dovevo fare una cosa particolare (niente di illegale, anzi... E' esattamente il contrario) e sarebbe stato bello arrivare all'indirizzo ip sapendo il mac di quella macchina (ad esempio: sono al lavoro, so il mac address del mio router ma non so l'indirizzo ip (perche' e' dinamico per esempio): come risalgo al suo ip attuale?).

Grazie lo stesso

[nuovoUtente86]

Originariamente inviato da Baboo85

Mmmmh bello, ma non e' abbastanza. Mi serviva per un indirizzo mac esterno col quale dovevo fare una cosa particolare (niente di illegale, anzi... E' esattamente il contrario) e sarebbe stato bello arrivare all'indirizzo ip sapendo il mac di quella macchina (ad esempio: sono al lavoro, so il mac address del mio router ma non so l'indirizzo ip (perche' e' dinamico per esempio): come risalgo al suo ip attuale?).

Grazie lo stesso

Il mac address ha visibilità locale, fuori dal dominio broadcast non ha valore, in quanto sostituito da quello del gateway e dei dispositivi intermedi.