nicht angemeldet
Der Martin
Der Martin
dedlfix
dedlfix
dedlfix
dedlfix
dedlfix
Der Martin
Der Martin
dedlfix
Hallo,
ich habe "zwei" Netzwerke, über zwei Netzwerkkarten an meinen Rechner angeschlossen. Für eine PHP CURL/file_get_contents Funktion möchte ich es nun nicht mehr Windows überlassen über welche Netzwerkkarte (und somit über welches Netz) der Request geschickt wird.
Kann ich in PHP festlegen welche Netzwerkkarte genutzt wird?
Hi,
ich habe "zwei" Netzwerke, über zwei Netzwerkkarten an meinen Rechner angeschlossen. Für eine PHP CURL/file_get_contents Funktion möchte ich es nun nicht mehr Windows überlassen über welche Netzwerkkarte (und somit über welches Netz) der Request geschickt wird.
Kann ich in PHP festlegen welche Netzwerkkarte genutzt wird?
ohne auf implementierungsspezifische Details einzugehen: Definitiv nein.
PHP ist auf Anwendungsebene angesiedelt. Eine Anwendung instruiert das Betriebssystem, eine Verbindung zu einer bestimmten Netzwerkressource aufzubauen. Es ist Aufgabe des TCP/IP-Protokollstacks, anhand der gewünschten Zieladresse und der Routingtabelle zu entscheiden, über welches Netzwerkinterface die Verbindung hergestellt wird, falls es mehrere gibt.
Genau da, also in dfer Routingtabelle, musst du also ansetzen. PHP hat selbst keine Möglichkeit, auf die Entscheidung einzuwirken.
So long,
Martin
Moin!
Genau da, also in dfer Routingtabelle, musst du also ansetzen. PHP hat selbst keine Möglichkeit, auf die Entscheidung einzuwirken.
Na?
$ php -S IP_ADRESSE_DER_NERTZWERKKARTE:8000
Allerdings wird der Michael das nicht gemeint haben. Viel öfter ist PHP sowohl als Modul als auch als CGI des Webservers konfiguriert. Und dann ist der Webserver zuständig.
Der wieder lässt sich freilich an ein Gerät binden. Beim Apache findet sich der Konfigurationseintrag als "listen IP_ADRESSE_DER_NERTZWERKKARTE:8000".
Jörg Reinholz
Hi,
$ php -S IP_ADRESSE_DER_NERTZWERKKARTE:8000
Allerdings wird der Michael das nicht gemeint haben. Viel öfter ist PHP sowohl als Modul als auch als CGI des Webservers konfiguriert. Und dann ist der Webserver zuständig.
Der wieder lässt sich freilich an ein Gerät binden. Beim Apache findet sich der Konfigurationseintrag als "listen IP_ADRESSE_DER_NERTZWERKKARTE:8000".
interessante Antworten, die gehen aber IMO an der Frage vorbei. Der OP sprach von einem von PHP ausgehenden Request (also PHP in der Client-Rolle), bei dem er je nach Ziel-URL ein bestimmtes Netzwerkinterface auswaählen und so die Route festlegen möchte.
So long,
Martin
Tach!
Der OP sprach von einem von PHP ausgehenden Request (also PHP in der Client-Rolle), bei dem er je nach Ziel-URL ein bestimmtes Netzwerkinterface auswaählen und so die Route festlegen möchte.
Von Route hat er nicht gesprochen, nur von der Absenderadresse. Anhand der wird das eine oder das andere Interface verwendet, das Routing ist davon unberührt.
dedlfix.
Moin!
Der OP sprach von einem von PHP ausgehenden Request (also PHP in der Client-Rolle), bei dem er je nach Ziel-URL ein bestimmtes Netzwerkinterface auswaählen und so die Route festlegen möchte.
Von Route hat er nicht gesprochen, nur von der Absenderadresse. Anhand der wird das eine oder das andere Interface verwendet, das Routing ist davon unberührt.
Naja... Wenn PHP der Client ist, dann wird - abgesehen von dem recht speziellen Sonderfall, dass nicht beide Interfaces an das selbe Netzwerk gebunden wurden - der Request natürlich über das Interface gesendet, welches sich entweder im Netzwerk der Zieladresse befindet oder laut Routing-Tabelle für das Zielnetz zuständig ist. Das Routing zu erwähnen ist also nicht nur "nicht ganz falsch", sondern sogar richtig.
In PHP ist aber auch dann nichts zu konfigurieren.
Jörg Reinholz
Tach!
Naja... Wenn PHP der Client ist,
Davon sollte man gemäß der Aufgabenbeschreibung ausgehen. Ob PHP oder ein anderes Programm verwendet wird, ist aber für das Prinzip egal.
dann wird - abgesehen von dem recht speziellen Sonderfall, dass nicht beide Interfaces an das selbe Netzwerk gebunden wurden - der Request natürlich über das Interface gesendet, welches sich entweder im Netzwerk der Zieladresse befindet oder laut Routing-Tabelle für das Zielnetz zuständig ist. Das Routing zu erwähnen ist also nicht nur "nicht ganz falsch", sondern sogar richtig.
Das trifft zu, wenn sich das Betriebssystem eine Absenderadresse selber wählen kann, man also nicht explizit eine vorgegeben hat. Und wenn man eine vorgegeben hat, sollte man mit der nicht über ein anderes Interface senden.
Die Frage ist nun, wie sich das System verhält. Hier bin ich momentan auch überfragt. Deswegen nachfolgend eine theoretische Betrachtung:
Gegeben sei ein Rechner mit zwei Interfaces. Der Einfachheit halber beschränken wir das mal auf eine einzige Adressfamilie (also nicht IPv4 und IPv6 gleichzeitig). Das eine Interface hat die Adressen A und B und das zweite 2 hat C. Das Default-Routing geht über Interface 1. Ein Programm möchte als Absender C haben und nach außerhalb des C-Netzes senden. Gibts einen Fehler (Ziel nicht erreichbar oder so), weil das System über Interface 2 zu senden versucht oder gehen die Pakete an Interface 1 mit Absender C? Weiterhin ist die Frage, wo die Antworten hingehen. Ans Interface 1 können sie nicht, da werden sie nicht angenommen und vermutlich auch nicht hingeroutet. Ans Interface 2 können sie unter Umständen auch nicht geroutet werden. Ich meine, in dem Fall muss es zu einem Fehler kommen. Die Pakete müssen über Interface 2 ausgesendet werden und wenn dort keine Route zum Ziel vorhanden ist, muss es scheitern. Dann hat das Programm Pech gehabt, was verlangt es auch explizit nach C.
In PHP ist aber auch dann nichts zu konfigurieren.
Nur wenn dir die Absenderadresse egal ist, was aber beim OP nicht der Fall ist.
dedlfix.
Moin!
Ist doch einfach.
1. Fall: Zielvorgabe: Was zu a.1.2.3 senden.
Ab zum Interface 0. IP anschauen. Hat b.0.0.12/8. Mist. Passt nicht. Also weiter.
Ab zum Interface 1.
Hat 2 IPS in zwei virtuellen Interfaces.
Ab zum Interface 1.0. IP anschauen. Hat c.0.0.12/8. Mist. Passt nicht. Also Weiter.
Ab zum Interface 1.1. IP anschauen. Hat d.0.0.12/8. Mist. Passt nicht. Also Weiter.
Routingtabelle anschauen:
Interface 1.0. mit IP c.0.0.12/8 und Gateway c.0.0.254 ist Router für 0.0.0.0/0 - das passt. WOOOOOP
2. Fall: Zielvorgabe: Was zu d.1.2.3 senden.
Ab zum Interface 0. IP anschauen. Hat b.0.0.12/8. Mist. Passt nicht. Also weiter.
Ab zum Interface 1.
Hat 2 IPS in zwei virtuellen Interfaces.
Ab zum Interface 1.0. IP anschauen. Hat c.0.0.12/8. Mist. Passt nicht. Also Weiter.
Ab zum Interface 1.1. IP anschauen. Hat d.0.0.12/8. - das passt. WOOOOOP
Das ist die Logik. Es findet nicht ganz so statt, vermutlich wird ein binärer Maskenvergleich mit einer Kernelliste aller Interfaces und Routen gemacht.
Jörg Reinholz
Tach!
Ist doch einfach.
1. Fall: Zielvorgabe: Was zu a.1.2.3 senden.
Ab zum Interface 0. IP anschauen. Hat b.0.0.12/8. Mist. Passt nicht. Also weiter.
Ab zum Interface 1.
Hat 2 IPS in zwei virtuellen Interfaces.
Ab zum Interface 1.0. IP anschauen. Hat c.0.0.12/8. Mist. Passt nicht. Also Weiter.
Ab zum Interface 1.1. IP anschauen. Hat d.0.0.12/8. Mist. Passt nicht. Also Weiter.
Routingtabelle anschauen: Interface 1.0. mit IP c.0.0.12/8 und Gateway c.0.0.254 ist Router für 0.0.0.0/0 - das passt. WOOOOOP
Und was ist mit den Antwortpaketen? Außerdem stimmen deine Buchstaben nicht mit meine überein und loopback kannst du aus der Betrachtung rauslassen.
dedlfix.
Tach!
Gegeben sei ein Rechner mit zwei Interfaces. Der Einfachheit halber beschränken wir das mal auf eine einzige Adressfamilie (also nicht IPv4 und IPv6 gleichzeitig). Das eine Interface hat die Adressen A und B und das zweite 2 hat C. Das Default-Routing geht über Interface 1. Ein Programm möchte als Absender C haben und nach außerhalb des C-Netzes senden. Gibts einen Fehler (Ziel nicht erreichbar oder so), weil das System über Interface 2 zu senden versucht oder gehen die Pakete an Interface 1 mit Absender C? Weiterhin ist die Frage, wo die Antworten hingehen. Ans Interface 1 können sie nicht, da werden sie nicht angenommen und vermutlich auch nicht hingeroutet. Ans Interface 2 können sie unter Umständen auch nicht geroutet werden. Ich meine, in dem Fall muss es zu einem Fehler kommen. Die Pakete müssen über Interface 2 ausgesendet werden und wenn dort keine Route zum Ziel vorhanden ist, muss es scheitern. Dann hat das Programm Pech gehabt, was verlangt es auch explizit nach C.
Ich hab das jetzt mal probiert. Das Szenario vereinfache ich noch mal, und lasse Adresse B weg. Ich hab da einen Windows-Rechner mit einem (physischen) Netzwerkinterface (1) und Default-Route über dieses Interface an eine Adresse aus dem Netzwerk A. Es gibt ein (virtuelles) Interface (2) mit Adresse C und dahinter mit das C-Netzwerk. Der Leitungshai horcht auf diesen beiden Interfaces und zeigt nur ICMP-Pakete an.
ping 8.8.8.8 -S C PING: transmit failed. General failure. Der Leitungshai schweigt.
ping C-Netzwerk-Ziel -S A Request timed out. Der Leitungshai zeigt die 4 Pakete - ohne Antworten - auf dem Interface 1 mit den Adressen gemäß Ping an. Die MAC-Adressen sind die vom Interface 1 und vom Interface des Routers. Hier wurde der Default-Router im A-Netzwerk bemüht und die C-Route ignoriert.
Das zeigt mir, dass bei festgelegter Absenderadresse quasi das Netzwerkinterface Vorrang vor dem Routing hat. Genauer geschlussfolgert: Es werden nur die Routen berücksichtigt, die über das Interface gehen, das zur gewünschten Absenderadresse gehört. Lege ich keine Adresse fest, sucht sich das System eine zum Routing passende aus.
dedlfix.
Moin!
Das zeigt mir, dass bei festgelegter Absenderadresse quasi das Netzwerkinterface Vorrang vor dem Routing hat.
Wenn Du Dir mal ARP anschaust, dann weisst Du, warum das so sein muss. Noch mehr wenn Du schaust, wie Ethernet-Frames aufgebaut sind.
Wenn eine zur zur Ziel-IP passendes Netzwerkgerät gefunden wird, dann fragt der Rechner per Brotkastennachricht nach "Hallo? Ist da wer mit der IP 1.2.3.4 aus dem Netzwerk /24?" und bekommt (hoffentlich(nur)) eine Antwort mit der Mac-Adresse. Wenn das Dein Leitungshai nicht registrierte, dann deswegen, weil diese MAC-Adresse im ARP-Cache gespeichert wird. Wenn es keine Antwort geben kann (alle Netzwerkgeräte haben keine passende IP/Maske, dann wird die Routing-Tabelle gefragt. Wenn es eine Antwort geben müsste (IP/Maske passen), dann wird nach einer Frist höflichem Wartens der Fehler getriggert, dass ein Verbindungsaufbau zum tiefsten Bedauern des Netzwerkstacks und seiner Freunde und Nachkommen nicht möglich sei.
Dem TO (Michael) wird das nichts nützen. So lange der aber nicht damit rausrückt, was er da Wundersames konfiguriert hat, ist ihm nicht zu helfen.
Jörg Reinholz
Tach!
Wenn Du Dir mal ARP anschaust, dann weisst Du, warum das so sein muss. Noch mehr wenn Du schaust, wie Ethernet-Frames aufgebaut sind.
Nein, weiß ich nicht, weil ich nicht weiß, worauf du hinauswillst. Vielleicht sind deine und meine Vorstellungen von der Arbeitsweise von Ethernet und IP ja auch nicht kompatibel zueinander. Und bei mindestens einem von uns beiden ist diese anscheinend auch nicht (vollständig) kompatibel zu den Gegebenheiten.
Wenn ein zur Ziel-IP passendes Netzwerkgerät gefunden wird, dann fragt der Rechner per Brotkastennachricht nach "Hallo? Ist da wer mit der IP 1.2.3.4 aus dem Netzwerk /24?" und bekommt (hoffentlich(nur)) eine Antwort mit der Mac-Adresse.
Zum einen ist die /24 keineswegs ein fester Wert. Die Netzmaske kann je nach Konfiguration eine andere sein. Beim ARP spielt die Netzmaske keine Rolle, die ist da gar nicht in den Daten, nur nackige IP-Adressen. In den Ethernet-Frames erst recht nicht, da gibts nur MAC-Adressen.
Die Auswahl des Netzwerkinterfaces trifft der TCP/IP-Stack. Pinge ich ohne einen Absender festzulegen eine C-Adresse an, zeigt der Leitungshai einen ARP-Request auf Interface 2 an. Das 1 wird nicht behelligt. Und nein, der ARP-Cache wurde vorher gelöscht hat dazu auch nachher keinen Eintrag drin - kann er ja auch nicht.
Anhand der Absenderadresse ist festgelegt, welches Interface verwendet wird. Dann kommt der ARP-Cache oder ein -Request an die Reihe, um die MAC der Zieladresse oder - falls das Ziel über Gateway zu erreichen ist - die des Gateways zu ermitteln.
Es gibt auch keine überflüssigen ARP-Request auf nicht zutreffenden Interfaces, wenn ich mit einer selbstgewählten Absenderadresse arbeite. Ich habe die Versuche wiederholt und der erste Versuch zeigt keinerlei ARP-Aktivitäten für die betroffenen Adressen auf den beiden Interfaces - natürlich mit vorher gelöschtem ARP-Cache. ARP hat also nicht zum Finden der Route oder eines passenden Interfaces oder zur Feststellung des Nicht-geroutet-werden-könnens beigetragen.
Für die gewählte Absenderadresse gibt es auf dem zugehörigen Interface keine Route zum Ziel, da muss auch keine MAC-Adresse erfragt werden. Und welche sollte es denn sein? Die MAC von Zielen hinter dem Gateway spielt sowieso keine Rolle in meinem/n Netzwerk(en). Ein Gateway ist für das Ziel nicht konfiguriert, also kann auch nicht von dessen nicht vorhandener IP-Adresse deren MAC-Adresse per ARP angefragt werden.
Wenn es keine Antwort geben kann (alle Netzwerkgeräte haben keine passende IP/Maske, dann wird die Routing-Tabelle gefragt.
Nochmal zum Mitschreiben: Wenn ich keine Absenderadresse festlege, dann wird ins Routing geschaut, welche Route zum Ziel führt, über welches Interface die Route geht und dann dessen IP-Adresse als Absender genommen. Weiter wie im nachfolgenden Punkt.
Lege ich jedoch eine Absenderadresse fest (oder sie wurde mir vergeben), dann ist diese an ein Interface gebunden und die weiteren Schritte reduzieren sich auf dieses Interface - bei direkt möglichen Verbindungen, also Zielen des Absenderadressen-Netzwerkes - oder die Einträge der Routenkonfiguration, die dieses Interface als Ziel haben.
ARP jedenfalls dient nicht zur Routen- oder Interfacefindung. ARP heißt "Wer hat die MAC zur IP-Adresse?" Es heißt nicht "Wer kennt den Weg zur IP-Adresse?" oder gar "Wer kann mir die MAC-Adresse eines hinter Gateways steckenden Ziels geben?"
Kleiner Grundlagenkurs:
a) Absender und Ziel sind im selben Netzwerk (Interface wird vom System entsprechend der Absender-Adresse genommen)
b) Für das Ziel ist ein Gateway konfiguriert (Interface ... s.o.)
Dem TO (Michael) wird das nichts nützen. So lange der aber nicht damit rausrückt, was er da Wundersames konfiguriert hat, ist ihm nicht zu helfen.
Dem TO nützt bereits die Information, dass und wie man die Absenderadresse (und damit das zu verwendende Interface) explizit festlegen kann. Wenn er mehr wissen möchte, oder das sein eigentliches Problem nicht löst, muss er mehr fragen.
dedlfix.
Hallo,
Dem TO nützt bereits die Information, dass und wie man die Absenderadresse (und damit das zu verwendende Interface) explizit festlegen kann.
diese Information hat auch mir genützt. Ich wusste bisher nicht, dass das prinzipiell möglich ist und bin davon ausgegangen, dass die Wahl der Absenderadresse und damit des Interfaces allein Sache des Betriebssystems, speziell des TCP/IP-Protokollstacks ist.
Und auf diesem Wissensdefizit beruhte selbstverständlich auch meine pauschale Aussage "geht nicht".
So long,
Martin
Moin!
Ich sehe schon. Du bist nicht wirklich gut drauf. Technisch hast Du zwar durchaus in einigen Punkten recht. Aber die Art, wie Du es aussendest, empfinde ich nicht als "wohlwollend".
Jörg Reinholz
Hallo Jörg,
Ich sehe schon. Du bist nicht wirklich gut drauf. Technisch hast Du zwar durchaus in einigen Punkten recht. Aber die Art, wie Du es aussendest, empfinde ich nicht als "wohlwollend".
😮 was? Hast du vielleicht etwas falsch aufgefasst? Dedlfix war absolut sachlich und neutral und ich finde, er hat dir viel Geduld entgegen gebracht.
LG,
CK
Hallo,
Dedlfix war absolut sachlich und neutral und ich finde, er hat dir viel Geduld entgegen gebracht.
sehe ich ähnlich. Allerdings war ich überrascht, dass du mir gegenüber ungewohnt deutlich geworden bist, wenn auch nur in der dritten Person.
Ich meine, okay, ich hab kein Problem damit - ich habe mein Halbwissen sehr überzeugt vertreten, und dabei haben sich dir möglicherweise die Zehennägel aufgerollt. Na gut, wir sind alle (auch) hier, um zu lernen. Unter dem Aspekt hat sich der Thread für mich schon gelohnt.
So long,
Martin
Hallo Martin,
sehe ich ähnlich. Allerdings war ich überrascht, dass du mir gegenüber ungewohnt deutlich geworden bist, wenn auch nur in der dritten Person.
Hm, inwiefern? Ich wollte damit ausdrücken, das ich es kaum ausgehalten habe den Thread zuende zu lesen weil ich das dringende Bedürfnis verspürte dich richtig zu stellen - typischer Fall von XKCD: Duty Calls halt. Überhaupt nicht böse gemeint und sicher nicht gegen dich gerichtet. Wie hast du das denn aufgefasst?
LG,
CK
Hi,
Überhaupt nicht böse gemeint und sicher nicht gegen dich gerichtet. Wie hast du das denn aufgefasst?
für mich las sich das wie: "Das ist ja nicht auszuhalten, was der für'n Blödsinn verzapft." ##
Was ja auch nicht ganz falsch war, aber eine direkte Klarstellung wäre IMO feiner gewesen als mich einfach dumm dastehen zu lassen, so dass ich irgendwann "zufällig" meinen Irrtum bzw. meine Wissenslücke aufgeklärt sehe.
Gute Nacht,
Martin
Hallo Martin,
Überhaupt nicht böse gemeint und sicher nicht gegen dich gerichtet. Wie hast du das denn aufgefasst?
für mich las sich das wie: "Das ist ja nicht auszuhalten, was der für'n Blödsinn verzapft." ##
Nee, so war das nicht gemeint, sorry.
Was ja auch nicht ganz falsch war, aber eine direkte Klarstellung wäre IMO feiner gewesen als mich einfach dumm dastehen zu lassen, so dass ich irgendwann "zufällig" meinen Irrtum bzw. meine Wissenslücke aufgeklärt sehe.
Es lag nicht in meiner Absicht dich „dumm dastehen zu lassen.“ Und dich aufgeklärt hatte dedlfix schon, es gab also keinen Grund noch etwas zu dem Thema schreiben.
Und eigentlich wollte ich da nur eine humorvolle Anmerkung fallen lassen. Ist wohl gründlich in die Hose gegangen, das lass ich demnächst wohl besser ;-/
LG,
CK
Tach!
Kann ich in PHP festlegen welche Netzwerkkarte genutzt wird?
ohne auf implementierungsspezifische Details einzugehen: Definitiv nein.
Definitiv: nicht nein.
PHP ist auf Anwendungsebene angesiedelt. Eine Anwendung instruiert das Betriebssystem, eine Verbindung zu einer bestimmten Netzwerkressource aufzubauen. Es ist Aufgabe des TCP/IP-Protokollstacks, anhand der gewünschten Zieladresse und der Routingtabelle zu entscheiden, über welches Netzwerkinterface die Verbindung hergestellt wird, falls es mehrere gibt.
Wann immer ich mit Low-Level-Netzwerkfunktionen gearbeitet habe, konnte man es sich aussuchen, an welche IP-Adresse und welchen Port man sich binden möchte. Für Serverfunktionalität ist das ein Muss, aber um eine solche geht es in dem Fall nicht. Aber auch der Client kann es sich raussuchen, welche IP-Adresse und welchen Port er als Absender nehmen möchte.
PHPs Curl kennt die Option CURLOPT_INTERFACE: "The name of the outgoing network interface to use. This can be an interface name, an IP address or a host name." Dazu ein User-Kommentar: "Please note that the CURLOPT_INTERFACE setting only accepts IP addresses and hostnames of the local machine." Auch wird das Betriebssystem sich weigern, einen der privilegierten Ports (unterhalb 1024) zu akzeptieren, wenn man keine ausreichenden Rechte vorweisen kann.
file_get_contents() kann man einen Context mitgeben, der Socket context options enthalten kann. Für diesen Fall ist bindto die gesuchte Option.
Genau da, also in der Routingtabelle, musst du also ansetzen. PHP hat selbst keine Möglichkeit, auf die Entscheidung einzuwirken.
Das ist erst ein späterer Schritt. Das Routing kann man als Client nun wirklich nicht mehr beeinflussen.
dedlfix.
Hallo dedlfix,
danke, ich habe beim Lesen von Martins Antwort fast in die Tischkante gebissen ;-)
LG,
CK
Hallo,
ich habe "zwei" Netzwerke, über zwei Netzwerkkarten an meinen Rechner angeschlossen. Für eine PHP CURL/file_get_contents Funktion möchte ich es nun nicht mehr Windows überlassen über welche Netzwerkkarte (und somit über welches Netz) der Request geschickt wird.
Kann ich in PHP festlegen welche Netzwerkkarte genutzt wird?
Es geht also um einen Request, den der Webserver als Client absetzt?
Hast Du den Host denn als IP-basierten oder als namensbasierten eingerichtet?
Ist es ein Apache? Da kann man das auch kombinieren, also namensbasiert mehrere virtual Webhosts auf eine IP legen und andere namensbasierte auf eine andere.
