Bitte um Nachhilfe: Ein WLAN-Router plus 1 Linux-PC und 1 FreeBSD-PC

[Encabulator]

Ich habe jetzt herausgefunden, daß man

route add default -ifp 10.0.0.1 -ifp em0

eingeben kann. Aber der gewünschte Effekt tritt nicht ein, es läuft dann weiterhin über wlan0, keine Ahnung warum.
Der Tip mit der rc.conf ist gut, das werde ich ausprobieren. Vielen Dank! Melde mich dann wieder...

 

[morromett]

Ich habe jetzt herausgefunden, daß man

route add default -ifp 10.0.0.1 -ifp em0

eingeben kann. Aber der gewünschte Effekt tritt nicht ein, es läuft dann weiterhin über wlan0, ...

BTW: Die Wirksamkeit deiner Änderung/Konfiguration kannst Du testen, mit z. B.:

route -4n show default
route -4n get 8.8.8.8

 

[Encabulator]

Auf dem FreeBSD ist wlan0 jetzt komplett aus dem Spiel:

$ ifconfig -a
em0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether f0:de:f1:80:3a:be
        inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255
        inet6 fe80::f2de:f1ff:fe80:3abe%em0 prefixlen 64 scopeid 0x1
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 02:80:37:ec:02:00
        media: Ethernet autoselect
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Leider komme ich trotzdem nicht weiter als bis zum 10.0.0.100. Ich vermute, daß auf dem Linux-Rechner die Rückroute fehlt. Ich werde weiter recherchieren und testen.

 

[Encabulator]

BTW: Die Wirksamkeit deiner Änderung/Konfiguration kannst Du testen, mit z. B.:

route -4n show default
route -4n get 8.8.8.8

Ist notiert, danke!

 

[Encabulator]

Also eigentlich reicht da eine defaultroute bei dem FreeBSD auf den linux-pc (Genaugenommen auf die ip vom Lan-Interface) und vom Linux-PC auf den Zyxel (Sollte per DHCP kommen). Dann noch das IP-Masquerading/NAT auf dem Linux PC und es sollte laufen.
Bei dem NAT ist es wichtig den richtigen Interfacenamen anzugeben, Linux ist da ja je nach modell oft etwas eigenwillig.

Was @morromett da noch plant erschließt sich mir nicht so direkt. Statische routen müsste man bei diesem konstrukt das ich so selbst schon mehrfach gebaut hab nur dann setzen wenn man das mit dem NAT nicht macht, und diese dann halt auf dem Zyxel was halt nicht geht.
Das FreeBSD muss nur wissen das es alle pakete an das Linux ding gibt als route und das linux das es alles ans zyxel gibt.

Wenns nicht funktioniert, wären die ausgaben von ifconfig bzw ip a von beiden system villeicht noch hilfreich und alle einträge der routing tabelle und alle arp-einträge, am besten mal in einem Post zusammengefasst

Und einmal ein ping und ein traceroute als ausgabe hier
-> Linux -> Zyxel (nur ping)
-> Linux 8.8.8.8
-> FreeBSD Linux (Nur ping)
-> FreeBSD Zyxel
-> FreeBSD 8.8.8.8

Evtl. auch interessant: Welches linux verwendest du, wie konfigurierst du die statischen ip adressen dort und das wifi? Networkmanager, systemd-networkd oä

Hast du noch ein anderes system das du statt dem freebsd an den switch hängen kannst um diese dubiosen schon lokalen probleme zu debuggen?

Auf dem Linux-Rechner verwende ich Kali. Das Netzwerkmanagement läuft über systemd, networking.service. Über das Applet in der Taskbar habe ich eth0 konfiguriert mit der statischen Adresse 10.10.10.1/24.

Ich bin zur Zeit nicht zu Hause, daher habe ich nur zwei Rechner plus diesen Switch dabei, um die Versuche zu machen.

Das NAT/Masquerading führe ich nach dem Booten von Hand aus:
iptables -t nat -A POSTROUTING -o 10.0.0.1 -j MASQUERADE

10.0.0.1 ist der Zyxel-Router. Ich hoffe, das ist die korrekte Adresse an dieser Stelle.

Verstehe ich das richtig, daß der iptables-Befehl auch für die entsprechende Rückroute sorgen würde? (Wäre ja auch sinnvoll, denn wenn er maskiert, müßte er ja auch zurückübersetzen könnten...)

 

[medV2]

Verstehe ich das richtig, daß der iptables-Befehl auch für die entsprechende Rückroute sorgen würde? (Wäre ja auch sinnvoll, denn wenn er maskiert, müßte er ja auch zurückübersetzen könnten...)

Ja. Je nach Linuxdistro, verwendeter Firewall und Co, kann aber eine Default-Block Policy in der Forward Table stehen, das müsste dann gegen Default-Accept oder zumindest eine eigenen Allow established/related Regel getauscht werden. Kann ich für Kali aber nicht sagen, vermutlich ist iptables auch nur ein Wrapper für nftables?

 

[morromett]

Das NAT/Masquerading führe ich nach dem Booten von Hand aus:
iptables -t nat -A POSTROUTING -o 10.0.0.1 -j MASQUERADE

10.0.0.1 ist der Zyxel-Router. Ich hoffe, das ist die korrekte Adresse an dieser Stelle.

Deine source-NAT-Regel (MASQUERADE) ist nicht OK. Konfiguriere in deinem Linux:

iptables -t nat -D POSTROUTING -o 10.0.0.1 -j MASQUERADE
iptables -t nat -I POSTROUTING 1 -o wlan0 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o eth0 -j MASQUERADE

und

sysctl -w net.ipv4.conf.all.arp_filter=1
sysctl -w net.ipv4.conf.all.rp_filter=1

Hinweis: Das alles ist nicht persistent.
Die default route in deinem Linux geht über das wlan0-Interface. Siehe z. B. die Ausgaben von:

ip r g 8.8.8.8
mtr -4nr -c 1 8.8.8.8
ip r g 10.10.10.10
mtr -4nr -c 1 10.10.10.10
arping -c 2 -I eth0 10.10.10.10
iptables -nvx -L -t nat  # die Zähler der 2 source-NAT-Regeln.
iptables -nvx -L  # für die default policy der FORWARD-chain
sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.forwarding net.ipv4.conf.all.bc_forwarding net.ipv4.conf.all.mc_forwarding
nft list ruleset   # wenn Du statt iptables-, die nftables-Regeln sehen willst. ;-)

BTW: Kali-Linux ist OK, denn es basiert auf debian.

EDIT:

Evtl. dein Kali-Linux, mit dem boot-Parameter "ipv6.disable=1" booten.

 

[Encabulator]

Deine source-NAT-Regel (MASQUERADE) ist nicht OK. Konfiguriere in deinem Linux:

iptables -t nat -D POSTROUTING -o 10.0.0.1 -j MASQUERADE
iptables -t nat -I POSTROUTING 1 -o wlan0 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o eth0 -j MASQUERADE

und

sysctl -w net.ipv4.conf.all.arp_filter=1
sysctl -w net.ipv4.conf.all.rp_filter=1

Hinweis: Das alles ist nicht persistent.
Die default route in deinem Linux geht über das wlan0-Interface. Siehe z. B. die Ausgabe von:

ip r g 8.8.8.8

BTW: Kali-Linux ist OK, denn es basiert auf debian.

Vielen Dank!
Das muß ich mir dann morgen in Ruhe anschauen und umsetzen! Ich melde mich dann!
Einen schönen Abend und bis morgen

 

[Encabulator]

Ich habe die drei Regeln ausprobiert, es war mir unmöglich, die erste einzugeben. Es gab jedesmal eine Fehlermeldung:

iptables: Bad rule (does a matching rule exist in that chain?).

Auch iptables -F hat nichts genützt.

Des weiteren habe ich noch einen älteren Thread entdeckt (https://forums.raspberrypi.com/viewtopic.php?t=355546) und habe die hier angegebenen Regeln mal getestet:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

Tatsächlich hat das einen gewissen Erfolg gehabt, sodaß ich sogar den Webbrowser auf FreeBSD verwenden konnte. Dann stellte sich aber schnell heraus, daß sich keine SSH-Shell auf den Linux-Laptop hat öffnen lassen.

Die einzige Konfiguration, in der beide Rechner eine SSH-Verbindung zum anderen aufbauen können, sshfs nutzen können und Internet-Zugang haben, ist der NR2301 als einziger Router, mit dem sich beide verbinden. Der Versuch, den Linux-Rechner als Router vor dem NR2301 zu konfigurieren, hat nicht vollumfänglich funktioniert.

Mein Wissen ist einfach zu bruchstückhaft, um die geplante Konfiguration umzusetzen. Durch Eure Hilfe habe ich das Ziel jetzt klarer vor Augen, danke dafür! Ich werde die Experimente fortsetzen, wenn ich wieder mein komplettes Netzwerk zur Verfügung habe, dann stehen mir einfach mehr Möglichkeiten zur Verfügung und das Arbeiten ist deutlich komfortabler als unter den momentanen Umständen.

Vielen Dank für all die Hinweise und Tips, Gruß an alle und noch einen schönen Sonntag!

 

[morromett]

Ich habe die drei Regeln ausprobiert, es war mir unmöglich, die erste einzugeben. Es gab jedesmal eine Fehlermeldung:

iptables: Bad rule (does a matching rule exist in that chain?).

Auch iptables -F hat nichts genützt.

War das sofort nach dem booten? Wenn ja, dann gab es nichts zu löschen, denn ich habe doch geschrieben, dass deine Eingaben/Konfigurationen (... in der Testphase noch) nicht persistent sind.

sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

Tatsächlich hat das einen gewissen Erfolg gehabt, sodaß ich sogar den Webbrowser auf FreeBSD verwenden konnte. Dann stellte sich aber schnell heraus, daß sich keine SSH-Shell auf den Linux-Laptop hat öffnen lassen.

BTW: War oder ist die default policy in deiner FORWARD-chain auf DROP?

Dann stellte sich aber schnell heraus, daß sich keine SSH-Shell auf den Linux-Laptop hat öffnen lassen.

Ist der sshd-Server auf deinem Linux-Laptop, installiert und richtig konfiguriert? Wie sind z. Zt. auf deinem Linux-Laptop die Ausgaben von:

ls -la /usr/sbin/sshd
sudo sshd -t
sudo netstat -tlpena | grep -i sshd
systemctl status ssh

?
Wenn der sshd auf dem Port 22 lauscht, dann versuch mal einen Portscan (aus dem Subnetz des Laptops) auf den TCP-Port 22 deines Linux-Laptops. Z. B.:

:~$ nc -zvn 142.132.203.155 22
(UNKNOWN) [142.132.203.155] 22 (ssh) open

(IP-Adresse anpassen).

 

[Encabulator]

Ich habe schon verstanden, daß Deine 3 NAT-Regeln erst einmal nicht persistent sind. Ich habe gebootet und dann versucht, die Regeln einzugeben, aber die erste wurde einfach nicht angenommen, ohne daß ich herausfinden konnte, warum.

Da es ja völlig risikofrei war, dachte ich: Lösch mal alles, was vielleicht an Regeln vorhanden ist. Aber auch danach kam diese Fehlermeldung bei der ersten Regel.

Zu den anderen drei Regeln aus dem besagten Thread: Ich habe nur diese drei eingegeben, andere Änderungen habe ich über iptables nicht vorgenommen. Ich habe auch mit iptables noch nie auf diesem Rechner gearbeitet. Also, völlig blank, die drei Thread-Regeln, fertig. Dann habe ich angefangen zu testen, was damit geht und was nicht.

Was den Komplex SSH/SSHFS angeht: Moment arbeite ich mit einer Dreieckskonfiguration. Keine Kabelverbindungen, nur wlan0 hüben wie drüben. Beide angemeldet auf dem NR2301. In diesem Zustand kann ich mich per ssh vom Linux aus auf dem FreeBSD (10.0.0.111) anmelden und das gleiche umgekehrt, also vom FreeBSD auf den Linux (10.0.0.100). Das funktioniert ohne Stottern, Ruckeln und ähnliche Probleme. Die SSH-Konfiguration ist also tiptop.

 

[morromett]

Ich habe gebootet und dann versucht, die Regeln einzugeben, aber die erste wurde einfach nicht angenommen, ohne daß ich herausfinden konnte, warum.

Die 1. Regel ist eine Regel zum löschen einer bereits vorhandenen Regel. Aber bei dir war nach dem booten keine Regel vorhanden, und deshalb diese Meldung.

EDIT:

Dann wird die default policy in der FORWARD-chain auf ACCEPT sein (d. h. alles per default erlaubt). Das kannst Du mit z. B.:

iptables -nvx -L FORWARD | grep -i policy

sehen.

EDIT 2:

Dann verstehe ich nicht, was Du oben in deinem Beitrag, mit:

Dann stellte sich aber schnell heraus, daß sich keine SSH-Shell auf den Linux-Laptop hat öffnen lassen.

meinst.

 

[Encabulator]

Okay, danke! Dann probiere ich das heute nochmal in Ruhe aus. - Zu Deiner Frage, EDIT 2: Was ich damit meinte, war ganz einfach, daß ich vom FreeBSD aus keinen Erfolg hatte mit dem Befehl ssh hmb@10.10.10.1. Es hat für mich oberste Priorität, daß SSH-Zugriffe funktionieren, auch sshfs-Mounts. Das war in dieser Testkonfiguration nicht der Fall, und ich konnte die Ursache nicht finden.

Wie gesagt, ich probiere Deinen Vorschlag heute nochmal aus und berichte. Bis dann!

 

[morromett]

Was ich damit meinte, war ganz einfach, daß ich vom FreeBSD aus keinen Erfolg hatte mit dem Befehl ssh hmb@10.10.10.1. Es hat für mich oberste Priorität, daß SSH-Zugriffe funktionieren, ...

Ja, ssh ist gut und wichtig.
In so einem Fall teste ich die Erreichbarkeit und evtl. "verbose messages" mit der Option "-v" oder "-vvv" für den ssh-Client. Z. B.:

nc -zvn 10.10.10.1 22

bzw.

ssh -vvv hmb@10.10.10.1

-v Ausführlicher Modus. Führt dazu, dass ssh Fehlersuchmeldungen über seinen Fortschritt ausgibt. Dies ist für die Fehlersuche bei Verbindungs-, Authentifizierungs- und Konfigurationsproblemen hilfreich. Mehrere Optionen -v erhöhen die Ausführlichkeit. Das Maximum ist 3.

Quelle: manpage für ssh

 

[Encabulator]

So, ich habe jetzt nochmal alles sortiert, physisch, gedanklich, script-mäßig etc. pp.

Deine fünf Befehle habe ich in ein Script gepackt, um sie kontrolliert ausführen zu können. Nachdem dann alles soweit geklärt war, daß gegenseitige Pings funktioniert haben (mit kleinen Einschränkungen, darauf komme ich gleich), sah es nach einem Erfolg aus!

Ich konnte vom FreeBSD aus 8.8.8.8 anpingen und auch google.com, nachdem ich route add default 10.10.10.1 eingegeben hatte.

Auf dem FreeBSD kann ich ssh hmb@10.10.10.1 eingeben und erhalte dann, unter Umständen nach kurzer Wartezeit, ein Login und das Eingabeprompt, aber es gibt immer wieder mal lange Reaktionszeiten, bis ein Befehl oder einfach nur die Eingabe von Zeichen beantwortet wird, sprich: die Zeichen sichtbar werden.

Also, danke nochmals für Deine Lösung!

Ich muß jetzt mal weitere Tests machen und werde die vorhandene Konfiguration auf FreeBSD beibehalten. Hierzu habe ich aber noch ein paar Fragen, vielleicht kannst Du mir dabei auch weiterhelfen:

1. Auf dem FreeBSD habe ich nur IPv4, hätte aber gerne auch IPv6 zur Verfügung. Was wäre da zu tun?

2. Ist es der korrekte Weg, nach dem Booten route add default 10.10.10.1 einzugeben? Ohne diese Route kann ich 10.0.0.100 auf dem Linux-Rechner nämlich nicht anpingen.

Meine rc.conf sieht so aus:

hostname="T420s"
keymap="de.noacc.kbd"
# ifconfig_em0="DHCP"
ifconfig_em0="inet 10.10.10.10 netmask 255.255.255.0"
ifconfig_em0_ipv6="inet6 accept_rtadv"
sshd_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
moused_nondefault_enable="NO"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
# sysrc kld_list+="i915kms"
font6x12="spleen-6x12"
allscreens_flags="-f 6x12 spleen-6x12"
kld_list="i915kms"
defaultrouter="10.0.0.1"
# wlans_iwn0="wlan0"
# ifconfig_wlan0="WPA SYNCDHCP"
fusefs_enable="YES"
keyrate="fast"

Ansonsten werde ich jetzt erstmal mit der Konfiguration weiter arbeiten, um herauszufinden, was es mit diesen Verzögerungen in den SSH-Sitzungen auf sich hat. Ein ähnliches Wartephänomen gibt es auch bei ping-Befehlen, wie ich ja schon weiter oben mehrfach erwähnt habe. Ich habe die starke Vermutung, daß das klare konfigurationsseitige Gründe hat. Mit anderen Worten, wenn alles paßt und korrekt ist, dann sollte ein ping-Befehl mindestens im lokalen Netzwerk sofort eine Antwort liefern. Wenn das nicht der Fall ist und man z. B. 18 s warten muß, das reicht signaltechnisch für 135 Erdumläufe

PS: Auf dem Linux-Rechner funktionieren IPv4 und IPv6, ich teste das ganz gerne mit ip.zuim.de.

 

[morromett]

Ist der Ping auch mit der IP-Adresse verzögert? Hast Du in der sshd_config, "UseDNS no" oder "UseDNS yes" wirksam konfiguriert? Eine andere/weitere Ursache könnte auch die MTU sein.
Sendet der Router bzgl. IPv6, RAs (router advertisments) aus, die am/beim Client ankommen? Das kannst Du z. B. auch mit tcpdump und geeignetem Filter (oder gleichwertig), feststellen.

 

[Encabulator]

1. Ping: Ja, auf dem FreeBSD ist der ping 10.10.10.1 um 18 s verzögert.

2. Ich habe jetzt in der sshd_config eingestellt: UseDNS no
Das hatte erstmal keinen Einfluß auf diese Wartezeiten. Interessant übrigens: Erstens fühlt es sich, als kämen die Wartezeiten nach einer gewissen Zeitspanne ohne Wartezeiten wieder zurück. Zweitens kommt es auch zu Operation timed out in der Session, gefolgt von Broken pipe.

3. Bezüglich IPv6 muß ich mich noch kurz schlau machen, wie ich das prüfen bzw. nachweisen kann.

 

[Encabulator]

Meinst Du so etwas hier?

16:57:46.969080 IP6 (class 0xc0, flowlabel 0xbdd57, hlim 255, next-header ICMPv6 (58) payload length: 88) _gateway > ZenBook14: [icmp6 sum ok] ICMP6, router advertisement, length 88

 

[Encabulator]

Die SSH-Sessions, die vom Linux-Rechner angestoßen werden, stehen übrigens stabil, keinerlei Probleme.

 

[Encabulator]

Der erste Versuch mit nc -zvn 10.10.10.1 22 auf dem FreeBSD hat Erfolg gezeigt. Der zweite nicht, time out. Der dritte ging dann wieder... Wie gesagt, es kommt einem vor, als laufe im Hintergrund eine Zeitscheibe mit, die einen Slot hat, in dem Netzwerkkommandos klappen. Kommt man im falschen Moment, ist entweder warten angesagt oder man bricht ab, und probiert es später. Ganz merkwürdig... Der zweite nc-Befehl lief nach einer Minute und fünfzehn Sekunden in ein time-out und meldete failed. Der dritte Versuch, kurz danach, klappte auf Anhieb.

 

[morromett]

1. Ping: Ja, auf dem FreeBSD ist der ping 10.10.10.1 um 18 s verzögert.

Dann mach vor dem Ping, immer einen arping (mit arp auf Layer 2) und danach den Ping (mit icmp auf Layer 3):

arping -c 3 -I <Interface> 10.10.10.1
arp -a

, um zu schauen ob der Ping dann auch um 18 s verzögert ist.

Interessant übrigens: Erstens fühlt es sich, als kämen die Wartezeiten nach einer gewissen Zeitspanne ohne Wartezeiten wieder zurück. Zweitens kommt es auch zu Operation timed out in der Session, gefolgt von Broken pipe.

Schau mal wie die timeout- und keepalive-Einstellungen auf dem Server und Client sind.

Meinst Du so etwas hier?

16:57:46.969080 IP6 (class 0xc0, flowlabel 0xbdd57, hlim 255, next-header ICMPv6 (58) payload length: 88) _gateway > ZenBook14: [icmp6 sum ok] ICMP6, router advertisement, length 88

Ja.

 

[morromett]

Der zweite nicht, time out. Der dritte ging dann wieder... Wie gesagt, es kommt einem vor, als laufe im Hintergrund eine Zeitscheibe mit, die einen Slot hat, in dem Netzwerkkommandos klappen. Kommt man im falschen Moment, ist entweder warten angesagt oder man bricht ab, und probiert es später. Ganz merkwürdig...

Poste mal eine Skizze mit deiner Netzwerk-Topologie (... d. h. mit der Anordnung deiner Geräte (inkl. IP-Adressen/Subnetz/Interfaces) und Leitungen/Verbindungen)..

 

[Encabulator]

Die ping/arping-Tests kann ich erst heute nachmittag/abend machen, aber eine Skizze folgt sogleich...

 

[morromett]

... eine Skizze ...

BTW: Wenn es Probleme mit dem Switch gibt, dann teste mal temporär auch mit einer direkten Kabelverbindung zwischen deinem Kali-Linux-Gerät und zwischen dem FreeBSD-Gerät.

 

[Encabulator]

Dann bräuchte ich aber ein Cross-Over-Kabel, oder nicht? Habe ich nämlich nicht zur Verfügung.