[GELÖST]Static/dhcp ip vergabe ist zickig

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

[GELÖST]Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 17.01.2020 15:30:15

Hallo erst mal.

Ich hab bei mir zuhause eine qnap nas die auf Debian umgeflasht habe.
Das ist jetzt meine erste Debian Installation (normaler weise nutzte ich ubuntu...)

Mein problem sind die beiden netzwerkports.
Auf dem system läuft openvpn und pihole (DNS und DHCP).

ich hab zwar in die /etc/network/interfaces ein getragen, das de beiden schnittstellen feste ips haben sollen, trozdem kommt es vor das eine oder mal beide schnitstellen, andere ips haben, die sie gar nicht haben sollten.

Code: Alles auswählen

auto lo eth0 eth1
iface lo inet loopback


iface eth0 inet static
 address 192.168.1.111
 netmask 255.255.255.0
 gateway 192.168.1.1
 broadcast 192.168.1.255

iface eth1 inet static
 address 192.168.1.4
 netmask 255.255.255.0
 gateway 192.168.1.1
 broadcast 192.168.1.255
Die nas ist mit meiner fritzbox direkt mit beiden schnitstellen verbunden. (Gigabit)
Der dhcp server der fritzbox ist aus.

Ich verstehe nicht, warum das so ist.

Ich hoffe ihr könnt mir helfen.

Geuss Conan

Edit: ich hatte im Dezember 19 als Jessie innstalliert und hab es gestern abend auf Buster geupdatet (erst gestern abend, wegen einem RAM bug.)
Zuletzt geändert von Conan89 am 18.01.2020 13:48:15, insgesamt 1-mal geändert.

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Static/dhcp ip vergabe ist zickig

Beitrag von unitra » 17.01.2020 15:56:35

Das liegt daran dass die Schnittstellen "eth0" und "eth1" sich nicht deterministisch verhalten beim Booten. Hier der Link zur Dokumentation und zur Migration: https://wiki.debian.org/NetworkInterfaceNames. Solange die Schnittstellen eth0 und eth1 heissen, wird das beschriebene Verhalten weiter anhalten.
Conan89 hat geschrieben: ↑ zum Beitrag ↑
17.01.2020 15:30:15
Hallo erst mal.

Ich hab bei mir zuhause eine qnap nas die auf Debian umgeflasht habe.
Das ist jetzt meine erste Debian Installation (normaler weise nutzte ich ubuntu...)

Mein problem sind die beiden netzwerkports.
Auf dem system läuft openvpn und pihole (DNS und DHCP).

ich hab zwar in die /etc/network/interfaces ein getragen, das de beiden schnittstellen feste ips haben sollen, trozdem kommt es vor das eine oder mal beide schnitstellen, andere ips haben, die sie gar nicht haben sollten.

Code: Alles auswählen

auto lo eth0 eth1
iface lo inet loopback


iface eth0 inet static
 address 192.168.1.111
 netmask 255.255.255.0
 gateway 192.168.1.1
 broadcast 192.168.1.255

iface eth1 inet static
 address 192.168.1.4
 netmask 255.255.255.0
 gateway 192.168.1.1
 broadcast 192.168.1.255
Die nas ist mit meiner fritzbox direkt mit beiden schnitstellen verbunden. (Gigabit)
Der dhcp server der fritzbox ist aus.

Ich verstehe nicht, warum das so ist.

Ich hoffe ihr könnt mir helfen.

Geuss Conan

Edit: ich hatte im Dezember 19 als Jessie innstalliert und hab es gestern abend auf Buster geupdatet (erst gestern abend, wegen einem RAM bug.)

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Static/dhcp ip vergabe ist zickig

Beitrag von MSfree » 17.01.2020 16:07:40

unitra hat geschrieben: ↑ zum Beitrag ↑
17.01.2020 15:56:35
Das liegt daran dass die Schnittstellen "eth0" und "eth1" sich nicht deterministisch verhalten beim Booten.
1. die verhalten sich sehr wohl deterministisch, dazu gibt es nämlich Regeln für udev, die den NIC-Namen eindeutic einer MAC zuordnen.

2. hat das mit dem Problem nichts zu tun. Denn eine feste IP ist eine feste IP und in diesem Fall sogar noch verbunden mit dem selben Switch, so daß es egal ist ob IP1 aus dem linken und IP2 aus dem rechten Netzwerkloch kommt.

3. vermutlich läuft irgendwo im Hintergrund noch ein DHCP-Client, der versucht, die feste IP mit einem per DHCP bekommenen zu ersetzen. Oder nach dem Prinzip "wer zuerst kommt" die IP zuweist, bevor die feste IP zugewiesen werden kann.

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 17.01.2020 17:31:08

Was ist "deterministisch"?

Wie kann ich herausfinden, ob ein dhcp client mit mit mischt?

Hmm ich hab noch ein anderes ip problem, ich hab das noch nicht geschrieben, weil ich es in angrif nemmen wollte, wen das andere gelöst ist.
Beim Start bekommen beide schnittstellen, keine ipv6 zugeteilt.
Wen ich nach ein paar Minuten "sudo /etc/init.d/networking restart" mache, dann bekommen sie erst eine.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Static/dhcp ip vergabe ist zickig

Beitrag von MSfree » 17.01.2020 19:41:48

Conan89 hat geschrieben: ↑ zum Beitrag ↑
17.01.2020 17:31:08
Wie kann ich herausfinden, ob ein dhcp client mit mit mischt?

Code: Alles auswählen

ps augx
Beim Start bekommen beide schnittstellen, keine ipv6 zugeteilt.
Woher soll die auch kommen, wenn du in /etc/network/interfaces nur IPv4 konfigurierst?

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 17.01.2020 19:50:58

uff

Code: Alles auswählen

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.3  1.0  33048  8276 ?        Ss   17:51   1:33 /sbin/init
root         2  0.0  0.0      0     0 ?        S    17:51   0:00 [kthreadd]
root         3  0.1  0.0      0     0 ?        S    17:51   0:07 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   17:51   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    17:51   0:00 [watchdog/0]
root         8  0.0  0.0      0     0 ?        S<   17:51   0:00 [khelper]
root         9  0.0  0.0      0     0 ?        S    17:51   0:00 [kdevtmpfs]
root        10  0.0  0.0      0     0 ?        S<   17:51   0:00 [netns]
root        11  0.0  0.0      0     0 ?        S    17:51   0:00 [khungtaskd]
root        12  0.0  0.0      0     0 ?        S<   17:51   0:00 [writeback]
root        13  0.0  0.0      0     0 ?        S<   17:51   0:00 [crypto]
root        14  0.0  0.0      0     0 ?        S<   17:51   0:00 [kintegrityd]
root        15  0.0  0.0      0     0 ?        S<   17:51   0:00 [bioset]
root        16  0.0  0.0      0     0 ?        S<   17:51   0:00 [kblockd]
root        18  0.0  0.0      0     0 ?        S    17:51   0:00 [kswapd0]
root        19  0.0  0.0      0     0 ?        S    17:51   0:00 [fsnotify_mark]
root        25  0.0  0.0      0     0 ?        S<   17:51   0:00 [kthrotld]
root        26  0.0  0.0      0     0 ?        S    17:51   0:00 [spi0]
root        27  0.0  0.0      0     0 ?        S<   17:51   0:00 [deferwq]
root        58  0.0  0.0      0     0 ?        S<   17:51   0:00 [ata_sff]
root        60  0.0  0.0      0     0 ?        S    17:51   0:00 [scsi_eh_0]
root        62  0.0  0.0      0     0 ?        S<   17:51   0:00 [scsi_tmf_0]
root        63  0.0  0.0      0     0 ?        S    17:51   0:00 [scsi_eh_1]
root        64  0.0  0.0      0     0 ?        S<   17:51   0:00 [scsi_tmf_1]
root        65  0.0  0.0      0     0 ?        S    17:51   0:00 [scsi_eh_2]
root        66  0.0  0.0      0     0 ?        S<   17:51   0:00 [scsi_tmf_2]
root        67  0.0  0.0      0     0 ?        S    17:51   0:00 [scsi_eh_3]
root        68  0.0  0.0      0     0 ?        S<   17:51   0:00 [scsi_tmf_3]
root        70  0.0  0.0      0     0 ?        S    17:51   0:00 [scsi_eh_4]
root        71  0.0  0.0      0     0 ?        S<   17:51   0:00 [scsi_tmf_4]
root        73  0.0  0.0      0     0 ?        S    17:51   0:00 [scsi_eh_5]
root        75  0.0  0.0      0     0 ?        S<   17:51   0:00 [scsi_tmf_5]
root        76  0.0  0.0      0     0 ?        S    17:51   0:00 [kworker/u2:5]
root        88  0.0  0.0      0     0 ?        S<   17:51   0:00 [kworker/0:1H]
root       115  0.0  0.0      0     0 ?        S    17:51   0:01 [jbd2/sda2-8]
root       116  0.0  0.0      0     0 ?        S<   17:51   0:00 [ext4-rsv-conver]
root       136  0.0  0.0      0     0 ?        S<   17:51   0:00 [ipv6_addrconf]
root       164  1.0  0.9  31924  7312 ?        Ss   17:52   1:12 /lib/systemd/systemd-journald
root       175  0.0  0.0      0     0 ?        S    17:52   0:00 [kauditd]
root       178  0.0  0.0      0     0 ?        S<   17:52   0:00 [rpciod]
root       214  0.0  0.4  17856  3764 ?        Ss   17:52   0:00 /lib/systemd/systemd-udevd
root       226  0.0  0.0      0     0 ?        S    17:52   0:00 [khubd]
root       227  0.0  0.0      0     0 ?        S    17:52   0:00 [mv_crypto]
root       253  0.0  0.0      0     0 ?        S    17:52   0:00 [scsi_eh_6]
root       254  0.0  0.0      0     0 ?        S<   17:52   0:00 [scsi_tmf_6]
root       255  0.0  0.0      0     0 ?        S    17:52   0:00 [usb-storage]
root       256  0.0  0.0      0     0 ?        S    17:52   0:00 [scsi_eh_7]
root       257  0.0  0.0      0     0 ?        S<   17:52   0:00 [scsi_tmf_7]
root       258  0.0  0.0      0     0 ?        S    17:52   0:00 [usb-storage]
root       259  0.0  0.0      0     0 ?        S    17:52   0:00 [scsi_eh_8]
root       260  0.0  0.0      0     0 ?        S<   17:52   0:00 [scsi_tmf_8]
root       261  0.0  0.0      0     0 ?        S    17:52   0:00 [usb-storage]
root       299  0.0  0.0      0     0 ?        S<   17:52   0:00 [ext4-rsv-conver]
_rpc       463  0.0  0.3   6484  2900 ?        Ss   17:52   0:00 /sbin/rpcbind -f -w
root       490  0.3  0.5  24668  3968 ?        Ssl  17:52   0:25 /usr/sbin/rsyslogd -n -iNONE
root       493  0.4  0.7  13268  5572 ?        Ss   17:52   0:33 /lib/systemd/systemd-logind
message+   494  2.0  0.4   6932  3696 ?        Ss   17:52   2:23 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root       514  0.0  0.3   8328  2532 ?        Ss   17:52   0:00 /usr/sbin/cron -f
daemon     540  0.0  0.2   3304  1804 ?        Ss   17:52   0:00 /usr/sbin/atd -f
root       541  0.0  0.0      0     0 ?        S<   17:52   0:00 [cfg80211]
root       580  2.1  0.7   8804  5968 ?        Ss   17:52   2:28 /usr/sbin/openvpn
nobody     583  0.0  0.7   8380  5636 ?        Ss   17:52   0:00 /usr/sbin/openvpn
root       587  0.0  1.2  32120  9884 ?        Ss   17:52   0:01 /usr/sbin/nmbd --foreground --no-process-group
root       614  0.0  0.7  10684  5660 ?        Ss   17:52   0:04 /usr/sbin/sshd -D
root       648  0.0  0.2   4248  1656 tty1     Ss+  17:52   0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
root       676  0.0  0.4  37248  3244 ?        Ssl  17:52   0:00 /usr/sbin/automount --pid-file /var/run/autofs.pid
www-data   789  0.0  0.6   9992  5188 ?        Ss   17:52   0:02 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
pihole     797  0.0  0.9  14852  7404 ?        Ss   17:52   0:02 /lib/systemd/systemd --user
pihole     811  0.0  0.4  34756  3616 ?        S    17:52   0:00 (sd-pam)
www-data   852  0.0  2.3 121672 17792 ?        Ss   17:52   0:00 /usr/bin/php-cgi
Debian-+  1025  0.0  0.5  14764  4388 ?        Ss   17:52   0:00 /usr/sbin/exim4 -bd -q30m
www-data  1028  0.0  1.2 121672  9844 ?        S    17:52   0:00 /usr/bin/php-cgi
www-data  1029  0.0  1.2 121672  9592 ?        S    17:52   0:00 /usr/bin/php-cgi
www-data  1030  0.0  1.2 121672  9388 ?        S    17:52   0:00 /usr/bin/php-cgi
www-data  1031  0.0  1.2 121672  9544 ?        S    17:52   0:00 /usr/bin/php-cgi
root      1051  0.0  1.6  39608 12888 ?        Ss   17:53   0:01 /usr/sbin/winbindd --foreground --no-process-group
root      1053  0.0  1.2  40024  9400 ?        S    17:53   0:00 winbindd: domain child [QNAP-NAS]
root      1063  0.0  0.9  38900  7300 ?        S    17:53   0:00 winbindd: idmap child
root      1081  0.0  1.1  39608  9012 ?        S    17:53   0:00 winbindd: domain child [BUILTIN]
root      1291  0.0  0.8  12428  6604 ?        Ss   17:57   0:00 sshd: root@notty
root      1297  0.0  0.9  14852  7380 ?        Ss   17:57   0:02 /lib/systemd/systemd --user
root      1298  0.0  0.4  34452  3612 ?        S    17:57   0:00 (sd-pam)
root      1324  0.0  0.1   2000  1452 ?        Ss   17:57   0:00 /usr/lib/openssh/sftp-server
pihole    1429  0.3  2.5  80252 19788 ?        Sl   17:57   0:25 /usr/bin/pihole-FTL
root      1622  0.0  0.2   8244  2312 ?        Ss   18:09   0:00 SCREEN
root      1623  0.0  0.4   7976  3140 pts/1    Ss+  18:09   0:00 /bin/bash
root      1863  0.0  0.2   2340  1760 ?        Ss   18:12   0:00 /usr/sbin/dhcpcd
root      4478  0.0  0.8  12428  6684 ?        Ss   19:23   0:00 sshd: root@notty
root      4493  0.0  0.2   2000  1636 ?        Ss   19:23   0:00 /usr/lib/openssh/sftp-server
root      7331  0.0  0.0      0     0 ?        S    19:28   0:00 [kworker/0:4]
root     10893  0.0  0.0      0     0 ?        S    19:36   0:00 [kworker/0:3]
root     11465  0.0  0.0      0     0 ?        S    18:33   0:00 [kworker/u2:1]
root     11806  0.0  0.8  12428  6616 ?        Ss   19:38   0:00 sshd: root@notty
root     11818  0.0  0.1   2000  1460 ?        Ss   19:38   0:00 /usr/lib/openssh/sftp-server
root     13410  0.0  0.8  12428  6584 ?        Ss   19:41   0:00 sshd: root@notty
root     13421  0.0  0.2   2000  1568 ?        Ss   19:41   0:00 /usr/lib/openssh/sftp-server
systemd+ 14017  0.0  0.7  22456  5640 ?        Ssl  19:42   0:00 /lib/systemd/systemd-timesyncd
root     15553  0.0  0.0      0     0 ?        S    19:45   0:00 [kworker/0:0]
admincon 15749  0.3  0.9  14952  7308 ?        Ss   19:45   0:00 /lib/systemd/systemd --user
admincon 15750  0.0  0.4  34820  3732 ?        S    19:45   0:00 (sd-pam)
root     15872  0.0  0.0      0     0 ?        S    19:45   0:00 [kworker/0:2]
root     17002  7.0  0.8  12428  6580 ?        Ss   19:48   0:00 sshd: admincon [priv]
admincon 17008  0.0  0.5  12428  4508 ?        S    19:48   0:00 sshd: admincon@notty
root     17009  0.0  0.3   9696  2676 pts/0    R+   19:48   0:00 ps augx
root     27993  0.0  0.8  12428  6448 ?        Ss   19:06   0:00 sshd: root@notty
root     28007  0.0  0.1   2000  1448 ?        Ss   19:06   0:00 /usr/lib/openssh/sftp-server
root     28043  0.3  1.0  13908  7880 ?        Ss   19:06   0:08 sshd: root@notty
root     28057  0.0  0.2   2180  1732 ?        Ss   19:06   0:01 /usr/lib/openssh/sftp-server
root     28129  0.0  0.8  12428  6576 ?        Ss   19:06   0:00 sshd: root@pts/0
root     28138  0.0  0.4   8620  3752 pts/0    Ss   19:06   0:00 -bash
root     28203  0.0  0.8  12428  6584 ?        Ss   19:06   0:00 sshd: root@pts/2
root     28215  0.0  0.5   8772  3932 pts/2    Ss+  19:06   0:00 -bash
root     31478  0.0  0.0      0     0 ?        S    19:12   0:00 [kworker/0:1]
Wen ich aber 5min später "sudo /etc/init.d/networking restart" mache, bekommen beide eine ipv6 ohne änderung der /etc/network/interfaces

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Static/dhcp ip vergabe ist zickig

Beitrag von MSfree » 17.01.2020 19:53:55

Conan89 hat geschrieben: ↑ zum Beitrag ↑
17.01.2020 19:50:58
uff
Wieso?
Schau mal auf die von mir gekürzte Ausgabe:

Code: Alles auswählen

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
root      1863  0.0  0.2   2340  1760 ?        Ss   18:12   0:00 /usr/sbin/dhcpcd
...

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 17.01.2020 20:00:38

Ich geb er es erlich zu, ICH hätte das nicht gefunden.
Danke, ich werde mal nach schauen, ob ich die still legen kann oder zu pihole gehört.

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: Static/dhcp ip vergabe ist zickig

Beitrag von eggy » 17.01.2020 20:20:16

Conan89 hat geschrieben: ↑ zum Beitrag ↑
17.01.2020 20:00:38
ICH hätte das nicht gefunden.
Trick fürs nächste Mal: grep

Code: Alles auswählen

ps aux |grep dhcp -i 
grep findet Zeilen, in denen Suchworte vorkommen, hier z.B. alles was dhcp enthält. was das -i ist, überlass ich mal dem Selbststudium (steht in "man grep").

@MSfree: warum g? ps Manpage sagt: "g wählt wirklich alle, selbst die Sitzungsleiter. Dieser Schalter ist veraltet und könnte in zukünftigen Veröffentlichungen nicht mehr zur Verfügung stehen. Es wird normalerweise vom Schalter a impliziert und ist nur nützlich, wenn es in einer SunOs-Prozessausführungsumgebung ausgeführt wird."

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 17.01.2020 21:34:02

Also die
/usr/sbin/dhcpcd
habe ich mal deaktivert und werde es jetzt mal beobachten.


In die interfaces habe ich das
iface eth0 inet6 dhcp
rein gesetzt. (hab schon verstanden was ihr gemeint habt, hat mich nur gewundert das es auch ohne ging)

Code: Alles auswählen

auto lo eth0 eth1
iface lo inet loopback


iface eth0 inet static
 address 192.168.1.111
 netmask 255.255.255.0
 gateway 192.168.1.1
 broadcast 192.168.1.255
iface eth0 inet6 dhcp

iface eth1 inet static
 address 192.168.1.4
 netmask 255.255.255.0
 gateway 192.168.1.1
 broadcast 192.168.1.255
iface eth1 inet6 dhcp
eth0 zieht sich zwar eine v6 eth1 dagegen nicht:

Code: Alles auswählen

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.111  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2a02:8071:::::::::  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::208:::::::: prefixlen 64  scopeid 0x20<link>
        ether 00:08:xx:xx:x:2d  txqueuelen 1000  (Ethernet)
        RX packets 543  bytes 118447 (115.6 KiB)
        RX errors 0  dropped 76  overruns 0  frame 0
        TX packets 526  bytes 58508 (57.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 11

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::208:::::::  prefixlen 64  scopeid 0x20<link>
        ether 00:08:xx:xx:x:2e  txqueuelen 1000  (Ethernet)
        RX packets 166  bytes 16960 (16.5 KiB)
        RX errors 0  dropped 68  overruns 0  frame 0
        TX packets 11  bytes 1042 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 15

Benutzeravatar
bluestar
Beiträge: 2335
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Static/dhcp ip vergabe ist zickig

Beitrag von bluestar » 18.01.2020 11:10:01

Conan89 hat geschrieben: ↑ zum Beitrag ↑
17.01.2020 15:30:15
Die nas ist mit meiner fritzbox direkt mit beiden schnitstellen verbunden. (Gigabit)
Warum hast du beide Netzwerkschnittstellen mit der Fritzbox verbunden? Das führt zwangsläufig zu Problemen und bringt dir erst mal so gar nichts.

Für IPv6 braucht es keinen DHCP-Server, dort kommen Router Advertisements zum Einsatz, einfach mal IPv6 lernen und verstehen.

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 18.01.2020 11:54:08

Ein port ist für dns und dhcp (server) zuständing (1.111), auf dem anderen ports nur smb zugriff auf die festplatten. (1.4) Ich hab mir sehr woll was dabei gedacht.

Ich hab nie geschrieben, die nas sll nen dhcpv6 server sein, sie soll sich ausschließlich um ipv4 kümmern.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Static/dhcp ip vergabe ist zickig

Beitrag von MSfree » 18.01.2020 12:05:12

Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 11:54:08
Ein port ist für dns und dhcp (server) zuständing (1.111), auf dem anderen ports nur smb zugriff auf die festplatten. (1.4) Ich hab mir sehr woll was dabei gedacht.
Und welchen Vorteil versprichst du dir von dieser Aufteilung?

Letztlich sind doch beide NICs mit dem selben Switch (also der Fritte) verbunden. Die Netzwerklast von DHCP ist extrem gering, vielleicht 100 Byte pro Stunde in einem Homenetz. Auch DNS ist vom Traffic her betrachtet völlig bedeutungslos. Eine Netzwerkentlastung ist also nicht gegeben, zumal alles letzlich wieder über den selben Sitch (deine Fritte) geht.

(Nicht nur) Meiner Meinung nach ist diese Aufteilung unsinnig und die Aufteilung in zwei IPs aus dem selben Netzwerksegment sogar gefährlich, weil man damit gerne mal die Routen der beteiligten System durcheinander bringt, bis das Netzwerk aus unerklärlichen Gründen einfach mal steht.

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 18.01.2020 12:09:11

Ok, habs zur kenntnis genommen.

Warum zeiht nur eienr der 2 schnittsellen eine ipv6?
In die interfaces habe ich iface eth0 inet6 dhcp und iface eth1 inet6 dhcp eingetragen.

TomL

Re: Static/dhcp ip vergabe ist zickig

Beitrag von TomL » 18.01.2020 12:15:48

MSfree hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:05:12
Und welchen Vorteil versprichst du dir von dieser Aufteilung?
Ich überlege auch schon die ganze Zeit, was der praktische Vorteil ist.... ich sehe nicht einen. Ganz im Gegenteil, zu den von Dir genannten Risiken sehe ich außerdem die Möglichkeit, dass so ein Konzept vielleicht sogar auch Security-Maßnahmen wie z.B. eine Firewall komplett neutralisieren kann. Wenn man so was nicht absolut sachkundig konfiguriert, halte ich so eine Lösung ebenfalls für schädlich.

Wenn man DNS und DHCP vom Rest trennen will, halte ich eine Lösung wie z.B. in einer VM oder wie LordCarlos vorgeschlagen hat, in einem Docker-Container für die deutlich bessere Alternative. Da läuft das in einem eigenständigen LAN-Client-System. Ich würde die 2. Karte auch deaktivieren.

TomL

Re: Static/dhcp ip vergabe ist zickig

Beitrag von TomL » 18.01.2020 12:19:31

Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:09:11
Warum zeiht nur eienr der 2 schnittsellen eine ipv6?
In die interfaces habe ich iface eth0 inet6 dhcp und iface eth1 inet6 dhcp eingetragen.
Die Interfaces "ziehen" keine IPv6, das ist Sache des Kernels, der für das NIC via SLAAC selber eine IPv6 generiert... das ist also anders, als bei IPv4. Der Parameter "dhcp" unterstellt wahrscheinlich die Verwendung von ULA's (fd00::), was Du aber offensichtlich nicht möchtest. Ändere mal "dhcp" auf "auto" und berichte, was passiert.

Und ggf. -wenns notwendig ist- auch noch das RA akzeptieren:

Code: Alles auswählen

iface eth0 inet6 auto
accept_ra 1

Benutzeravatar
bluestar
Beiträge: 2335
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Static/dhcp ip vergabe ist zickig

Beitrag von bluestar » 18.01.2020 12:30:45

TomL hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:19:31
Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:09:11
Warum zeiht nur eienr der 2 schnittsellen eine ipv6?
In die interfaces habe ich iface eth0 inet6 dhcp und iface eth1 inet6 dhcp eingetragen.
Ich hatte es bereits geschrieben:
bluestar hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 11:10:01
Für IPv6 braucht es keinen DHCP-Server, dort kommen Router Advertisements zum Einsatz, einfach mal IPv6 lernen und verstehen.
Wenn du meinen Rat befolgst, dann kommst auch du zu der Erkenntnis, dass deine Fritzbox Router Advertisements in dein LAN posaunt und deine Hosts (also auch dein NAS) diese Informationen nutzen um sich gemäß SLACC (https://tools.ietf.org/html/rfc4862) automatisch zu konfigurieren.

Ich würde noch mal auf dein IPv4 Setup mit zwei Schnittstellen, gleiches Subnetz und zwei Default-Gateways zurückkommen und ein paar Fragen an dich richten:
1) Warum trägst du zwei Default-Gateways ein?
2) Hast du dich intensiv mit Routing beschäftigt um zu verstehen, was es bedeutet wenn ein Subnetz (192.168.1.0/24) über zwei Netzwerkschnittstellen erreichbar ist?
3) Auf Basis von Frage (2) wo hast du die Source-Based Routing Konfiguration angelegt und wie sieht sie bei dir aus?

Wenn ich so den Thread verfolge und daraus dein Wissen über IP-Netze, Routing, IPv6 betrachte, dann würde ich dir zwei Lösungsansätze empfehlen:
1) Du beschäftigst dich mit Bonding (https://wiki.ubuntuusers.de/Netzwerkkarten_bündeln/)
2) Du folgst TomL's Rat und deaktivierst die zweite Karte

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 18.01.2020 12:40:32

1) muss man das nicht für jeden port extra angeben?
2) genau genommen ist die einstellung:
DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen

FRITZ!Box wird als DNS-Server via DHCPv6 bekannt gegeben. Teile des vom Internetanbieter zugewiesenen IPv6-Netzes werden an nachgelagerte Router weitergegeben. Geräte im Heimnetz bekommen eine IPv6-Adresse via DHCPv6 zugewiesen.
bei meiner Fritzbox aktiv, seid jahrsoballd die ips stimmen, kümmer eich mich ums routen, ein sache nach dem anderen.

Benutzeravatar
bluestar
Beiträge: 2335
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Static/dhcp ip vergabe ist zickig

Beitrag von bluestar » 18.01.2020 12:45:46

Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:40:32
1) muss man das nicht für jeden port extra angeben?
Bitte beschäftige dich mit dem Thema IP-Netzwerke und verstehe erst einmal was die Option Default-Gateway für einen Host bedeutet.
Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:40:32
2) genau genommen ist die einstellung:
DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen
FRITZ!Box wird als DNS-Server via DHCPv6 bekannt gegeben. Teile des vom Internetanbieter zugewiesenen IPv6-Netzes werden an nachgelagerte Router weitergegeben. Geräte im Heimnetz bekommen eine IPv6-Adresse via DHCPv6 zugewiesen.
bei meiner Fritzbox aktiv, seid jahrsoballd die ips stimmen, kümmer eich mich ums routen, ein sache nach dem anderen.
Nein meine Frage (2) und (3) beziehen sich nicht auf IPv6 sondern auf deine IPv4 Konfiguration deines NAS

Conan89
Beiträge: 27
Registriert: 17.01.2020 15:06:41

Re: Static/dhcp ip vergabe ist zickig

Beitrag von Conan89 » 18.01.2020 12:58:52

Darum kümmer ich mich, wen meine jetzigen probleme gelöst sind.
Das waren feste ipv4 vergabe und ipv6 vergabe.

edit: das problem ist gelöst, es war nicht debian, ein neustart der Fritzbox war nur nötig. :facepalm:

TomL

Re: Static/dhcp ip vergabe ist zickig

Beitrag von TomL » 18.01.2020 14:31:11

Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:40:32
1) muss man das nicht für jeden port extra angeben?
Nein, muss man nicht. Ein Port ist was anderes, als ein Interface
Conan89 hat geschrieben: ↑ zum Beitrag ↑
18.01.2020 12:40:32
2) genau genommen ist die einstellung:
DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen

FRITZ!Box wird als DNS-Server via DHCPv6 bekannt gegeben. Teile des vom Internetanbieter zugewiesenen IPv6-Netzes werden an nachgelagerte Router weitergegeben. Geräte im Heimnetz bekommen eine IPv6-Adresse via DHCPv6 zugewiesen.
Das ist falsch, der Präfix ist keine per DHCPv6 zugewiesene IP-Adresse, und wie ich schon sagte, das ist auch kein DHCP und hat mit DHCP absolut nichts zu tun. Das Router Advertisement ist Teil des Neighbor Discovery Protocols und verwendet ICMPv6. Für die IANA ist auch weniger die lokale Interface-ID Deiner NICs relevant, die kann theoretisch weltweit durchaus sehr oft vorkommen, sondern nur die Site-ID... und die ist ganz sicher einmalig. Ums kurz zu sagen, IPv6-Adressen werden bei üblichen DSL-Verträgen/Router nicht per DHCP an lokale Geräte verteilt, sondern von den Client-Geräten stateless selber erstellt.

Antworten