Guten Abend Forum,
ich habe seit laengerer Zeit ein Problem in der Schublade, dass ich
regelmaessig mal auspacke, ueber Suchmaschinen nach Informationen suche
und meine Literatur durchforste, leider ohne Erfolg.
Zur Sache, ich benoetige fuer meinen Desktop eine zweite, intern
adressierbare IP-Adresse, welche neben dem tcp/ip-Stack des OS genutzt
werden kann.
Im Forum erhielt ich den Hinweis, dass dies theoretisch moeglich waere,
indem ich den ARP Cache durch Senden von ARP-Replies erweitern koennte.
ARP ist fuer die Aufloesung von IP-Adressen in MAC-Adressen zustaendig.
Somit waere der Grundgedanke, wenn ich es richtig verstanden habe, dem
Cache einfach zu sagen ... Hier ist die MAC-Adresse, bspw. vom Interface
'wlan0', verbunden mit der 'eigentlich' zuvor ueber den ARP-Request
angefragten IP, die die gewuenschte zweite IP ist.
In diesem Zusammenhang habe ich einen ARP-Client in C geschrieben, der
eben jenen Reply sendet, erfolgreich.
Die in dem Programm eingebauten 'Debug'-Funktionen geben in der Konsole
alle eine Erfolgsmeldung zurueck.
Gesendete ARP-Pakete als solche sehen tip top aus.
Problem an der Sache, wie ich es drehe und wende, mein Cache hat bislang
nicht einmal eine Aenderung vorgenommen, wobei ich Devices
[eth0;wlan0;loopback] und MAC-Adressen [eth0;wlan0;loopback und eine
gaenzlich andere] mehrfach variiert habe.
Laut Internet gibt es verschiedene Problemausloeser, welche ebenfalls
Stein des Problems sein koennen. Vom IP-Forwarding, ueber den
Promiscuous-Mode der Karte, ueber ueber ueber.
Soweit ich das beurteilen kann, fallen diese Punkte aber weg oder wurden
entsprechend abgeaendert.
Frage, ist dies ueberhaupt ein Weg, dem System eine zweite IP zuzuweisen
und falls nein, wuerde ich mich ueber Tipps, Anregungen oder dergleichen
sehr freuen.
Sinn und Zweck des Ganzen ist keine boese Absicht, sondern der Wunsch
einen tcp-Handshake in C mittels des Einsatzes von packet-Sockets
nachzuprogrammieren. Ich habe mich dafuer interessiert, wie die Sache
'unter der Haube' funktioniert und soweit auch alles ans Laufen
bekommen. Problem ist nur, dass sich mein Programm beim System
zurueckmeldet und der Stack sagt -logischerweise- 'Noe, diesen Handshake
habe ich nicht initiiert, also weg damit'
Matthias S. schrieb:> Frage, ist dies ueberhaupt ein Weg, dem System eine zweite IP zuzuweisen
Nein. Wenn du eine IP in einem weiteren Subnet brauchst, dann einfach
sowas:
Um den ARP-Cache zu manipulieren musst du kein eigenes Programm
schreiben. Das Kommando "arp" erledigt das (man arp). Z.Bsp. "arp -s
<ip> <mac> pub" legt einen Eintrag an. Das pub-Flag definiert, dass das
Kernel auch externe ARP-Request für die <ip> beantworten soll (aka
Proxy-ARP - ohne "pub", würde der Eintrag nur bei rausgehenden Paketen
die ARP-Anfrage umgehen[1]).
Was du aber wohl möchtest, ist ein Interface mit mehreren IPs. Die
moderne Methode ist "ip addr add <ip> dev <interface>" (man ip-address).
Die etwas ältere die Alias-Interfaces a la "ifconfig eth0:<id> <ip>"
(man ifconfig).
[1] Wurde früher (pre-DHCP) gern von simplen Netzwerkgeräten benutzt, um
sich eine IP zuweisen zu lassen. Die merkten sich einfach die IP des
letzten, direkt an sie adressierten (MAC-Layer!) Paketes. Dazu wurde
auf irgendeinem Rechner mittels "arp -s" händisch ein temporärer Eintrag
für das Gerät angelegt (MAC-Addr stand auf dem Gehäuse) und es
anschließend einmal angepingt. Das Gerät merkte sich die IP und
beantwortete auch künftige ARP-Anfragen dafür. Fertig war die
IP-Konfiguration.
asdfasd schrieb:> Fertig war die> IP-Konfiguration.
Ömmm ... nein!
Das bewirkt erstmal nur, dass das Subnet über die Information verfügt,
wohin - d.h. an welche MAC-Adresse - Pakete für diese IP-Adresse
geschickt werden sollen. Das bedeutet noch nicht, dass etwas bereit wäre
diese Pakete anzunehmen. Zu dieser MAC-Adresse muss ja noch nicht mal
Hardware existieren.
Konrad S. und asdfasd schrieben:
>ifconfig eth0:A 10.11.12.13>"ifconfig eth0:<id> <ip>"
Perfekt, vielen Dank an Euch!
>Das bedeutet noch nicht, dass etwas bereit wäre>diese Pakete anzunehmen.
Innerhalb des Subnets habe ich die letzte Ziffer meiner bestehenden ip,
passend zum dazugehoerigen interface, einfach um eins erhoeht.
Lt. 'ip addr' ist das Pseudointerface bekannt, also noch einen 'ping'
hinterher geschickt, mit dem Resultat, dass die zweite IP problemlos
angesprochen werden kann. LAEUFT!
Nun habe ich etliche Stunden ueber dem in C geschriebenen Client
gebruetet, damit er selbiges erledigt und jetzt funktioniert es mit
einer Zeile in der Konsole.
Aber davon mal abgesehen, dass Programmieren hat Spaß gemacht und sein
erstes erfolgreich gesendetes ARP-Paket ueber den Ether flitzen zu
sehen, hatte auch was fuer sich.
Habt Ihr Tipps, was evtl. falsch laufen kann, wenn das ueber den Client
gesendete Paket definitiv in Ordnung ist?
Matthias S. schrieb:> Habt Ihr Tipps, was evtl. falsch laufen kann, wenn das ueber den Client> gesendete Paket definitiv in Ordnung ist?
Falls sich ein Rechner im Subnet für das ARP-Paket interessiert hat,
dann findet sich ein Eintrag im ARP-Cache. Der lässt sich mit
Matthias S. schrieb:> Habt Ihr Tipps, was evtl. falsch laufen kann, wenn das ueber den Client> gesendete Paket definitiv in Ordnung ist?
Mir ist dies bereits gelungen: https://github.com/Daniel-Abrecht/DPA-UCS
Interresant wäre, ob das Programm bei dir lauft. Compiliren kann man es
mit "make linux" und starten mit "sudo ./bin/linux" . Die IP kann in
src/main.c eingestellt werden. Danach sollten andere Computer die IP
anpingen können, und einen Webserver mit 404 seite gibts auch. Es kann
auch ohne TCP support Compiliert werden, mit "make NO_TCP=1 linux" oder
ohne ICMP, wenn man die Zeile im makefile auskommentiert.
Wenn mein Programm lauft kann man die Unterschiede in den gesendeten
Daten und die Socket optionen von meinem und deinem Programm
vergleichen. Falls nicht, gibt es anderswo ein Problem.
Viele router senden keine Ethernetframes mit identischer source und
destination mac weiter.
Daniel A. schrieb:
>Viele router senden keine Ethernetframes mit identischer source und>destination mac weiter.
Aehm, wieso Router? Ich nutze zwar das interface 'wlan0', aber der
Client sendet vom Desktop aus direkt auf die IP des Subnetzes, also an
meinen Rechner und nicht ueber die Adresse des Routers.
Bsp.:
lokale IP fuer iface wlan0 127.0.0.101
IP des Routers 127.0.0.1
Wenn mein Client an die 101 sendet, geht das doch nicht nochmal ueber
den Router, oder?
ich selber schrieb:
>aber der Client sendet vom Desktop aus direkt auf die IP des Subnetzes
Subnetz vom Router! Also geht es doch drueber, wenn ich mir das jetzt
nochmal durch den Kopf gehen lasse.
Ich glaube ich sollte mir mal die Logs vom Router ansehen.
Matthias S. schrieb:> Client sendet vom Desktop aus direkt auf die IP des Subnetzes
Nein. Er sendet an die MAC-Adresse, die sich für diese IP-Adresse
zuständig erklärt hat. Das könnte ein Router sein.
Matthias S. schrieb:> lokale IP fuer iface wlan0 127.0.0.101> IP des Routers 127.0.0.1
Pakete an 127.x.x.x verlassen den Rechner nicht.
Wenn mit Packet Sockets packete über das Interface wlan0 gesendet
werden, kommen diese beim Wlan router an. Dieser muss es dann an die
Ziel-mac senden. Also zum rechner, von welchem dieses gekommen ist, wenn
quelle=ziel. Nur machen das viele router und switches bei diesem
Spezialfall nicht.
Konrad S. schrieb:
>Dann nimm doch den 192.168.x.x-Bereich, damit machst du nichts falsch.
Okay, dass die 127.er nicht die Betreffenden sind, haette ich angesichts
der Problemstellung vielleicht dazu schreiben sollen, mea culpa.
Die 192.168 er sind ebenso generisch/standardisiert und waeren auch
gegangen.
Daniel A. schrieb:
>Wenn mit Packet Sockets packete über das Interface wlan0 gesendet>werden, kommen diese beim Wlan router an. Dieser muss es dann an die>Ziel-mac senden. Also zum rechner, von welchem dieses gekommen ist, wenn>quelle=ziel. Nur machen das viele router und switches bei diesem>Spezialfall nicht.
Wie bereits geschrieben, glaube ich langsam, dass der Router des Pudels
Kern ist. Ich werde gleich mal in dessen LogFiles sehen und gucken, ob
ich etwas a la ARP Cache Poisoning Versuch wurde vereitelt sehe.
Was anderes, Du hast geschrieben ich koenne Deinen Code kompilieren.
Ganz ehrlich, wenn es eine kleine Source-File waere, die ich mal eben
durchsehen koennte, gerne. Aber dass Teil fasse ich so auf die Schnelle
nicht an.
Ich unterstelle Dir hier nichts schlechtes, Gott bewahre, aber mal eben
leichtfertig > SUDO dreißig Seiten fremden Code auf meinem System
ausfuehren... Mache ich nicht.
Was ich Dir anbieten kann, ich schicke Dir meinen Code fuer den ARP
Reply und Du fuehrst ihn aus. Schneller, sicherer <weil nur eine Seite
Code> und kommt aufs GLeiche raus.
Matthias S. schrieb:> Was ich Dir anbieten kann, ich schicke Dir meinen Code fuer den ARP> Reply und Du fuehrst ihn aus
Ja, das fände ich super. Ich werde aber erst am abend dazu kommen.
Matthias S. schrieb:> Okay, dass die 127.er nicht die Betreffenden sind, haette ich angesichts> der Problemstellung vielleicht dazu schreiben sollen, mea culpa.>> Die 192.168 er sind ebenso generisch/standardisiert und waeren auch> gegangen.
Nicht "wären auch gegangen", denn mit den 127.x.x.x wäre es nicht
gegangen, da diese den Rechner nie verlassen und auch nie ARP machen.
Konrad S. schrieb:
>Nicht "wären auch gegangen"
Waeren auch gegangen im Sinne von hier veroeffentlichen, dass war
gemeint.
Genauso ungefaehrlich.
Also wenn ich nicht wuesste, was der localhost, fuer eine IP hat, dann
sollte ich nicht mit ARP "rumspielen", waere zumindest von abzuraten.
Es macht keinen Sinn über den Anstellwinkel von Rotorblättern eines
Helikopters zu referieren und dabei auf ein Auto zu zeigen - das Auto
wird dadurch nicht flugfähig.
Matthias S. schrieb:> Sinn und Zweck des Ganzen ist keine boese Absicht, sondern der Wunsch> einen tcp-Handshake in C mittels des Einsatzes von packet-Sockets> nachzuprogrammieren.
D.H. du willst den TCP-Stack des Betriebsystems garnicht verwenden,
sondern deinen eigenen daneben ausrollen?
Und bei eingehenden Paketen soll dann automatisch entschieden werden, ob
das Ethernet-Frame für den Betriebsystem-IP-Stack ist, oder für deinen
eigenen?
Soweit korrekt?
Grobe Idee, ungetestet:
eine virtuelle Ethernet-Bridge (btctl create ....) vorschalten, darin
sowohl das echte eth-device als auch ein virtuelles für deine
Experimente verschalten. (z.B. ip tuntab add oder tunctl)
dem virtuellen verpasst du eine neue, erfundene MAC.
Schon kannst du am virtuellen Device beliebig mit Packet-sockets,
eigenem ARP usw. spielen, ohne dass sich das mit dem Linux-Eigenen
TCP/IP-Stack in die Quere kommt.
Conrad S. schrieb:
>Dann nimm doch den 192.168.x.x-Bereich, damit machst du nichts falsch.
Ich habe den Bereich 192.168.x.x genutzt!
Nur hier, habe ich 127.XX geschrieben. Das es sich hierbei um zwei
grundverschiedene Adressbereiche handelt ist mir klar.
Nur beide haben etwas gemeinsam. Es sind beides standardisierte
Adressbereiche. 127 kennt jeder fuer Localhost und 192.168 duerfte jeder
kennen, der ein Heimnetz mit einem Router betreibt.
Gleichwohl wollte ich meine 192.168.x.x hier nicht posten, eigentlich
gehoppst, wie gesprungen, weil man mit diesen Adressen ebenso wenig
anfangen kann. Daran habe ich aber im Moment nicht gedacht, weil es
schon frueher Morgen war/ist und ich langsam groggy bin.
Localhost 127.0.0.1 nur intern
Lokales wlan 192.168.2.101 funkt hingegen zum
Router 192.168.2.1 und der funkt mit seiner richtigen IP im Netz
und ARP hat mit IP gar nichts zu tun, sondern mit der Aufloesung von MAC
hin zu IP-Adressen, durch einen allgemeinen Broadcast. Dieser beinhaltet
die Frage, welcher der "Nachbarn" die gesuchte IP hat und dieser
antwortet mit seiner IP und der im Endeffekt angefragten MAC.
Planlos schrieb:
>Und bei eingehenden Paketen soll dann automatisch entschieden werden, ob>das Ethernet-Frame für den Betriebsystem-IP-Stack ist, oder für deinen>eigenen?>Soweit korrekt?
Nein, im Prinzip habe ich das Problem, wie oben schon beschrieben, durch
den Einsatz von 'ifconfig' loesen koennen.
Durch das neue Pseudointerface gibt es keinen Grund mehr einen
Entscheidungsprozess zu veranlassen.
Mein Progamm sendet Daten an dieses neu geschaffene Interface und der
tcp/ip-Stack bleibt außen vor, da ich beabsichtige, den Handshake selbst
vom Programm aus durchfuehren zu lassen, so der Plan.
Die virtuelle Ethernet-Bridge laesst sich nicht mit einem so geringen
Aufwand umsetzen, insofern geht meine Praeferenz jetzt erstmal zu der
quick & dirty Methode.
Allerdings klingt Dein Vorschlag sehr nach einer schoenen Testumgebung,
welche sich anzuschauen sicher lohnen wuerde.
> Mein Progamm sendet Daten an dieses neu geschaffene Interface und der> tcp/ip-Stack bleibt außen vor, da ich beabsichtige, den Handshake selbst> vom Programm aus durchfuehren zu lassen, so der Plan.
Ein alias-Interface wird genauso vom IP-Stack des BS behandelt,
wie das reale Interface. D.h. er bleibt nicht "aussen vor".
Wie kommst Du den darauf?
Daniel A. schrieb:> Matthias S. schrieb:>> Was ich Dir anbieten kann, ich schicke Dir meinen Code fuer den ARP>> Reply und Du fuehrst ihn aus>> Ja, das fände ich super. Ich werde aber erst am abend dazu kommen.
Gut, ich habe es ausprobiert. Dass nicht zuerst auf einen ARP-Request
gewartet wird ist zwar nicht Ideal, es funktioniert bei mir aber, sofern
vorher ein arp request erfolgte. Ich habe folgende Ausgabe erhalten:
1
daniel@daniel-Inspiron-7720:~/tmp$ sudo ./client
2
ARP-Reply No.[0] transmitted successfully...
3
ARP-Reply No.[1] transmitted successfully...
...
1
ARP-Reply No.[9] transmitted successfully...
2
daniel@daniel-Inspiron-7720:~/tmp$ arp -a
3
? (192.168.1.1) at 00:25:86:e1:e2:96 [ether] on wlan0
? (192.168.1.1) at 00:25:86:e1:e2:96 [ether] on wlan0
14
daniel@daniel-Inspiron-7720:~/tmp$ sudo ./client
15
ARP-Reply No.[0] transmitted successfully...
16
ARP-Reply No.[1] transmitted successfully...
...
1
ARP-Reply No.[9] transmitted successfully...
2
daniel@daniel-Inspiron-7720:~/tmp$ arp -a
3
? (192.168.1.29) at 60:36:dd:26:4a:bc [ether] on wlan0
4
? (192.168.1.1) at 00:25:86:e1:e2:96 [ether] on wlan0
5
daniel@daniel-Inspiron-7720:~/tmp$
Das Problem wird vermutlich beim Router liegen. Ich verwende manchmal
ein Physikalisches Loopback-Device um solche Probleme zu verhindern. Da
dieses Programm sowieso immer den selben ARP-Reply sendet, könnte man
ebensogut auch mit "sudo arp -s 192.168.1.29 60:36:dd:26:4a:bc" einen
eintrag im ARP-Cache platzieren.
Thread beobachten
Seitenaufteilung abschalten