IP im Linux Terminal ausgeben

[Karl Heinz]

Hallo,

in einem Tutorial werden folgende Befehle genutzt um die IP auszugeben:

wget http://checkip.dyndns.org/ -q -O - | grep -Eo '\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>'

oder

wget -qO- http://ipecho.net/plain;echo

Geht das nicht einfacher? Warum so kompliziert?

Viele Grüße

[dedlfix]

Tach!

in einem Tutorial werden folgende Befehle genutzt um die IP auszugeben:

wget http://checkip.dyndns.org/ -q -O - | grep -Eo '\<[[:digit:]]{1,3}(\.[[:digit:]]{1,3}){3}\>'

oder

wget -qO- http://ipecho.net/plain;echo

Geht das nicht einfacher? Warum so kompliziert?

Wenn du die IP-Adresse eines anderen Gerätes wissen möchtest, musst du das Gerät befragen. In dem Fall möchtest du die öffentliche IP-Adresse des Routers wissen. Dazu müsste die ganze Geschichte noch komplexer werden, weil das dann für jeden Router individuell vorgenommen werden muss. Da ist einen Request an einen Dienst im Internet zu stellen, dessen Arbeitsweise genau bekannt ist, noch die einfachste Variante.

dedlfix.

[Karl Heinz]

@@dedlfix,

Wenn du die IP-Adresse eines anderen Gerätes wissen möchtest, musst du das Gerät befragen.

Situation ist wie folgt:

• Linux PC und Dreambox sind im gleichen LAN
• Dreambox ist mit einem VPN-Server in den USA verbunden
• Durch die VPN-Verbindung der Dreambox zum VPN-Server in den USA ist die Dreambox wohl dann nichtmehr im selben LAN oder?

Ziel:

Ausgehend von meinem PC habe ich eine telnet Verbindung zur dreambox aufgebaut, durch folgende Eingabe am PC:

telnet 192.168.178.68

Was ich gerade nich verstehe:

Durch die Verbindung der Dreambox zum VPN-Server in den USA rutscht die Dreambox doch in ein anderes LAN (Das LAN in den USA). Wieso kann ich die Dreambox dann noch mit dem telnet Befehl oben ansprechen? Das dürfte doch eigentlich nichtmehr funktionieren, weil die Dreambox durch die VPN-Verbindung zum US-Server sozusagen in eine anderes LAN umgezogen wird?

In dem Fall möchtest du die öffentliche IP-Adresse des Routers wissen.

Die öffentliche IP-Adresse des US-Routers mit welchem meine Dreambox per VPN verbunden ist.

Dazu müsste die ganze Geschichte noch komplexer werden, weil das dann für jeden Router individuell vorgenommen werden muss.

Warum noch komplexer, es funktioniert doch so.

Wirklich verstehen tue ich die beiden Befehle nicht. Mit wget lädt man sich irgend eine Datei runter (keine Ahnung welche?). In der Datei steht wohl die IP des Routers in den USA. Diese IP läst man sich auf der Console am heimischen PC ausgeben. Ist das so korrekt?

Was hinter http://checkip.dyndns.org/ und http://ipecho.net/plain steckt, keine Ahnung? Warum wird das benötigt bzw. was ist der Unterschied.

Vielleicht kann mir jemand etwas genauer erklären was die beiden Befehle genau machen?

[pl]

hi,

die Dreambox bekommt kein anderes LAN, durch VPN ändert sich aber möglicherweise das Routing bzw. NAT für dieses LAN 192.168.x.x in welchem sich die DB befindet.

Bleibt Deine REMOTE_ADDR dieselbe nachdem VPN aufgebaut ist? Prüf das mal.

MfG

[Regina Schaukrug]

die Dreambox bekommt kein anderes LAN,

das stimmt. Aber der Rest ist vielmehr so, dass die Dreambox über das bestehende LAN (und dessen Internetzugang) eine (verschlüsselte) Netzwerkverbindung aufbaut, deren logische Endpunkte (mit eigenen IP-Adressen) (Literatur zu "TUN" und "TAP") als virtuelles Netzwerkgerät genutzt werden können. Insoweit bekommt die Dreambox tatsächlich kein anderes aber eben ein weiteres (virtuelles) LAN. Danach wird im wohl vorliegenden Fall das Routing verändert, so dass die Default-Route für das Internet über eben diese virtuelle Verbindung geht.

Was stattfindet kann man sich unter Linux in Abhängigkeit von Distribution und Version mit:

• ip address show oder ifconfig -a und
• ip route show oder route

ansehen. Allerdings muss man die Ausgaben zu interpretieren wissen. Es ist hilfreich sich diese Ausgaben mit und ohne aktiviertes virtuelles Netzwerk anzusehen.

[pl]

Nun, ich habe nicht umsonst gefragt, ob nach dem Aufbau des VPN die REMOTE_ADDR noch dieselbe ist.

Ein VPN kann nämlich auch so konfiguriert sein, daß allen Geräten im LAN der Zugriff in ein anderes Netz verwehrt wird. Was ja auch Sinn macht: Das P steht für Private.

Und der Betreiber des VPN hat mit Sicherheit kein Interesse daran, daß Anwender sein Privates Netz mit anderen Netzen koppeln dürfen. Noch weniger wenn es sich um eine kostenpflichtige Leistung handelt.

MfG

[Regina Schaukrug]

Ein VPN kann nämlich auch so konfiguriert sein, daß allen Geräten im LAN der Zugriff in ein anderes Netz verwehrt wird.

Naja. Mit, sagen wir mal, z.B. mir als Kunde wird er erhebliche Probleme damit haben, das durchzusetzen.

Und der Betreiber des VPN hat mit Sicherheit kein Interesse daran, daß Anwender sein Privates Netz mit anderen Netzen koppeln dürfen.

Regeln die das auf ihren Zugangspunkten nicht über Limits, z.B. durch Traffic-Shaping?

[Regina Schaukrug]

ob nach dem Aufbau des VPN die REMOTE_ADDR noch dieselbe ist.

Das kommt doch sehr auf das wo (der Server steht) und ein wenig auf das "wie" (der Server adressiert wird) an. Beipiel. Ein Rechner mit der "nativen" IP 192.168.1.200 und der IP 10.11.12.200 im VPN nimmt eine Verbindung zum Rechner "foobar.example.com" auf. Wird dessen Adresse nun zu 192.168.1.5 aufgelöst, dann ist 192.168.1.200 REMOTE_ADDR, wird foobar.example.com jedoch zu 10.11.12.5 aufgelöst, dann ist 10.11.12.200 die REMOTE_ADDR. Die Anwendungsfälle, in denen der direkte lokale Netzverkehr unterbunden durch VPN getunnelt wird (was man mit Firewallregeln durchaus machen kann) sind eher sehr speziell. Zudem gibts dafür eigentlich IPsec-Tunnel.

[pl]

Wird dessen Adresse nun zu 192.168.1.5 aufgelöst, dann ist 192.168.1.200 REMOTE_ADDR, wird foobar.example.com jedoch zu 10.11.12.5 aufgelöst, dann ist 10.11.12.200 die REMOTE_ADDR.

Private Netze nach RFC 1918 (169.254.0.0/16 nach RFC 5735) werden nicht groutet. Eine WAN Kopplung wird über NAT (Network Address Translation) realisiert. Wobei NAT auf dem Router stattfindet.

MfG

[pl]

Ein VPN kann nämlich auch so konfiguriert sein, daß allen Geräten im LAN der Zugriff in ein anderes Netz verwehrt wird.

Naja. Mit, sagen wir mal, z.B. mir als Kunde wird er erhebliche Probleme damit haben, das durchzusetzen.

Er wird es gar nicht können wenn es die Policy verbietet.

Und der Betreiber des VPN hat mit Sicherheit kein Interesse daran, daß Anwender sein Privates Netz mit anderen Netzen koppeln dürfen.

Regeln die das auf ihren Zugangspunkten nicht über Limits, z.B. durch Traffic-Shaping?

Nein. Das hat nichts mit Shaping zu tun. Sondern mit der Policy/VPN Konfiguration. Bei den VPNs die wir in unserer Firma hatten, gab es für den PC der den Tunnel aufgebaut hat nicht einmal mehr das eigene LAN.

D.h., das Gerät mit dem VPNClient war nach dem Herstellen der VPN Verbindung von LAN getrennt. Mit der Bandbreite hat das überhaupt nichts zu tun.

MfG

[Regina Schaukrug]

Bei den VPNs die wir in unserer Firma hatten, gab es für den PC der den Tunnel aufgebaut hat nicht einmal mehr das eigene LAN.

Ja. Aber da hatten die Benutzer offenbar auch keine Admin-Rechte...

D.h., das Gerät mit dem VPNClient war nach dem Herstellen der VPN Verbindung von LAN getrennt.

Dann wurde in dem von Dir gesehenen Netzwerk womöglich was ganz anderes verwendet als es hier möglich ist. Die Daten müssen über den DSL-/Kabel-/Sonstwas-Router gehen, also muss getunnelt werden. Dazu muss das ursprüngliche LAN vorhanden sein und voll funktionieren. Dein "gab es für den PC der den Tunnel aufgebaut hat nicht einmal mehr das eigene LAN" ist im vorliegenden Fall technisch unmöglich.

Mit der Bandbreite hat das überhaupt nichts zu tun.

Es ging da um den Wunsch des VPN-Anbieters, den Traffic zu begrenzen. Da ihm die wirksame Einschränkung auf ein oder eine bestimmte Anzahl von Geräten nicht wirklich möglich ist, wenn der Besitzers mindestens eines der Geräte weiß was er tut, kann er, um sein Interesse an einer Limitierung durchzusetzen, nur den Traffic begrenzen. Weil er ja nicht mal erfährt, von welchem Gerät die Daten stammen und zu welchem die Antworten gesendet werden. Ich kann wiederum tunneln, einen NAT-Router betreiben, und/oder mit Proxys arbeiten...

[pl]

Bei den VPNs die wir in unserer Firma hatten, gab es für den PC der den Tunnel aufgebaut hat nicht einmal mehr das eigene LAN.

Ja. Aber da hatten die Benutzer offenbar auch keine Admin-Rechte...

Auch das hat mit VPN gar nichts zu tun.

D.h., das Gerät mit dem VPNClient war nach dem Herstellen der VPN Verbindung von LAN getrennt.

Ansonsten wurde womöglich was ganz anderes verwendet als es hier möglich ist. Die Daten müssen über den 8DSL/Kabel/Sonstwas-Router gehen, also muss getunnelt werden. Dazu muss das ursprüngliche LAN vorhanden sein und voll funktionieren. Dein "gab es für den PC der den Tunnel aufgebaut hat nicht einmal mehr das eigene LAN" ist im vorliegenden Fall technisch völlig unmöglich.

Natürlich ist das möglich. Sonst hätten wir das ja nicht so einrichten können. Und natürlich brauchts dazu die LAN Verbindung vom VPNClient zum lokalen Gateway nach draußen. Das LAN gibts ja auch weiterhin, nur halt so daß der PC mit dem VPNClient nicht mehr im LAN erreichbar ist (auch nicht per ping) sondern nur noch im VPN. Was auch Sinn und Zweck eines VPN ist.

MfG

PS: Ich vermute mal, die Dreambox ist der VPNCLient. Und damit man den Ein/Aus schalten kann, wird wohl ein telnet zu diesem Gerät erlaubt sein.

[Regina Schaukrug]

Ja. Aber da hatten die Benutzer offenbar auch keine Admin-Rechte...

Auch das hat mit VPN gar nichts zu tun.

Bitte nimm zur Kenntnis und merke Dir gut, dass es um die Frage geht, ob der VPN-Anbieter den Zugang wirksam und gegen den Widerstand eines wissenden Kunden auf ein oder eine bestimmte Anzahl von Geräten beschränken kann. Ich weiß das, weil ich es nicht nur gestern und vorgestern just auch und nicht nur in einem "ganz sicheren Netzwerk" so betrieben habe.

Ansonsten wurde womöglich was ganz anderes verwendet als es hier möglich ist. Die Daten müssen über den 8DSL/Kabel/Sonstwas-Router gehen, also muss getunnelt werden. Dazu muss das ursprüngliche LAN vorhanden sein und voll funktionieren. Dein "gab es für den PC der den Tunnel aufgebaut hat nicht einmal mehr das eigene LAN" ist im vorliegenden Fall technisch völlig unmöglich.

Natürlich ist das möglich.

Oh, Alter! Bist Du heute wieder ein Sturkopf! Was in einem lokalen Netz mit IPsec geht, geht nicht mehr, wenn der Zugang zum VPN über den Zugang eines ISP mittels Routers stattfindet.

Merkregel hierzu: Wenn Du etwas tunneln willst (hier: musst), dann brauchst Du was, wo hinein Du Deinen Tunnel graben kannst. Bei der Bahn ist das Fels oder Erdreich, beim Netz eine bestehende Verbindung, also das ursprüngliche LAN. Schaltest Du das ab, dann ist der Tunnel "perdu".

[pl]

Ja. Aber da hatten die Benutzer offenbar auch keine Admin-Rechte...

Auch das hat mit VPN gar nichts zu tun.

Bitte nimm zur Kenntnis und merke Dir gut, dass es um die Frage geht, ob der VPN-Anbieter den Zugang wirksam und gegen den Widerstand eines wissenden Kunden auf ein oder eine bestimmte Anzahl von Geräten beschränken kann.

Selbstverständlich kann er das! Einer bezahlt und der ganze Campus guckt Film -- Hallo!?

So blöd ist doch keiner der Filme gegen Bezahlung über VPN anbietet!

Ansonsten wurde womöglich was ganz anderes verwendet als es hier möglich ist. Die Daten müssen über den 8DSL/Kabel/Sonstwas-Router gehen, also muss getunnelt werden. Dazu muss das ursprüngliche LAN vorhanden sein und voll funktionieren.

Nein es muss eben nicht voll funkionieren. Sonst guckt ja der ganze Campus Filme ohne Bezahlung. Was funktionieren muss, und da hast Du natürlich vollkommen Recht, ist die physikalische Verbindung vom VPNClient zu seinem Gateway und DSL.

MfG

[Regina Schaukrug]

Bitte nimm zur Kenntnis und merke Dir gut, dass es um die Frage geht, ob der VPN-Anbieter den Zugang wirksam und gegen den Widerstand eines wissenden Kunden auf ein oder eine bestimmte Anzahl von Geräten beschränken kann.

Selbstverständlich kann er das! Einer bezahlt und der ganze Campus guckt Film -- Hallo!?

Er kann es wollen, aber können kann er es nicht. Die tatsächliche Zahl der letztendlich versorgten Geräte wirksam und gegen den Widerstand einer nicht ahnungslosen Person zu begrenzen ist ihm völlig unmöglich. Beim Traffic sieht das anders aus, denn den kann er so begrenzen, dass es keinen Spaß mehr macht, wenn der "ganze Campus Film guckt" - mithin also die Freigabe durch den Käufer für diesen selbst so nachteilig wird, dass es ihm nicht in den Sinn kommt, "den ganzen Campus mitgucken zu lassen".

[pl]

Bitte nimm zur Kenntnis und merke Dir gut, dass es um die Frage geht, ob der VPN-Anbieter den Zugang wirksam und gegen den Widerstand eines wissenden Kunden auf ein oder eine bestimmte Anzahl von Geräten beschränken kann.

Selbstverständlich kann er das! Einer bezahlt und der ganze Campus guckt Film -- Hallo!?

Er kann es wollen, aber können kann er es nicht. Die tatsächliche Zahl der letztendlich versorgten Geräte wirksam und gegen den Widerstand einer nicht ahnungslosen Person zu begrenzen ist ihm völlig unmöglich.

Da bist Du falsch informiert in Sachen VPN.

MfG

[Regina Schaukrug]

Bitte nimm zur Kenntnis und merke Dir gut, dass es um die Frage geht, ob der VPN-Anbieter den Zugang wirksam und gegen den Widerstand eines wissenden Kunden auf ein oder eine bestimmte Anzahl von Geräten beschränken kann.

Selbstverständlich kann er das! Einer bezahlt und der ganze Campus guckt Film -- Hallo!?

Er kann es wollen, aber können kann er es nicht. Die tatsächliche Zahl der letztendlich versorgten Geräte wirksam und gegen den Widerstand einer nicht ahnungslosen Person zu begrenzen ist ihm völlig unmöglich.

Da bist Du falsch informiert in Sachen VPN.

Nein. Du willst die Problematik nur nicht zu Ende denken. Die Zahl der am VPN unmittelbar teilnehmende Geräte ist, seit der Erfindung von NAT, Sockets und Proxys nicht zwingend identisch mit der Anzahl der Geräte, deren Traffic über das VPN geht, bzw. die über das VPN Zugriff auf Ressourcen erhalten. (PDF, 40 kB)

[Regina Schaukrug]

Was funktionieren muss, und da hast Du natürlich vollkommen Recht, ist die physikalische Verbindung vom VPNClient zu seinem Gateway und DSL.

Nein nicht nur OSI-Level 1, sondern auch OSI-Level 2 und 3 müssen funktionieren. (Womit also zwingend auch ein logisches Netzwerk besteht!) Demnach gehen dann auch OSI-Level 4 bis 7. Selbst wenn irgendwelche Einstellungen (Routen) so gesetzt werden, dass das ursprüngliche LAN (zunächst) nicht mehr (ohne weiteres) benutzbar ist, so kann der wissende Kunde mit Admin/Root-Rechten alles wieder so ändern, wie er es braucht - also weitere Geräte versorgen.

[JürgenB]

Hallo,

wenn ich die IP-Adresse zu einem Namen suche, nehem ich erst mal ping.

Gruß
Jürgen

[Fred]

Hallo,

wenn ich die IP-Adresse zu einem Namen suche, nehem ich erst mal ping.

ich denke mal der Karl Heinz möchte seine öffentliche IP erfahren ohne das er einen DNS Namen wie z.B. von dnydns hat.

Gruß
Fred