14.12.2021

3292

Routing in Netzwerk namespace

Hallo. Ich habe ein problem. Bzw komme ich einfach nicht weiter.

Mein vorhaben: um meine Internetleitung zu entlasten möchte ich ein Programm über eine Andere Netzwerkschnittstelle ins internet gehen lassen.

um das zu erreichen habe ich einen Netzwerk namespace namens "mobilfunk" erstellt.

Hier der script was beim hochfahren ausgeführt wird:

#!/bin/bash
nsname=mobilfunk
NIC=eth1
Gateway=192.168.8.1
IPAddr=192.168.8.10
DNS=9.9.9.9

#alte netns löschen
if [ -f /var/run/netns/${nsname} ];
then
echo "INFO:::: "${nsname}" wird gelöscht."  
ip netns del ${nsname}
else
echo "INFO:::: "${nsname}" nicht vorhanden."  
fi

#ip -all netns delete
ip netns add ${nsname} && echo ${nsname}" erstellt"  
ip link set dev ${NIC} netns ${nsname} && echo ${NIC} " wurde " ${nsname} "zugeordnet."    
ip netns exec ${nsname} ifconfig ${NIC} ${IPAddr}/24 up && echo ${NIC} " wurde " ${IPAddr} "zugewiesen."  
ip netns exec ${nsname} ifconfig lo 127.0.0.1/8 up && echo "lokale schleige wurde erstellt."  
ip netns exec ${nsname} route add default gw ${Gateway} && echo "Gateway " ${Gateway} " erstellt."  
#ip netns exec ${nsname} dhcpcd ${NIC} && echo "dhcpcd ausgeführt" 

#DNS Server hinzufügen

if [ -d /etc/netns/ ];
then
echo "INFO:::: ""netns-Ordner vorhanden."  
else
echo "INFO:::: ""netns-Ordner fehlt!"  
mkdir /etc/netns
fi


if [ -d /etc/netns/${nsname}/ ];
then
echo "INFO:::: "${nsname}"-Ordner vorhanden"  
echo "nameserver "${DNS} > /etc/netns/${nsname}/resolv.conf && echo "nameserver "${DNS} " in Datei /etc/netns/"${nsname}"/resolv.conf geschrieben"  
else
echo "INFO:::: "${nsname}"-Ordner fehlt"  
mkdir /etc/netns/${nsname}
echo "nameserver "${DNS} > /etc/netns/${nsname}/resolv.conf  
fi

exit 0;

danach wir dann das Programm gestartet und eine weboberfläsche ist unter dem port 6666 erreichbar.

gehe ich in das netzwerk vom mobilfunkrouter kann ich die oberfläsche öffnen und bedienen. Das bringt mir aber leider nix da weitere anwendungen zugriff auf die oberfläsche brauchen.

wo das Programm noch ohne Namespace gelaufen ist habe ich in den anderen Programmen die Adresse 127.0.0.1 verwendet.

hier nochmal die Zusammenfassung:
1 Server mit 2 Lan karten (eth0 -> IP 192.168.220.xx und eth1 -> IP 192.168.8.xx)
eth0 -> ist im hauptnetz , alle clients haben über diese schnittstelle zugriff auf den Server
eth1 -> hängt an einem mobilfunkrouter und befindet sich in einem Namespace namens "mobilfunk"
das Programm "xyz" wird im NS ausgeführt und geht übers mobilfunknetz ins internet, die weboberfläsche hat den port 6666
das Programm "abc" wird normal ausgeführt und braucht irgendwie zugriff zum programmm "xyz"

Vermutlich benötige ich ein veth um dann irgendwie beide netze "verbinden" zu können. Habe einige Anleitungen mal ausprobiert aber leider hat das nicht zum erfolg geführt.

z.b. das hier

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1618062033

Url: https://administrator.de/forum/routing-in-netzwerk-namespace-1618062033.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

38 Kommentare

Neuester Kommentar

Vermutlich benötige ich ein veth um dann irgendwie beide netze "verbinden" zu können.

Nö du musst deinem Namespace auch die Route zu deinem 220er Netz mitteilen denn die legst du dort ja gar nicht an, ergo versucht der Namespace die 220er IPs über das GW 192.168.8.1 aufzulösen welches das Netz 192.168.220.0/24 aber gar nicht kennt

Okay. Und wie Teile ich dem namespace das mit . Bzw. Wie würde der Befehl dann lauten ?

Zitat von @FlorianHe:

Okay. Und wie Teile ich dem namespace das mit . Bzw. Wie würde der Befehl dann lauten ?

Na wie fügt man denn wohl Routen hinzu?!
ip route add --help
https://www.cyberciti.biz/faq/linux-route-add/
Das ganze macht's du für deinen Namespace feddisch. Du sagst damit einfach der Routing Tabelle des Namespace an welchem Interface dein 220er Netz erreichbar ist und schon ist das asynchrone Routing Vergangenheit 😉🖖

Also so

 ip netns exec mobilfunk ip route add 192.168.220.0/24 via 192.168.8.10

?

Mus ich dann auf dem Hostsystem auch eine Route hinzufügen?

Komisch, im ersten Versuch hat doch alles wunderbar geklappt...?! 🤔

Zitat von @FlorianHe:

Also so

 ip netns exec mobilfunk ip route add 192.168.220.0/24 via 192.168.8.10

Nein, du musst der route sagen an welchem Interface sie in dem Fall anliegt.

Mus ich dann auf dem Hostsystem auch eine Route hinzufügen?

Nein das kennt beide Netze durch die Standard-Routing-Tabellle, ganz im Gegensatz zur Routing-Tabelle deines Namespace dem musst du das mit der Route erst mal mitteilen, denn sonst schickt der Namespace wie gesagt Traffic an 192.168.220.0/24 über sein Default GW und das ist im Namespace der Mobilfunkrouter der das Netz eben nicht kennt und somit die Pakete im Internet-Nirvana landen.

ip netns exec mobilfunk ip route add 192.168.220.0/24 dev eth0

Zitat von @aqui:

Komisch, im [contentid:1606887920 ersten_Versuch] hat doch alles wunderbar geklappt...?! 🤔

ja. leider hat sich dann rausgestellt das es doch nicht so ist. und ich wollte erstmal selber probieren.

Meine Routingtabelle im namespace sieht jetzt so aus

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.8.1     0.0.0.0         UG    0      0        0 eth1
192.168.8.0     *               255.255.255.0   U     0      0        0 eth1
192.168.220.0   192.168.8.10    255.255.255.0   UG    0      0        0 eth1

wenn ich jetzt z.b. den router (192.168.220.1) anpingen möchte geht es irgendwie trotzdem nicht

> ip netns exec mobilfunk ip route add 192.168.220.0/24 dev eth0
> 

wenn ich diesen Befehl ausführe kommt die meldung

Cannot find device "eth0"

Musst du ja erst mal hinzufügen ...
https://linux.die.net/man/8/ip

Heute schon wieder Freitag?

Zitat von @149569:

Musst du ja erst mal hinzufügen ...

okay. sorry das ich mich so dämlich anstelle aber eth0 ist ja schon angelegt. das ist ja die schnittstelle die im 220er netz hängt.

Also dann mal zu Fuß.

Du brauchst erst mal auf dem Host ein veth das mit einem weiteren veth in dem Namespace verbunden wird.

ip link add veth0 type veth peer name veth1

Dann musst du das veth1 Interface als erstes dem Namespace zuweisen denn jetzt ist es ja noch dem globalen Namespace zugewiesen:

ip link set veth1 netns Mobilfunk

Dann musst du das veth0 zusammen mit dem eth0 des Hosts in eine Bridge packen (Man kann auch über eine separate IP routen, aber das lass ich jetzt mal).

# bridge erstellen
ip link add br0 type bridge
# eth0 des Hosts zur Bridge hinzufügen
ip link set eth0 master br0
# veth0 zur Bridge hinzufügen
ip link set veth0 master br0

Jetzt braucht der Namespace für das veth1 Interface noch eine neue IP-Adresse aus dem Netz von eth0 des Hosts (nehme ich einfach mal die .34)

# link aktivieren
ip netns exec Mobilfunk ip link set veth1 up
# ip zu veth1 im Namespace zuweisen
ip netns exec Mobilfunk ip address add 192.168.220.34/24 dev veth1

Nun sollte ein Ping aus dem Namespace heraus in das 220er Netz funktionieren

ip netns exec Mobilfunk ping 192.168.220.1

Ebenso sollte vom Host bzw. im 220er Netz ein Ping auf 192.168.220.34 funktionieren.

Hier wird das ganze auch nochmal beschrieben
https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespac ...

Habe ich hier auch nochmal einwandfrei getestet, funktioniert wie gewünscht.

Bildlich dargestellt sieht das geschilderte dann so aus:

Der Namespace ist also über die veth mit dem HOST verbunden und da veth0 in einer Bridge mit eth0 liegt lässt sich dem Namespace auch eine IP aus dem Netz von eth0 verpassen weil die Interfaces in einer gemeinsamen Layer-2 Domain liegen.

wow danke für die Detaillierte Antwort. das hat mir echt geholfen um erstmal das grundlegende zu verstehen.

leider komme ich an einer stelle nicht weiter.

ich starte das script was ich zuerst gepostet habe.

dann führe ich die befehle aus die du gepostet hast.

un ab dem Befehl

ip link set eth0 master br0

bricht die ssh verbindung ab und der Server ist nicht mehr erreichbar.

Habe dann einen Monitor an den PC gemacht und die restlichen Befehle dort eingegeben.

wenn ich den Befehl

sudo ip netns exec Mobilfunk ip link veth1 up

eingebe kommt die Meldung "Command veth1 is unknown"

gebe ich ifconfig -a ein (im Namespace) wird mir die virtuelle karte angezeigt.

habe dann den Befehl in

sudo ip netns exec Mobilfunk ip link set dev veth1 up

geändert und dann wurde der Befehl richtig ausgeführt

ich habe dann noch die ip-Adresse vergeben und dann die netzwerkverbindung getestet. Leider ist der Server immer noch nicht erreichbar.

woran kann das liegen ? kann das sein das die Brücke noch aktiviert werden muss und vom dhcp ne ip adresse braucht ?

Zitat von @FlorianHe:
un ab dem Befehl

ip link set eth0 master br0

bricht die ssh verbindung ab und der Server ist nicht mehr erreichbar.

Wenn du über die selbe Verbindung rein kommst sägst du dir natürlich erst mal den Ast ab auf dem du sitzt, das ist normal

habe dann den Befehl in

sudo ip netns exec Mobilfunk ip link set dev veth1 up

geändert und dann wurde der Befehl richtig ausgeführt

War ein Typo sorry is oben korrigiert.

ich habe dann noch die ip-Adresse vergeben und dann die netzwerkverbindung getestet. Leider ist der Server immer noch nicht erreichbar.

woran kann das liegen ? kann das sein das die Brücke noch aktiviert werden muss und vom dhcp ne ip adresse braucht ?

Der Brücke muss natürlich dann die IP-Adresse zugewiesen werden die vorher eth0 hatte, wenn du dessen Dienste darüber von Remote anprichst, korrekt denn die Brücke ist nun die Verbindung zur Außenwelt für den Host.
Dachte zumindest diese Grundlagen wären vorhanden, wohl falsch gedacht

hab leider von Sachen Netzwerk gar kein Plan.

wie bekomme ich das hin das die brücke sich die ip adresse vom dhcp server holt ?
find im internet nur den weg über /etc/network/interfaces aber gibts doch bestimmt auch einen Befehl oder ?

Zitat von @FlorianHe:
wie bekomme ich das hin das die brücke sich die ip adresse vom dhcp server holt ?
find im internet nur den weg über /etc/network/interfaces aber gibts doch bestimmt auch einen Befehl oder ?

Im Normalfall konfiguriert man sowas ja nicht per Skript sondern hinterlegt die Konfiguration fest einmalig im Networkmanager seiner Wahl dann ist Skripting hier überflüssig und auch zuverlässiger.
Wenn man dhcpcd einsetzt dann kann man natürlich auch auf der Shell manuell nachhelfen

# release lease
dhcpcd -k eth0
# request new lease on br0
dhcpcd -n br0

Aber wie gesagt, das konfiguriert man in seinem Networkmanager., das hier ist nur für das erstmalige Testen gedacht. Welchen Networkmanager du von der Menge an Möglichen einsetzt können wir hier natürlich nur raten.

Wenn's das dann war bitte auf gelöst setzen. Danke.

Gruß /h

Super. vielen vielen Dank.
Das werde ich dann nachher gleich mal testen. Das mit der Konfiguration im Network Manager werde ich mir dann anschauen wenn es per Script ordnungsgemäß funktioniert.

Hi. ich muss nochmal mit Fragen nerven. ;)
Ich bin leider immernoch dabei mein Dienst der im Namespace laufen soll zugang zum anderen Internet zu verschaffen.

Und ich weiß jetzt endlich auch woran es habert.

wenn ich ganz normal auf dem Hostsystem den Befehl

curl https://xxxxxxxxxxxxx.ddns.net:10000/

eigebe wird die Seite bzw der Html code der Seite angezeigt

führe ich den Befehl im Namespace aus kommt der Fehler:
curl: (7) Failed to connect to xxxxxxxxxx.ddns.net port 10000: Verbindungsaufbau abgelehnt

Das komische ist wenn ich eine Seite im Namespace mit curl aufrufe ohne angabe des Ports funktioniert es.
Ich kann also im namespace keine urls aufrufen die auf einem anderen port liegen.

wo liegt da der Fehler?

Zitat von @FlorianHe:
wenn ich ganz normal auf dem Hostsystem den Befehl

curl https://xxxxxxxxxxxxx.ddns.net:10000/

Kann ich hier nicht nachstellen, klappt hier beim Nachstellen problemlos. Vermutlich sperrt dein anderer Anbieter den Port oder du hast eine Firewall die den Port im NS sperrt oder du hast in der Firewall des Ziels den Source Address Range des anderen Anbieters geblockt , oder du hast dir ein Loopback(Hairpin)-NAT Problem gebaut wenn die Dienste die du via dyndns erreichen willst in dein eigenes Netz zeigen. Ein tcpdump oder wireshark trace sollte dir zeigen was Sache ist.

Habe so mehr oder weniger die Ursache gefunden.
Die Netzwerkkarte die im namespace hängt ist an einem Huawei mobilfunkrouter.

Ich habe die netzwerkkarte mal testweise mal das Gastnetz meiner FRITZ!Box angeschlossen. Da war das selbe Problem. Habe dann ne Weile in den FRITZ!Box Einstellungen rum gesucht und da war der Fehler. Im gastnetz war ein zugangsprofil erstellt was nur surfen und mailen zulässt. Hab das dann mal gelöscht und schon ging es.

Da meine FRITZ!Box auch LTE kann hab ich mal aus dem huawei Router die sim in die FRITZ!Box getan. Jetzt konnte der Dienst auch übers Mobilfunknetz im namespace seine Verbindungen aufbauen.

Muss jetzt nurnoch herausfinden wieso sich der huawei Router weigert. Leider sind dort die Einstellungsmöglichkeiten begrenzt.

Hab mal mit Netstat die Verbindungen anzeigen lassen

 root@tvserverv1:~# netstat -tp
Aktive Internetverbindungen (ohne Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 172.31.179.30:51450     vmi44491.xxx:18000 VERBUNDEN   3859/xxx     
tcp        0      0 172.31.179.30:45722     vmi15572.xxxx.:12000 VERBUNDEN   3859/xxx     
tcp        0      0 172.31.179.30:40264     vmi15572.xxxx.:13000 VERBUNDEN   3859/xxx     
tcp        0      0 172.31.179.30:42096     vmi44491.xxx:19000 VERBUNDEN   3859/xxx     
tcp        0      0 172.31.179.30:45556     vmi44491.xxx:11000 VERBUNDEN   3859/xxx     
tcp        0      0 172.31.179.30:60814     vmi304401.xxx:14200 VERBUNDEN   3859/xxx      
tcp        0      0 172.31.179.30:33218     vmi304401.xxx:13000 VERBUNDEN   3859/xxx      
tcp6       0      0 192.168.220.34:1234     192.168.220.35:44640    VERBUNDEN   3859/xxx 

Theoretisch muss ich im Router die Ports 11000 12000 usw freigeben.

Zitat von @149569:
Ein tcpdump oder wireshark trace sollte dir zeigen was Sache ist.

Danke für den Tipp. Das werde ich mir gleich mal anschauen was das ist. Vielleicht hilft mir das auch bei späteren Fehlersuchen

Schönes Wochenende

Theoretisch muss ich im Router die Ports 11000 12000 usw freigeben.

Ausgehend sollten diese im Normalfall nicht geblockt werden wenn du nichts verstellt hast. Natürlich solltest du auch erst mal ohne Namespace prüfen ob über die Mobilfunkverbindung deines Providers die Ports auch nicht blockiert sind. Ich würde dir aber raten das ganze über ein VPN abzufackeln dann ist die Nutzung von non standard ports im LTE Netz nicht mehr nötig weil alles getunnelt über die VPN Verbindung läuft.

Ich hätte nochmal eine Frage zum Routing.

ist es möglich vom Hostsystem aus einen Teilnehmer im Namespacenetz anzupingen?

wenn ich z.b.

ip route add 192.168.8.0/24 via 192.168.220.34 dev br0

im Hostsystem einfüge kann ich die Netzwekkarte eth1 (ip Adresse 192.168.8.113) anpingen.

wenn ich den router des 2. netzes anpingen möchte ist er leider nicht erreichbar. Wie stellt man das an das der rechner weis wenn ich 192.168.8.1 anpingen möchte (vom Hostsystem aus) das der weg über br0-veth0-veth1-eth1 zurückgelegt werden muss.

übrigens das mit dem VPN habe ich mal probiert. und da ist es genau das selbe. hab ich den lte router am netz kann die vpn verbindung nicht aufgebaut werden. nehme ich die fritzbox geht es. ich versteh einfach nicht was das huawei Teil für ein problem hat und die verbindungen blockt. ich will jetzt als nächstes mal probieren ein handy als hotspot zu verwenden was mit einem alten wlan ap verbunden ist der dann mit lan an eth1 hängt. ich bin mal gespannt ob das klappt.

hab ich den lte router am netz kann die vpn verbindung nicht aufgebaut werden.

Das kann sehr gut sein, denn im LTE Netz werden bei Billigprovidern immer im Internet nicht routebare RFC 1918 oder RFC 6598 v4 IP Adressen eingesetzt mit zentralem CGN (DS-Lite). Damit ist ein VPN zumindestens als Dialin mit IPv4 technisch unmöglich.
Kannst du ganz einfach klären wenn du im Huawei Dashboard mal auf die zugeteilte WAN IP siehst.
Die FritzBox nutzt vermutlich xDSL mit einer öffentlichen IP. Leider machst du dazu keine oder nur sehr oberflächliche Aussagen um das zielführend beurteilen zu können.

Man bekommt das aber in der regel einfach gefixt indem man einen anderen APN nutzt im Mobilnetz. Bei den meisten Billigprovidern geht das aber mit einem Tarifwechsel einher. Hängt also von deinen Vertragsoptionen ab.

also aktuell hat der Huawei router volgende IP#s
ipv4. 10.112.xx.xxx
ipv6 2a02:3037:000b:fd80.......

wie die IP Adressen lauten wenn ich die Simkarte im Fritzboxrouter verwende kann ich gerade leider nicht testen da ich nicht vorort bin.

auf jeden all war es halt so das die internet verbindung im gastnetz der Fritzbox erst richtig ging als ich in den Fritzboxeinstellungen die zugangsprofile so geändert habe das alles zugelassen ist (vorher war "nur surfen und mailen" aktiviert)

vllt. noch zur info. die verbindung hatte ich jetzt immer mit

curl wttr.in

getestet.

wenn ich z.b.

curl google.de

nehme geht es immer.

also wenn ich den fritzbox router am namespace anschließe geht curl google.de und curl wttr.in
und wenn ich den huawei router mit der gleichen Simkarte am namespace anschließe geht curl google.de und curl wttr.in nicht

ipv4. 10.112.xx.xxx

Wie es zu erwarten war... Im Internet nicht geroutete RFC 1918 IP. Damit ist ein v4 VPN technisch unmöglich ! Zumindestens mit dem Mobilfunk Vertrag den du hast. Da hast du völlig falsche Vertragsoptionen abgeschlossen. Auf sowas achtet man doch logischerweise immer VORHER. Siehe dazu auch:
https://de.wikipedia.org/wiki/IPv6#Dual-Stack_Lite_(DS-Lite)
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...
Du kannst aber problemlos IPv6 nutzen für das VPN. Das ist eine öffentliche v6 Adresse !

in den Fritzboxeinstellungen die zugangsprofile so geändert habe das alles zugelassen ist (vorher war "nur surfen und mailen" aktiviert)

Logisch, denn VPN Traffic ist eben nicht nur TCP 80, 443 bzw. Email Ports. Sagt einem aber auch schon der gesunde IT Verstand.

gut. das ist selbst mir klar.

aber was ich nicht verstehe das so eine simple seite wie wttr.in nicht geht und google.de aber funktioniert (unabhängig von der VPN)

Löse die einfach mal in ihre Ziel IPs auf mit nslookup und checke mal ob das ggf. andere Routing Wege bei deinem Setup nimmt...

xxx@tvserverv1:/etc$ nslookup
> wttr.in
Server:         192.168.220.35
Address:        192.168.220.35#53

Non-authoritative answer:
Name:   wttr.in
Address: 5.9.243.187
>

die ip-Adresse ist bei beiden die selbe. der DNS-Server ebenfalls.

die routen sind unterschiedlich aber der zielserver ist der gleiche:

hier das hostsystem mit dsl zugang

tvadmin@tvserverv1:~$ traceroute wttr.in
traceroute to wttr.in (5.9.243.187), 30 hops max, 60 byte packets
fritz.box (192.168.220.1)  0.902 ms  1.252 ms  2.123 ms
p3e9bf74d.dip0.t-ipconnect.de (62.155.247.77)  15.033 ms  15.032 ms  15.364 ms
n-ea9-i.N.DE.NET.DTAG.DE (62.154.24.218)  27.420 ms  27.418 ms  27.497 ms
n-ea9-i.N.DE.NET.DTAG.DE (62.154.24.218)  27.486 ms  27.571 ms  33.691 ms
* * *
core23.fsn1.hetzner.com (213.239.252.246)  30.188 ms core24.fsn1.hetzner.com (213.239.252.250)  26.413 ms  19.615 ms
ex9k1.dc7.fsn1.hetzner.com (213.239.229.238)  18.567 ms ex9k1.dc7.fsn1.hetzner.com (213.239.229.234)  20.361 ms ex9k1.dc7.fsn1.hetzner.com (213.239.229.238)  21.470 ms
b6.xgu.ru (5.9.32.177)  22.315 ms  18.125 ms  18.673 ms
static.187.243.9.5.clients.your-server.de (5.9.243.187)  22.394 ms  22.768 ms  23.398 ms
tvadmin@tvserverv1:~$

hier das namespace mit LTE zugang

root@tvserverv1:~# traceroute wttr.in
traceroute to wttr.in (5.9.243.187), 30 hops max, 60 byte packets
192.168.8.1 (192.168.8.1)  2.053 ms  6.056 ms  6.092 ms
* * *
10.81.85.1 (10.81.85.1)  48.212 ms  47.430 ms  47.930 ms
* 10.81.85.22 (10.81.85.22)  48.808 ms *
10.81.121.145 (10.81.121.145)  50.362 ms  50.938 ms  51.690 ms
195.71.45.211 (195.71.45.211)  60.151 ms * 195.71.45.209 (195.71.45.209)  55.764 ms
ae6-0.0001.prrx.09.fra.de.net.telefonica.de (62.53.5.73)  55.183 ms ae7-0.0001.prrx.09.fra.de.net.telefonica.de (62.53.5.75)  31.555 ms  30.896 ms
telefonica-gw.hetzner.com (62.52.230.22)  30.140 ms  52.956 ms  50.778 ms
core4.fra.hetzner.com (213.239.224.177)  51.279 ms core1.fra.hetzner.com (213.239.224.173)  50.095 ms  41.885 ms
core23.fsn1.hetzner.com (213.239.229.74)  54.814 ms core24.fsn1.hetzner.com (213.239.229.78)  41.106 ms *
ex9k1.dc7.fsn1.hetzner.com (213.239.229.238)  43.961 ms  44.727 ms  42.312 ms
b6.xgu.ru (5.9.32.177)  41.510 ms  41.219 ms  42.216 ms
static.187.243.9.5.clients.your-server.de (5.9.243.187)  42.273 ms  46.500 ms  33.444 ms
root@tvserverv1:~#

wenn ich mit dem laptop ins wlan des mobilfunkrouters gehe funktioniert komischerweise der befehl curl wttr.in

die route ist auch die selbe:

Florians-MacBook-Pro:~ florian$ traceroute wttr.in
traceroute to wttr.in (5.9.243.187), 64 hops max, 52 byte packets
 1  192.168.8.1 (192.168.8.1)  3.118 ms  2.018 ms  1.922 ms
 2  * * *
 3  10.81.85.1 (10.81.85.1)  51.484 ms  46.334 ms  38.585 ms
 4  * * *
 5  10.81.121.145 (10.81.121.145)  39.748 ms  38.504 ms  39.514 ms
 6  195.71.45.209 (195.71.45.209)  34.385 ms
    195.71.45.211 (195.71.45.211)  32.656 ms  38.452 ms
 7  ae7-0.0001.prrx.09.fra.de.net.telefonica.de (62.53.5.75)  39.027 ms  41.841 ms  46.909 ms
 8  telefonica-gw.hetzner.com (62.52.230.22)  39.208 ms  31.127 ms  47.629 ms
 9  core1.fra.hetzner.com (213.239.224.173)  28.935 ms
    core4.fra.hetzner.com (213.239.224.177)  32.878 ms
    core5.fra.hetzner.com (213.239.224.222)  32.409 ms
10  core23.fsn1.hetzner.com (213.239.224.249)  60.025 ms
    core23.fsn1.hetzner.com (213.239.203.154)  53.685 ms  51.631 ms
11  ex9k1.dc7.fsn1.hetzner.com (213.239.229.238)  55.970 ms
    ex9k1.dc7.fsn1.hetzner.com (213.239.229.234)  41.586 ms
    ex9k1.dc7.fsn1.hetzner.com (213.239.229.238)  42.005 ms
12  b6.xgu.ru (5.9.32.177)  37.683 ms  43.996 ms  48.890 ms
13  static.187.243.9.5.clients.your-server.de (5.9.243.187)  32.053 ms  32.873 ms  40.095 ms

die ip-Adresse ist bei beiden die selbe.

Es ging logischerweise nur um das Webserver Ziel und die Hops dahinzukommen. Irgendwo muss ja im Hop Pfad zu wttr.in etwas TCP 80 oder 443 blocken. DNS spielt doch da kein Rollo !!
Das Google und wttr.in dasselbe sein soll gehört wohl ins Reich der Märchen...
Tip:
Traceroute auf dem Mac sollte man wegen der Vergleichbarkeit zu anderen Plattformen besser immer mit "-I" laufen lassen ansonsten macht der kein ICMP wie andere Endgeräte sondern TCP Pings.

Zitat von @aqui:
Das Google und wttr.in dasselbe sein soll gehört wohl ins Reich der Märchen...

Oh. Da habe ich ausversehen das falsche gepostet.

Ich hab mir jetzt erstmal ne Notlösung gebaut. Ich habe ein altes Handy genommen, da die sim aus dem Router rein gesteckt dann einen Hotspot aktiviert und mit einem alten alten accespoint als WLAN zu LAN Brücke genommen was dann am ethernetanschluss für den namespace angeschlossen. Jetzt kann der Dienst seine Daten aus dem Internet holen.

Ich werde mir jetzt die Tage einen anderen mobilfunkrouter besorgen. Ich hoffe mal das das mit dem dann auch so gut geht

Weißt du eig ob das routen vom hostsystem ins namespacenetz möglich ist?

Zitat von @FlorianHe:

Ich hätte nochmal eine Frage zum Routing.

ist es möglich vom Hostsystem aus einen Teilnehmer im Namespacenetz anzupingen?

wenn ich z.b.

ip route add 192.168.8.0/24 via 192.168.220.34 dev br0

Weißt du eig ob das routen vom hostsystem ins namespacenetz möglich ist?

Steht doch oben, einfach nur die Brücke weglassen und veth0 und veth1 jeweils eine eigene IP aus dem gleichen Subnetz vergeben, feddisch ist der Käse. Mit der Brücke hast du ja schon Kontakt zum Namespace weil dieser dann mit einem Bein im lokalen Netz und mit dem anderen Bein am LTE Netz hängt.

Achso und dann füge ich auf dem hostsystem die Route hinzu

Gehen wir mal davon aus das veth0 192.168.220.31 hat und veth1 die 32 dann muss die Route so lauten? :

IP Route add 192.168.8.0/24 dev veth0

Zitat von @FlorianHe:

Achso und dann füge ich auf dem hostsystem die Route hinzu

Nein! Der Host kennt das Netz dann bereits weil er eine Adresse davon besitzt, eine Route hinzufügen ist also Blödsinn!

Gehen wir mal davon aus das veth0 192.168.220.31 hat und veth1 die 32 dann muss die Route so lauten? :

Du brauchst keine Route, weil die Interfaces direkt am Host existieren und dieser das Netz durch die dem Interface zugewiesenen Adressen bereits kennt und in der Routing-Tabelle bereits die Einträge automatisch hinzugefügt werden wenn man den Interfaces eine IP zuweist!
Außerdem solltest du ein separates Subnetz dafür nehmen nicht das das am Host ins lokale Netz führt sondern ein anderes, also bspw. 192.168.230.0/30, da ja eh nur zwei Devices beteiligt sind reicht hier dann ein 30er Subnetz, 192.168.230.1/30 für den Host und 192.168.230.2/30 für den Namespace.

Das sind jetzt aber absolute Routing Grundlagen min Jung.

Tut mir leid das ich mich mit den routing grundlagen noch so schwer tue.

nur wenn ich auf dem host keine route anlegen muss woher weis der dann wenn ich z.b. ping 192.168.8.112 ausführe das er über 192.168.230.1(veth0)-192.168.230.28(veth1)-192.168.8.111(eth1)-192.168.8.1(default gw)-192.168.8.112(teilnehmer im netz2) gehen muss ?

woher weis der dann wenn ich z.b. ping 192.168.8.112

Den kompletten Pfad kennt er nicht, zumindestens nicht bei statischem Routing. Der gesamte Pfad ergibt sich nach den an den Hops eingetragenen Routen. Der Routing Weg wird immer Hop für Hop entschieden.
Der Host auf dem du den Ping absetzt sieht also zuerst in seine eigene Routing Tabelle und wählt dort die Route aus. Dabei gilt bei mehrfachen Routen zum Ziel immer der best longest prefix match sprich also die Route mit dem größten Prefix (Netzmaske) die den Weg zum Ziel definiert.
An das Gateway schickt der Ping Host das Paket und an dem Gateway wird dann wieder wie oben neu entschieden usw. bis zum Ziel.
Ganz einfach Logik wo man sich nun wahrlich nicht schwer tun muss.

okay. also ich habe jetzt 2 virtuelle netzwerke angelegt veth3(192.168.230.1) und veth4(192.168.230.2)

routingtabelle host:

host@server:~$ route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    207    0        0 br0
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0
192.168.220.0   *               255.255.255.0   U     207    0        0 br0
192.168.230.0   *               255.255.255.252 U     0      0        0 veth3

routingtabelle namespace:

namespace@server:~# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.43.1    0.0.0.0         UG    203    0        0 eth1
192.168.43.0    *               255.255.255.0   U     203    0        0 eth1
192.168.220.0   *               255.255.255.0   U     0      0        0 veth1
192.168.230.0   *               255.255.255.252 U     0      0        0 veth4

pinge ich jetzt 192.168.43.1 aus dem hostsystem an (da mein handy momentan als router dient ist es jetzt 43.1 und nicht 8.1) schlägt es fehl

laut traceroute geht es ja direkt zur fritzbox. Und das ist ja nicht richtig. ich muss doch irgendwie sagen "gehe über 230.1" und 230.1 muss dann sagen "gehe zu 230.2" usw.

host@server:~$ traceroute 192.168.43.1
traceroute to 192.168.43.1 (192.168.43.1), 30 hops max, 60 byte packets
 1  fritz.box (192.168.220.1)  0.650 ms  0.712 ms  0.759 ms
 2  p3e9bf74d.dip0.t-ipconnect.de (62.155.247.77)  9.247 ms !N  9.387 ms !N  9.356 ms !N
tvadmin@tvserverv1:~$

die brücke veth0 und veth1 habe ich noch drin gelassen weil die schnittstellen noch in verwendung sind.

ich habe jetzt 2 virtuelle netzwerke angelegt veth3(192.168.230.1) und veth4(192.168.230.2)

Das ist jetzt aber dreist gelogen, denn das sind wie man ja unschwer sehen kann keine 2 IP Netze sondern 2 Hostadressen im gleichen IP Netz !
Normal funktioniert das so NICHT auf Interfaces die nicht per Layer 2 Bridging miteinander verbunden sind, denn die erzwingen immer einzigartige Netzwerk Adressen. Klar, denn sonst wäre eine eindeutige Wegefindung ja unmöglich. Bei virtuellen Interfaces sollte das ähnlich sein.

Zitat von @aqui:

ich habe jetzt 2 virtuelle netzwerke angelegt veth3(192.168.230.1) und veth4(192.168.230.2)

Das ist jetzt aber dreist gelogen, denn das sind wie man ja unschwer sehen kann keine 2 IP Netze sondern 2 Hostadressen im gleichen IP Netz !

okay das war flasch ausgedrückt. ich meine ich habe 2 virtuelle netzwerkschnittstellen angelegt.

veth3 mit der IP Adresse 192.168.230.1
veth4 mit der IP Adresse 192.168.230.2

Ich habe jetzt noch eine weitere Route auf der Host-seite hinzugefügt

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.43.0    192.168.230.2   255.255.255.0   UG    0      0        0 veth3

jetzt passiert folgendes:

traceroute 192.168.43.1
traceroute to 192.168.43.1 (192.168.43.1), 30 hops max, 60 byte packets
192.168.230.2 (192.168.230.2)  0.127 ms  0.095 ms  0.051 ms
* * *
* * *
* * *
* * *

der erste hop ist somit schonmal richtig. jetzt muss ich nurnoch herausfinden wie ich der Schnittstelle veth4 sage das die anfrage an eth1 weitergereicht werden soll.

Zitat von @aqui:

Normal funktioniert das so NICHT auf Interfaces die nicht per Layer 2 Bridging miteinander verbunden sind, denn die erzwingen immer einzigartige Netzwerk Adressen. Klar, denn sonst wäre eine eindeutige Wegefindung ja unmöglich. Bei virtuellen Interfaces sollte das ähnlich sein.

wie könnte ich das dann lösen?

Hallo. Habe endlich das erreicht was ich wollte. Ich kann jetzt mit einem Gerät was mit meinem hauptnetzwerk verbunden ist auf das Netzwerk zugreifen was mit dem Namespace meines Linux rechners verbunden ist.

Ich würde jetzt nochmal abschließend meine lösung posten sodass andere leute die mal das selbe vorhaben leichter ans ziel kommen.

Ich hoffe mal die Beschreibungen der hier verwendeten Befehle stimmen. Ich gebe es nur so wieder wie ich es verstanden habe. Das ist ja für mich auch das erste mal das ich mich mit routing und generell Netzwerk etwas mehr auseinander setze.

hier nochmal mein aufbau des Netzes:

mein Ziel war es mit dem Linux laptop zugriff auf die Kammera zu bekommen.

um das möglich zu machen sind 4 Sprünge notwendig:
laptop -> Fritz.Box -> Linux-Server -> LTE-Router -> Kammera

zuerst habe ich in Der FritzBox die Route zum Linux-Server hinzugefügt.

IP = 192.168.43.0
Maske = 255.255.255.0
gateway = 192.168.220.35 (linux-server)

dem Hostsystem des Linux rechners wird noch folgende route hinzugefügt:

IP = 192.168.43.0
Maske = 255.255.255.0
gateway = 192.168.230.2

jetzt muss dem kernel des Linux-servers noch gesagt werden das er seine Packete weiterleiten soll.

dazu muss ip forwarding aktiviert werden

echo 1 > /proc/sys/net/ipv4/ip_forward

danach muss dem recher klar gemacht werden das anfragen an eth0 zu veth0 weitergereicht werden sollen.

iptables -t nat -A POSTROUTING -o veth0 -j MASQUERADE

jetzt wird noch die regel erstellt die routing zwischen eth0 zu veth0 zulässt

iptables -A FORWARD -i eth0 -o veth0 -j ACCEPT
iptables -A FORWARD -o eth0 -i veth0 -j ACCEPT

würde man jetzt die Kammera anpingen kommt die Anfrage im Namespace an aber die Kammera wird immer noch nicht erreicht.Die Anfrage muss jetzt noch an eth1 weitergereicht werden.

ip netns exec mobilfunk iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A FORWARD -i eth1 -o veth1 -j ACCEPT
iptables -A FORWARD -o eth1 -i veth1 -j ACCEPT

sind alle routingtabellen richtig angelegt ist die Kammera jetzt erreichbar.

so ist meine Routing-Tabelle auf dem Hostsystem:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.220.1   0.0.0.0         UG    0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 docker0
192.168.43.0    192.168.230.2   255.255.255.0   UG    0      0        0 veth0
192.168.220.0   *               255.255.255.0   U     0      0        0 eth0
192.168.230.0   *               255.255.255.252 U     0      0        0 veth0

und so im Namespace:

Kernel-IP-Routentabelle                                                         
Ziel            Router          Genmask         Flags Metric Ref    Use Iface   
default         192.168.43.1    0.0.0.0         UG    203    0        0 eth1    
192.168.43.0    *               255.255.255.0   U     203    0        0 eth1    
192.168.230.0   *               255.255.255.252 U     0      0        0 veth1 

Macht man jetzt vom Linux Laptop eine anfrage zur Kammera und verfolgt diese mit traceroute erhält man folgende Ausgabe:

Laptop:~ # traceroute 192.168.43.196                                      
traceroute to 192.168.43.196 (192.168.43.196), 30 hops max, 38 byte packets     
 1  192.168.220.1 (192.168.220.1)  0.817 ms  0.523 ms  0.543 ms                 
 2  192.168.220.35 (192.168.220.35)  0.714 ms  0.637 ms  0.722 ms               
 3  192.168.230.2 (192.168.230.2)  0.785 ms  0.777 ms  0.684 ms                 
 4  192.168.43.196 (192.168.43.196)  1.820 ms  1.269 ms  1.268 ms 

zuletzt poste ich mal noch mein script. Es ist zwar noch nicht ganz Fertig aber die grundfunktion funktioniert. Mein Programm bekommt internet aus dem Mobilfunknetz und alle geräte die an meiner fritzbox hängen haben zugriff in das zusatznetzwerk.

#!/bin/bash
### BEGIN INIT INFO
# Provides:          CAM
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Should-Start:      $network $time
# Should-Stop:       $network $time
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: kammera
# Description:       kammeraprogramm starten
### END INIT INFO

############KONFIG#########################
nsname=mobilfunk
NIC=eth1		#Netzwerkkarte für Namespace
NICL=eth0		#Netzwerkkarte Hostsystem
brname=br0		#name der Brücke

VethL=veth0		#Virtuelle Netzwerkkarte Hostsystem
IPethL=192.168.230.1	#IP Adresse des Namespace
VethN=veth1		#Virtuelle Netzwerkkarte Namespace
IPethN=192.168.230.2	#IP Adresse des Namespace

#routing host netz zu virtuelles netz
masqn=192.168.43.0/24

DNS=192.168.230.1	#DNS Server für Internetzugang 2
#############KONFIG ENDE###################

case "$1" in  
	start)
	echo "start"  
    
#alte netns löschen
if [ -f /var/run/netns/${nsname} ];
then
echo "INFO:::: "${nsname}" wird gelöscht."  
ip netns del ${nsname}
else
echo "INFO:::: "${nsname}" nicht vorhanden."  
fi
#eth1 aktiv schalten
ip link set ${NIC} up && echo "INFO:::: "${NIC}" up"  
##Namespace erstellen und Netzwerkkarte zuordnen
ip netns add ${nsname} && echo "INFO:::: "${nsname}" erstellt"  
ip link set dev ${NIC} netns ${nsname} && echo "INFO:::: "${NIC} " wurde " ${nsname} "zugeordnet."    


ip netns exec ${nsname} ifconfig lo 127.0.0.1/8 up && echo "INFO:::: lokale schleife wurde erstellt."  
ip netns exec ${nsname} dhcpcd ${NIC} && echo "INFO:::: dhcp anfrage für "${NIC}" gestellt"  



##Netzwerverbindung zwischen Namespace und Host erstellen 
ip link add ${VethL} type veth peer name ${VethN} && echo "INFO:::: virtuelle netzwerkkarten: "${VethL}" und "${VethN}" erstellt."  
ip link set ${VethN} netns ${nsname} && echo "INFO:::: "${VethN}" " ${nsname}" zugeordnet."  


# link aktivieren
ip netns exec ${nsname} ip link set ${VethN} up && echo "INFO:::: "${VethN}" akiv geschaltet."  
ip link set ${VethL} up && echo "INFO:::: "${VethL}" akiv geschaltet."  
# IP Adressen der Host zu Namespace-Verbindung vergeben
ip address add ${IPethL}/30 dev ${VethL} && echo "INFO:::: veth0 ip adresse zugewiesen"  
ip netns exec ${nsname} ip address add ${IPethN}/30 dev ${VethN} && echo "INFO:::: veth1 ip adresse zugewiesen"  


##DNS Server hinzufügen

if [ -d /etc/netns/ ];
then
echo "INFO:::: ""netns-Ordner vorhanden."  
else
echo "INFO:::: ""netns-Ordner fehlt!"  
mkdir /etc/netns
fi


if [ -d /etc/netns/${nsname}/ ];
then
echo "INFO:::: "${nsname}"-Ordner vorhanden"  
echo "nameserver "${DNS} > /etc/netns/${nsname}/resolv.conf && echo "nameserver "${DNS} " in Datei /etc/netns/"${nsname}"/resolv.conf geschrieben"  
else
echo "INFO:::: "${nsname}"-Ordner fehlt"  
mkdir /etc/netns/${nsname}
echo "nameserver "${DNS} > /etc/netns/${nsname}/resolv.conf  
fi


if [ -f /etc/netns/${nsname}/resolv.conf ];
then
echo "INFO:::: /etc/netns/"${nsname}"/resolv.conf vorhanden"  
else
echo  "INFO:::: /etc/netns/"${nsname}"/resolv.conf fehlt"  
fi

#################   ROUTE ZUM Netz an ETH1 hinzufügen  ###########################################
# Enable IP-forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward
# Flush forward rules.
iptables -P FORWARD DROP
iptables -F FORWARD
# Flush nat rules.
iptables -t nat -F
# aktiviere masquerading im Namespace
ip netns exec ${nsname} iptables -t nat -A POSTROUTING -o ${NIC} -j MASQUERADE
#geroutete packete von - nach akzeptieren
iptables -A FORWARD -i ${NIC} -o ${VethN} -j ACCEPT
iptables -A FORWARD -o ${NIC} -i ${VethN} -j ACCEPT
# aktiviere masquerading im Hostsystem
#iptables -t nat -A POSTROUTING -o ${NICL} -j MASQUERADE
iptables -t nat -A POSTROUTING -o ${VethL} -j MASQUERADE
iptables -A FORWARD -i ${NICL} -o ${VethL} -j ACCEPT
iptables -A FORWARD -o ${NICL} -i ${VethL} -j ACCEPT
##Erklärung iptables -t nat -A POSTROUTING -o ${NIC} -j MASQUERADE
# -t nat 			= filter gilt für tabelle "nat" 
# -A POSTROUTING 	= alle Packete nachdem sie geroutet wurden
# -o ${NIC}			= packete werden geprüft wenn sie die schnittst. verlassen
# -j MASQUERADE		= packete ummaskieren. 
#
#Route vom Host zum Namespace über Veth1 hinzufügen 
ip route add ${masqn} via ${IPethN} dev ${VethL}

############################ Programme Starten #######################################


esac