Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
IPv6 Konfiguration
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Sat May 21, 2022 3:09 pm    Post subject: Reply with quote

ARM Paltinchen;
Code:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:f0:5b:75 brd ff:ff:ff:ff:ff:ff
    inet 213.172.113.133/29 brd 213.172.113.135 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:1640:198:0:dea6:32ff:fef0:5b75/64 scope global dynamic mngtmpaddr
       valid_lft 2591555sec preferred_lft 604355sec
    inet6 2001:1640:198::5/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::dea6:32ff:fef0:5b75/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether dc:a6:32:f0:5b:76 brd ff:ff:ff:ff:ff:ff
    inet 10.254.240.10/24 brd 10.254.240.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 2001:1640:198:1::7/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::dea6:32ff:fef0:5b76/64 scope link
       valid_lft forever preferred_lft forever


Code:

ip r
default via 213.172.113.129 dev eth0 metric 2
10.254.240.0/24 dev wlan0 proto kernel scope link src 10.254.240.10
213.172.113.128/29 dev eth0 proto kernel scope link src 213.172.113.133

ip -6 r
2001:1640:198::/64 dev eth0 proto kernel metric 256 pref medium
2001:1640:198:1::/64 dev wlan0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
default via 2001:1640:198::1 dev eth0 metric 2 pref medium


Code:

ip n
213.172.113.130 dev eth0 lladdr b8:27:eb:6d:1a:71 REACHABLE
10.254.240.85 dev wlan0 lladdr 00:09:fd:a5:96:73 REACHABLE
213.172.113.129 dev eth0 lladdr dc:2c:6e:c1:87:f9 REACHABLE
213.172.113.134 dev eth0 lladdr b8:27:eb:a2:a8:cf REACHABLE
2001:1640:198:0:ba27:ebff:fea2:a8cf dev eth0 lladdr b8:27:eb:a2:a8:cf REACHABLE
fe80::8bf3:6b4d:f51e:7308 dev wlan0 lladdr 00:09:fd:a5:96:73 STALE
fe80::dea6:32ff:fef0:5b76 dev wlan0 lladdr dc:a6:32:f0:5b:76 router STALE
2001:1640:198:1:a86d:b0ad:def:4a36 dev wlan0 lladdr 00:09:fd:a5:96:73 STALE
2001:1640:198::1 dev eth0 lladdr dc:2c:6e:c1:87:f9 router REACHABLE
fe80::de2c:6eff:fec1:87f9 dev eth0 lladdr dc:2c:6e:c1:87:f9 router REACHABLE


WAN-Client;
Code:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp7s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether d4:be:d9:05:5b:e1 brd ff:ff:ff:ff:ff:ff
3: wlp13s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:09:fd:a5:96:73 brd ff:ff:ff:ff:ff:ff permaddr 64:27:37:2a:a0:43
    inet 10.254.240.85/24 brd 10.254.240.255 scope global dynamic noprefixroute wlp13s0
       valid_lft 70sec preferred_lft 57sec
    inet6 2001:1640:198:1:a86d:b0ad:def:4a36/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86219sec preferred_lft 14219sec
    inet6 fe80::8bf3:6b4d:f51e:7308/64 scope link
       valid_lft forever preferred_lft forever


Code:

ip r
default via 10.254.240.10 dev wlp13s0 proto dhcp src 10.254.240.85 metric 3003
10.254.240.0/24 dev wlp13s0 proto dhcp scope link src 10.254.240.85 metric 3003

ip -6 r
2001:1640:198:1::/64 dev wlp13s0 proto ra metric 3003 mtu 1280 pref medium
fe80::/64 dev wlp13s0 proto kernel metric 256 pref medium
multicast ff00::/8 dev wlp13s0 proto kernel metric 256 pref medium
default via fe80::dea6:32ff:fef0:5b76 dev wlp13s0 proto ra metric 3003 mtu 1280 pref medium


Code:

ip n
213.172.113.130 dev eth0 lladdr b8:27:eb:6d:1a:71 REACHABLE
10.254.240.85 dev wlan0 lladdr 00:09:fd:a5:96:73 REACHABLE
213.172.113.129 dev eth0 lladdr dc:2c:6e:c1:87:f9 REACHABLE
213.172.113.134 dev eth0 lladdr b8:27:eb:a2:a8:cf REACHABLE
2001:1640:198:0:ba27:ebff:fea2:a8cf dev eth0 lladdr b8:27:eb:a2:a8:cf REACHABLE
fe80::8bf3:6b4d:f51e:7308 dev wlan0 lladdr 00:09:fd:a5:96:73 STALE
fe80::dea6:32ff:fef0:5b76 dev wlan0 lladdr dc:a6:32:f0:5b:76 router STALE
2001:1640:198:1:a86d:b0ad:def:4a36 dev wlan0 lladdr 00:09:fd:a5:96:73 STALE
2001:1640:198::1 dev eth0 lladdr dc:2c:6e:c1:87:f9 router REACHABLE
fe80::de2c:6eff:fec1:87f9 dev eth0 lladdr dc:2c:6e:c1:87:f9 router REACHABLE
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Sat May 21, 2022 3:16 pm    Post subject: Reply with quote

Your WLAN-Client misses the address: 2001:1640:198:1::X/64 and therefore the default route does not point to 2001:1640:198:1::7/64
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Sat May 21, 2022 3:32 pm    Post subject: Reply with quote

Altägyptisch ... OK ... nicht meckern wenn ich falsch übersetze ...

Und warum ist das so?
Die legt ja der radvd fest: WLAN-Client: 2001:1640:198:1:a86d:b0ad:def:4a36/64 passt doch oder?
Das sind die 64Bit Netmask: 2001:1640:198:1 den Rest baut der radvd aus MAC und Co zusammen.

Default Route:
Macht auch der radvd. Der nimmt die Link Lokal Adresse des wlan0 vom ARM.

fe80::dea6:32ff:fef0:5b76/64 wlan0
2001:1640:198:1::7/64 wlan0
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Sat May 21, 2022 4:12 pm    Post subject: Reply with quote

Ach Du gute Güte ... sorry ... ich war da gedanklich in einem engl. Thread.

Vorab: Ich kenne den radvd nicht und kann da leider nicht helfen. Was aber den Wlan-Client betrifft, so muss seine Default-Route auf den ARM zeigen. Das tut sie aber nicht. kannst Du mal testweise einem WLAN-Client eine fixe Adresse zuweisen und als Def-Route auf 2001:1640:198:1::7/64 zeigen (der scope muss global sein und nicht link).
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Sat May 21, 2022 5:10 pm    Post subject: Reply with quote

Ist ja kein Problem kann halt sein das ich dann Unsinn Antworte und es nicht weiß weil ich falsch übersetzt habe. Ich Versuche halt damit zurecht zu kommen.

Ich habe das in die /etc/conf.d/net so eingetragen:
Code:

config_wlp13s0="2001:1640:198:1::8/64"
routes_wlp13s0="default via 2001:1640:198:1::7"


Das sieht so jetzt aus:
WLAN-Client:
Code:

ip -6 route
2001:1640:198:1::/64 dev wlp13s0 proto kernel metric 256 pref medium
fe80::/64 dev wlp13s0 proto kernel metric 256 pref medium
multicast ff00::/8 dev wlp13s0 proto kernel metric 256 pref medium
default via 2001:1640:198:1::7 dev wlp13s0 metric 2003 pref medium

geht aber leider trotzdem nicht.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Sat May 21, 2022 5:33 pm    Post subject: Reply with quote

Ok. WENN Du vom WLAN-Client Deinen ARM erreichst (ping), DANN ist das forwarding im ARM ein Problem. (Probier auch ob Du den Client vom ARM aus erreichst).

Was mach aber wundert: Du sagtest dass Du vom Client über IPv4 (über den ARM) ins Internet kommst (da muss also das forwarding laufen) ... hast Du es auch für v6 eingeschaltet ?
(net.ipv6.conf.all.forwarding=1)
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Sat May 21, 2022 6:28 pm    Post subject: Reply with quote

Ein Ping geht von beiden Seiten über WLAN.

Ja ich kann mit IPv4 auf das Internet zugreifen. Die Verbindungen sind aber manchmal sehr langsam. Ich vermute die Versuchen erst IPv6 wenn das nicht geht dann erst IPv4. Ein Ping an eine Adresse die beides kann geht nur mit ping4.

Das sagt er:
Code:

sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 1


Mir ist da gerade was eingefallen. Wenn ich einen ping auf einen Internen Rechner mache der nur eine IPv6 Adresse hat und dort schaue ob die Pakete ankommen. Sieht das so aus:
Code:

tcpdump -i eth0 icmp6
dropped privs to pcap
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:23:25.659630 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 88, length 64
20:23:25.659738 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 88, length 64
20:23:25.660071 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 88, length 64
20:23:25.766344 IP6 fe80::de2c:6eff:fec1:87f9 > ff02::1:ff99:50: ICMP6, neighbor solicitation, who has ki50.thewebsideoflife.de, length 32
20:23:25.766436 IP6 ki50.thewebsideoflife.de > fe80::de2c:6eff:fec1:87f9: ICMP6, neighbor advertisement, tgt is ki50.thewebsideoflife.de, length 32
20:23:26.699665 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 89, length 64
20:23:26.699789 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 89, length 64
20:23:26.700105 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 89, length 64
20:23:27.739628 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 90, length 64
20:23:27.739762 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 90, length 64
20:23:27.740091 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 90, length 64
20:23:28.530628 IP6 fe80::dea6:32ff:fef0:5b75 > fe80::ba27:ebff:fe80:b692: ICMP6, neighbor solicitation, who has fe80::ba27:ebff:fe80:b692, length 32
20:23:28.530733 IP6 fe80::ba27:ebff:fe80:b692 > fe80::dea6:32ff:fef0:5b75: ICMP6, neighbor advertisement, tgt is fe80::ba27:ebff:fe80:b692, length 24
20:23:28.779632 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 91, length 64
20:23:28.779742 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 91, length 64
20:23:28.780056 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 91, length 64
20:23:29.819621 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 92, length 64
20:23:29.819731 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 92, length 64
20:23:29.820047 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 92, length 64
20:23:30.859621 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 93, length 64
20:23:30.859755 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 93, length 64
20:23:30.860077 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 93, length 64
20:23:31.899634 IP6 2001:1640:198:1::8 > arc.thewebsideoflife.de: ICMP6, echo request, id 52281, seq 94, length 64
20:23:31.899764 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 94, length 64
20:23:31.900101 IP6 arc.thewebsideoflife.de > 2001:1640:198:1::8: ICMP6, echo reply, id 52281, seq 94, length 64
^C
25 packets captured
25 packets received by filter
0 packets dropped by kernel

Der bekommt die Pakete und sendet welche zurück. Die dann aber auf dem Rückweg nicht mehr ankommen.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Sat May 21, 2022 9:13 pm    Post subject: Reply with quote

Mir ist auch noch etwas eingefallen: Bist Du Dir wirklich sicher, dass Dein Edge Router auch mit beiden Adressen:

2001:1640:198:0.../64 und 2001:1640:198:1..../64

zurecht kommt ?


Ich hätte ja das vorhandene Netz gesplittet - wir haben ja genügend Adressen: die hinteren 64 bit. Ich hätte also nur: 2001:1640:198:0.../64 verwendet.

Ich hätte z.B.: die ersten 16 bit (der zweiten 64 bit) noch mal für das Netz hergenommen und die verbleibenden 48 bit reichen mehr als Dicke als Host Adresse. Dann hätte ich so konfiguriert (beispiel):


ARM:

config_eth0=" [...]
2001:1640:198::5/80"
routes_eth0=" [...]
default via 2001:1640:198::1"
config_wlan0=" [..]
2001:1640:198:0:1::1/80"

(hier nicht sofort ersichtlich: Adresse für eth0 ist eigentlich: 2001:1640:198:0 : 0:0:0:5)

Damit wäre die Default Route für die WLAN-Clints also: 2001:1640:198:0:1::1 =>


WLAN-Client:

config_wlp13s0="2001:1640:198:0:1::8/80"
routes_wlp13s0="default via 2001:1640:198:0:1::1"

(hier besser ersichtlich: Adresse für wlp13s0 ist eigentlich: 2001:1640:198:0 : 1:0:0:8 )

P.S.: Wenn der Netzwerk Stack im Linux Kernel IPv4 UND IPv6 unterstützt, wird default immer zuerst IPv6 verwendet.
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Sat May 21, 2022 10:17 pm    Post subject: Reply with quote

Ja das gehört noch zu meinem Adressbereich. Stimmt aber schon in einem Subnet wird man kaum alle Adressen belegen.

Bei dem Ping an den internen Rechner ist aber der Ruoter gar nicht beteiligt.

<Edit>
Wie geht da eigentlich der Weg zurück für das Datenpaket?

Da es nicht aus dem gleichen Subnet ist wird es an die default Route gesendet: 2001:1640:198::1 das ist das Edge Dings.
Es ist halt so ich habe keine Ahnung was der Edge Router macht weil ich da keinen Zugriff habe. Vor über 20 Jahren war das kein Problem da habe ich von den Anbietern die Login Daten Problemlos bekommen heute Zicken die alle nur noch herum und nennen das Service. Was ich sicher weiß es gehört zu meinem Adressbereich laut Auftragsbestätigung.

Ich bräuchte also einen eigenen Router hinter dem Edge-Router da ich nicht möchte das der Edge Router meinen ganzen Internen Datenverkehr mitlesen kann. Da muss ich wohl noch etwas umbauen. So was blödes weil der eigentlich total Überflüssig ist.

Wenn ich Deinen Vorschlag umsetze muss ich aber alle Rechner neu konfigurieren weil sich ja für alle dann die Netzmaske ändert.
</Edit>
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 10:48 am    Post subject: Reply with quote

alexander_ro wrote:
Bei dem Ping an den internen Rechner ist aber der Ruoter gar nicht beteiligt.

Sag das nicht ... Ja, der Ping selbst zwischen ARM und WLAN-Client geht nicht über den Edge ... aaaaber ... vorher ... machten die ja automatische Adresszuweisung über ICMP ... (BTW: Ich selbst bin bei IPv6 auch noch ein ziemlicher Laie).

alexander_ro wrote:
Wie geht da eigentlich der Weg zurück für das Datenpaket?

Sorry, die Frage verstehe ich nicht :-( (Was meinst Du jetzt da?)

alexander_ro wrote:
Es ist halt so ich habe keine Ahnung was der Edge Router macht weil ich da keinen Zugriff habe. Vor über 20 Jahren war das kein Problem da habe ich von den Anbietern die Login Daten Problemlos bekommen heute Zicken die alle nur noch herum und nennen das Service. Was ich sicher weiß es gehört zu meinem Adressbereich laut Auftragsbestätigung.

Ja, ja, die gute neue Zeit, wo einige Provider in unserem Ländle versuchen Dir auch noch ein bestimmtes Router Modell aufzuzwingen ... :evil: (bedeutet: Ich bin hier voll Deiner Meinung).

alexander_ro wrote:
Ich bräuchte also einen eigenen Router hinter dem Edge-Router da ich nicht möchte das der Edge Router meinen ganzen Internen Datenverkehr mitlesen kann. [...]

Äääh, nein, Dein Edge kann nur alles lesen, was zwischen Intern und Internet läuft. So wie ich es verstanden habe, willst Du den ARM als Router zwischen Deinem kabelgebundenen Netz und WLAN nutzen. Was da dazwischen läuft geht doch nicht über den Edge.

alexander_ro wrote:
Wenn ich Deinen Vorschlag umsetze muss ich aber alle Rechner neu konfigurieren weil sich ja für alle dann die Netzmaske ändert.

Wenn es dann immer noch Probleme gibt, bräuchten wir nochmal alle 3 IP-Abfragen vom ARM UND vom WLAN-Client. Es kann ja immer noch sein, dass wir ein Prob mit dem Forwarding im ARM haben.
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Mon May 23, 2022 11:19 am    Post subject: Reply with quote

Ein Ping hat ja ein Datenpaket hin und eins wieder zurück. Das Datenpaket muss ja irgendwie wieder zur Quelle zurückfinden.

Ping: ARM -> Interner Rechner: hier kommt das Datenpaket laut tcpdump beim Internen Rechner an. Die Antwort kommt aber nicht beim ARM an. Wo bleibt die also?
Wenn ich von dem internen Rechner einen ping an die Adresse 2001:1640:198:1::7 mache wird das weil ein anderes Subnet zum Edge Router gesendet über die default Route des internen Rechners.[/topic]

Code:

traceroute 2001:1640:198:1::7
traceroute to 2001:1640:198:1::7 (2001:1640:198:1::7), 30 hops max, 80 byte packets
 1  router.x.de (2001:1640:198::1)  1.086 ms  0.842 ms  0.637 ms
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 11:51 am    Post subject: Reply with quote

alexander_ro wrote:
Ein Ping hat ja ein Datenpaket hin und eins wieder zurück. Das Datenpaket muss ja irgendwie wieder zur Quelle zurückfinden.

Ja, aber nicht irgendwie, sondern ganz einfach ;-) ->

Vorab: Du hast in jedem IP-Header (v4 und v6) die Absender-IP-Adresse und die Empfänger-IP-Adresse. Der Empfänger weiß somit von welcher Station ein Paket kam und tauscht dann einfach für die Antwort beides aus ... was aber noch nichts darüber aussagt, ob es auch so zurückgeschickt werden KANN ... DENN ... der eigentliche Transport erfolgt über Layer 2 (= die MAC-Schicht). Wenn also z.B. eine Rücksende-Empfänger-Adresse aus einem anderen Netz kam, dann muss diese angepingt Maschine erstmal einen Router (Gateway) FINDEN, der für dieses fremde Netz zuständig ist (meistens das Default Gateway) um es dann an die MAC-Adresse dieses Routers zu schicken. Du wirst also NICHT die IP Adresse des Routers in diesen Paketen finden. Hier ein Beispiel von zwei Hosts über einen Router:

Ping Request von Station 1:
Code:
Layer 2: TO MAC-router-IF-1 FROM MAC-Station1 [...] Layer 3: SRC IP 2001:1640:198:0::5 TARGET IP 2001:1640:198:1::7


Weiterleitung Ping Request am Router:
Code:
Layer 2: TO MAC-Station2 FROM MAC-router-IF-2 [...] Layer 3: SRC IP 2001:1640:198:0::5 TARGET IP 2001:1640:198:1::7


Weg zurück - Station 2 sendet Ping Reply:
Code:
Layer 2: TO router-IF-2 FROM MAC-Station2 [...] Layer 3: SRC IP 2001:1640:198:1::7 TARGET IP 2001:1640:198:0::5


Weiterleitung Ping Reply am Router:
Code:
Layer 2: TO MAC-Station1 FROM MAC-router-IF-1 [...] Layer 3: SRC IP 2001:1640:198:1::7 TARGET IP 2001:1640:198:0::5
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Mon May 23, 2022 12:41 pm    Post subject: Reply with quote

Der traceroute gibt aber doch den nächsten Punkt an an den wirklich das Datenpaket gesendet wird?

Alles was im gleichen Subnet ist kann der auch ohne Default Route zustellen. Für ein anderes Subnet gibt der das Datenpaket einfach an das in der default Route genannte Gerät weiter. Das ist in diesem Fall der Edge Router. Ich glaube schon das der das Antwort Paket des ping an den Edge Router sendet. Da ich keine Zugriff habe auf den Router kann ich es nicht prüfen.

Das feststellen der MAC Adresse läuft ja nun nicht mehr über ARP sondern über Erweiterungen im neuen ICMP6.

Sicher ist jedenfalls das die Antwort verloren geht nicht die Anfrage dann muss das Forwarding auf den ARM auch funktionieren.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 1:09 pm    Post subject: Reply with quote

alexander_ro wrote:
Der traceroute gibt aber doch den nächsten Punkt an an den wirklich das Datenpaket gesendet wird?

Meinst Du traceroute oder tcpdump ? Der traceroute funktioniert ein bischen tricky: https://de.wikipedia.org/wiki/Traceroute

alexander_ro wrote:
Alles was im gleichen Subnet ist kann der auch ohne Default Route zustellen.

Ja.

alexander_ro wrote:
Für ein anderes Subnet gibt der das Datenpaket einfach an das in der default Route genannte Gerät weiter.

Exakter: Für ein anderes NETZ (egal ob Subnetz) sucht Deine Maschine einen PASSENDEN Router. Das KANN das Default GW sein, muss es aber nicht, WENN Deine Maschine mindestes zwei Interfaces hat, DENN dann hast Du mindestens zwei Routen: EINE spezielle Route UND die default Route (für alles andere, was nicht in die spezielle Route passt).

alexander_ro wrote:
Das ist in diesem Fall der Edge Router. [...]

Sicher ist jedenfalls das die Antwort verloren geht nicht die Anfrage dann muss das Forwarding auf den ARM auch funktionieren.


Nein, Nein. Du hattest doch etwas anderes vor: Du wolltest doch daß Dein ARM zwischen zwei Netzen routet (kabelgeb. LAN und WLAN). Das soll doch NICHT über Deinen Edge laufen. Oder hab ich das komplett mißverstanden ?

Versuch doch einfach eine Umstellung der Adressen, denn dann hast Du auch für die Zukunft VIELE lokale Netze bereits in petto.

(Ich hab das Gefühl Du willst die Umstellung wegen des Aufwandes nicht machen, das ist natürlich Deine Entscheidung, aber ohne Zugriff auf den Edge - vor allem WIE dieser Konfiguriert ist - kann Deine Adresslösung problematisch sein).
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Mon May 23, 2022 2:30 pm    Post subject: Reply with quote

Ich habe mit dem tcpdump auf dem internen Rechner gesehen das die ping Pakete ankommen.

Ich habe mit dem traceroute 2001:1640:198:1::7 auf dem internen Rechner gesehen das er als ersten und einzigen Hop den Edge Router anzeigt.

pietinger wrote:

Nein, Nein. Du hattest doch etwas anderes vor: Du wolltest doch daß Dein ARM zwischen zwei Netzen routet (kabelgeb. LAN und WLAN). Das soll doch NICHT über Deinen Edge laufen. Oder hab ich das komplett mißverstanden ?

Verstehst Du schon richtig. Sieht so aus:
Code:

Edge Router = 1.Subnet = ARM (eth0) = ARM (wlan0) = 2.Subnetz = WLAN-Client

Der interne Rechner von dem ich spreche ist im 1.Subnet.

<Edit>
Die in der ersten Zeile genannten ping Pakete wurden von dem WLAN-Client gesendet.
</Edit>
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 2:40 pm    Post subject: Reply with quote

alexander_ro wrote:
Ich habe mit dem traceroute 2001:1640:198:1::7 auf dem internen Rechner gesehen das er als ersten und einzigen Hop den Edge Router anzeigt.

Das bedeutet, Du hast an diesem internen LAN-Clienten NUR eine default route, aber keine spezielle Route gesetzt. Möglicherweise habe ich mich falsch ausgedrückt, als ich sagte, dass Du (nur) an Maschinen mit zwei Interfaces zwei Routen benötigst. Die brauchst Du für JEDEN Clienten, WENN die in einem NETZ mit ZWEI Ausgängen = 2 Router sitzen, DENN die müssen ja auch entscheiden, welchen der beiden Router sie verwenden sollen.
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Mon May 23, 2022 3:32 pm    Post subject: Reply with quote

Ja das glaube ich auch das da noch was fehlt. Deshalb meinte ich ja viel weiter oben wie das zurück kommt.

Das sieht auf dem internen Rechner so aus.
Code:

ip -6 route
2001:1640:198::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via 2001:1640:198::1 dev eth0 metric 2 pref medium


Das muss dann irgendwie das 2001:1640:198:1::/64 auf den ARM 2001:1640:198::5 routen. Der muss ja dann schon wissen das er das 2.Subnet über das wlan0 erreicht. Muss mal suchen wie man das macht. Vermutlich kann man das doch dem netifrc an die Backe kleben ... also in der /etc/conf.d/net konfigurieren.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 4:33 pm    Post subject: Reply with quote

alexander_ro wrote:
Ja das glaube ich auch das da noch was fehlt. Deshalb meinte ich ja viel weiter oben wie das zurück kommt.

Verstehe ich jetzt. Ich war die ganze Zeit gedanklich (noch) bei Deiner Verbindung: ARM <-> WLAN

alexander_ro wrote:
Vermutlich kann man das doch dem netifrc an die Backe kleben ... also in der /etc/conf.d/net konfigurieren.

Ja, klar (ich mag den netifrc :-) ) !


(Wenn Du Deine LAN-Clienten eh noch anlangen musst (weil die statisches netifrc statt dhcp haben) kannst Du ja nochmal über die Umstellung der Adressbereiche nachdenken ... ;-) )
Back to top
View user's profile Send private message
firefly
Watchman
Watchman


Joined: 31 Oct 2002
Posts: 5173

PostPosted: Mon May 23, 2022 5:38 pm    Post subject: Reply with quote

alexander_ro wrote:
Ja das glaube ich auch das da noch was fehlt. Deshalb meinte ich ja viel weiter oben wie das zurück kommt.

Das sieht auf dem internen Rechner so aus.
Code:

ip -6 route
2001:1640:198::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via 2001:1640:198::1 dev eth0 metric 2 pref medium


Das muss dann irgendwie das 2001:1640:198:1::/64 auf den ARM 2001:1640:198::5 routen.

Genau denn 2001:1640:198:1::/64 (2001:1640:0198:0001:0000:0000:0000:0000/64) und 2001:1640:198::/64 (2001:1640:0198:0000:0000:0000:0000:0000/64) sind zwei verschiedene Subnetze.
Und wenn ein client (aus dem 2001:1640:198::/64 subnetz) ein ziel aus dem 2001:1640:198:1::/64 subnetz direkt erreichen möchte so muss ein passender eintrag in der routing tabelle vorhanden sein.

Aktuell gibt es denen auf deinem internen Rechner nicht. Wodurch dieser Versucht über das default gateway das ziel zu erreichen. Und da das system, auf dem das default gateway zeigt, auch keinen weg zum zweiten Subnetz kennt, landet das paket quasi im nirwana.

Der eintrag in der routing tabelle muss dann in etwa so aussehen:

Code:
2001:1640:198:1::/64 via 2001:1640:198::5 dev eth0


Dadurch ist dem system klar, dass wen ein paket an eine IP-Addresse des subnetz 2001:1640:198:1::/64 verschickt werden soll, dass das subnetz via dem system, welches die IP 2001:1640:198::5 hat, erreichbar ist.

Dieser Eintrag muss dann entweder auf dem system hinterlegt sein, welches als default gateway für alle Rechner des internen netzwerk dient oder auf jedem Rechner des internen netzwerks konfiguriert werden.
Am besten ist es, wenn es auf dem system, welches als default gateway genutzt wird, gemacht wird, weil man dadurch das ganze nur an eine stelle konfigurieren muss und nicht an zig stellen.
Oder der routing eintrag wird via DHCP(v6) verteilt.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 8:16 pm    Post subject: Reply with quote

Vermutlich ist das "nur" ein privates Heim-Netz (ohne abwertende Meinung). Bei etwas größeren Installationen würde man es nicht so machen, in einem Client-Segment zwei Router einzusetzen ( https://de.wikipedia.org/wiki/Segment_(Netzwerk) ). Stattdessen hat jedes (Layer-3)-Segment nur einen einzigen (default) Router (jetzt mal von hochredundanten Installationen bei richtig reichen Unternehmen abgesehen). Diese sind dann erst im Backbone untereinander verbunden, so daß alle Routen zentral nur auf den Routern gepflegt werden müssen. Alle Clienten haben nur ein DefaultGW. In diesem Fall würde es so aussehen:

Code:
WLAN ..........(funk)......... Router2 <-|
                                         V
Ethernet-Switch für LAN <-> Router1 <-> Ethernet-(Mini)-Switch ("Backbone") <-> EDGE-Router <----> Internet


Natürlich muß man dabei Zugriff auf den Edge haben, damit man ihm die DREI Routen geben kann (genauso wie beide Router jeweils 3 Routen haben werden: 1. Default zum Edge 2. Link ins eigene Netz und 3. Link zum anderen Router).

Oder Du hast gleich einen professionellen Router mit mehreren (vielen) Ethernet-Ports ... ;-) Wenn der ARM zwei Ethernet-Ports hätte, könnte man das sauber lösen (er braucht dann halt aber einen zweiten Switch - ja, eine Trennung wäre auch über VLAN möglich ... aber ich bin ein Security Paranoiker ...)


P.S.: Es würde dann so aussehen wie hier (statt DMZ halt WLAN; statt eth2 halt wlp13s0): https://forums.gentoo.org/viewtopic-t-1114432.html


P.P.S.: Argh ... wieder einmal Unsinn geredet ... WENN er eine DIREKTE Verbindung zwischen EDGE und einem Ethernet-Port des ARM macht, braucht er ja keinen zweiten Switch, nur der zweite Port des ARM hängt am (LAN-)Switch.
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Mon May 23, 2022 10:06 pm    Post subject: Reply with quote

Ich dachte am Anfang auch immer das würde an der ARM <=> WLAN Verbindung liegen. Ich hatte nicht gleich die Idee mit dem tcpdump auf dem internen Rechner zu schauen ob da Pakete ankommen. Wenn etwas wie der ARM neu ist neige ich dazu dann auch dort das Problem zu vermuten.

Ja das netifrc ging bisher immer gut und flexibel für sonder Wünsche ... oder sonderbare Wünsche ;)

Ich finde Router also die spezialisierte Hardware meist recht überflüssig. Die sind gut für Räumlich weit verteilte Netze die nur Netz sind. Wie z.B. bei der Telekom mit den Kunden Zugängen.

Wenn ich aber dicht gepackt Rechenleistung habe brauche ich keine speziellen Router. Computer mit mehreren Netzwerkschnittstelen und Switches können das gut lösen und liefern gleich noch etwas zusätzliche Rechenleistung. Die Router kosten an der stelle nur mehr Geld, Energie und Nerven weil ich mich jedes mal ärgere wenn es für das Teil keine Software Updates mehr gibt und ich den nur aus diesem Grund verschrotten muss. Nein es ist nicht nur ein privates Netzwerk aber es ist anders als andere Netze.

Ich bin mir nicht ganz sicher was da besser ist wenn der ARM zwei Ethernet Schnittstellen hätte. Das WLAN hat ja das zweite Subnetz. Die wie auch immer zu trennen bringt auch nicht viel weil die Computer über das WLAN auf die in dem anderen Netz zugreifen. Ein VLAN oder was auch immer bringt doch nur etwas wenn ich eine Nutzergruppe von einer anderen trennen will damit keiner Daten klauen kann. Das ist bei mir aber nicht so.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Mon May 23, 2022 11:14 pm    Post subject: Reply with quote

alexander_ro wrote:
Ich finde Router also die spezialisierte Hardware meist recht überflüssig.

Ja, bei kleineren Installationen; große Unternehmen benötigen Einheitlichkeit (die Cisco ihnen bietet; deswegen wollen sie ja auch ein Linux mit systemd). Andere Vorteile eines spezialisierten Routers sind der Strom-Verbrauch und - bei guten Routern - auch noch die Performance beim Durchsatz; ansonsten sind selbst gebaute Kisten natürlich viel wartungsfreundlicher (weshalb viele auch einen kleinen PI dafür nutzen) und würde ich bei kleineren Installationen genauso gerne einsetzen.

alexander_ro wrote:
Ich bin mir nicht ganz sicher was da besser ist wenn der ARM zwei Ethernet Schnittstellen hätte.

Du sparst Dir bei allen LAN-Clienten das Setzen einer zweiten Route. Die brauchen dann nur eine Default Route.

alexander_ro wrote:
Das WLAN hat ja das zweite Subnetz. Die wie auch immer zu trennen bringt auch nicht viel weil die Computer über das WLAN auf die in dem anderen Netz zugreifen.

Getrennt sind sie ja bereits jetzt schon. Der Unterschied ist: Du hättest dann drei Netze: Das WLAN-, das LAN-Netz und das Netz zwischen ARM und Edge. Was meiner Meinung nach auch die sauberste Lösung ist :-) Ach ja: Was der Edge denkt, kann Dir dann auch egal sein, denn der hat dann nur einen einzigen Partner und sieht nur ein einziges Netz ... ;-)

(Dein Edge kann dann gerne eine hartkodierte Subnetz-Maske /64 haben, weil es ihn dann nicht interessiert wenn Du diese intern in 64K Subnetze mit /80 aufgesplittet hast)
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Tue May 24, 2022 8:30 am    Post subject: Reply with quote

Das kommt nun darauf an was bei Dir klein ist.

Wer die gleiche Linux Distribution benutzt auf den Systemen hat es auch einheitlich.

Um beim aktuellen Fall zu bleiben ist der Stromverbrauch geringer. Würde das nicht einer der Computer nebenbei mit erledigen bräuchte ich einen extra WLAN Router als zusätzliches Gerät. Also ein Gerät mehr ...
Performance kann sein aber wenn man die Netzwerkschnittstelle richtig einstellt ist der Unterschied nicht so groß. Der Linux Kernel leistet da gute Arbeit weil ja die Host Schnittstelle auch die volle Bandbreite bieten muss.

Das setzen der Routen geht automatisch wenn ich mal festgelegt habe wie ich es machen möchte. Ich habe mir da ein Tool gebaut das die Aufgabe erledigt und das in die /etc/conf.d/net einträgt.

Ja das stimmt meine Daten vom WLAN laufen jetzt zusätzlich durch das 1.Subnet. Da es mein eigens Netz ist und so alle Kommunikation verschlüsselt wird ist das kein Sicherheitsproblem. Die Bandbreite reicht auch leicht weil das Gigabit Netz sehr viel schneller als die Internetleitung ist. In dem 1. Subnet laufen fast nur Daten die zu externen Zielen gehen.

Wie gesagt Hardware Router haben sicher ihre Berechtigung bei mir glaube ich sind die nicht nötig. Ich baue aber auch fast alles aus normalen Computern weil man bei den Spezialisierten Geräten immer das Problem hat das die Updates irgendwann nicht mehr gemacht werden und man das Wegwerfen kann wenn es eine Internetverbindung hat. Das gilt Heute auch für Handys und Autos da ist nur das selber bauen sehr schwierig. Aber wenn es auch keiner glauben will es laufen oder fahren Millionen Menschen herum mit Geräten die andere Kontrollieren. Hat der Hersteller erst mal die Updates eingestellt ist das nicht die frage ob sondern nur wann.

<Edit>
So habe ich das nun gemacht:
Code:

routes_eth0="2001:1640:198:1::/64 via 2001:1640:198::5
             default via 2001:1640:198::1"


Der ping vom Internen Rechner zu der Adresse beim ARM wlan0 funktioniert jetzt. Das andere kann ich erst Testen wenn ich wieder am Standort des WLANs bin.
</Edit>
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 4124
Location: Bavaria

PostPosted: Tue May 24, 2022 12:37 pm    Post subject: Reply with quote

alexander_ro wrote:
Das kommt nun darauf an was bei Dir klein ist.

Ja, da hast Du recht; Klein ist relativ. Sagen wir mal so: Mein früherer AG hat das fünftgrößte WAN-Netz in D betrieben ;-)

alexander_ro wrote:
Aber wenn es auch keiner glauben will es laufen oder fahren Millionen Menschen herum mit Geräten die andere Kontrollieren.

Ha ... wem erzählt Du das :lol: Was Datenschutz und Privacy betrifft, bin ich Paranoiker (Du kennst ja sicherlich meinen Guide) 8)

Würde mich sehr freuen, wenn Du ein kurzes "Läuft" für Deine Lösung durchgeben kannst (nach Test WLAN). Wünsche Dir alles Gute.
Back to top
View user's profile Send private message
alexander_ro
Guru
Guru


Joined: 22 Nov 2014
Posts: 427

PostPosted: Wed May 25, 2022 8:43 am    Post subject: Reply with quote

Ja das funktioniert jetzt auch vom WLAN-Client aus. Nur eine Internet Verbindung gibt es damit nicht weil der Provider wieder Zicken macht ... :(

Mir wurde das Netz 2001:1640:198::/48 zugeteilt der Provider routet auf den Edge-Router aber nur das Subnet 2001:1640:198:0::/64. Die Behauptung ist es geht nicht und ich müsse einen eigenen Router haben und auf dessen IP-Adresse könne er das routen.

Die Firma ist die totale Katastrophe mit denen habe ich schon einen Streit weil die sich weigern die Revers-Zone von meinem Nameserver zu laden. Ich soll die manuell jede Einzeln melden. IT zu Fuß rein Technologisch ist Deutschland wirklich eine Entwichlungsland geworden es gibt kaum noch etwas was so funktioniert wie es eigentlich sein soll. Diese ganzen Digitalisierungsmachenschaften der Regierung sind nur Werbegag. Wenn die Basis also das Netz mit den nötigen Diensten schon nicht funktioniert weil die Provider einem das Leben zur Hölle machen muss man sich nicht Wundern das Firmen da nicht Einsteigen.

Code:

Edege-Router = Mein-Router = 1.Subnet = Rest-von-meinem-Netz

So ein Konstrukt ist halt totaler Unsinn und frist nur ohne Mehrwert Ressourcen. Ich bekomme noch Zustände mit diesen Firmen.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum