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

E

Encabulator

Well-Known Member
Hallo,
ich habe mir nach ca. 25 Jahren FreeBSD-Pause wieder einen Laptop mit FreeBSD hergerichtet, einen alten ThinkPad T420s. Funktioniert soweit ganz gut, von Kleinigkeiten abgesehen Der zweite Rechner ist ein Linux-Laptop, der per WLAN mit einem MiFi-5G-Router, Typ Zyxel NR2301, verbunden ist.
Des weiteren hat er einen USB-NIC.
Netzwerktechnisch sind die beiden Laptops über einen kleinen HP-Switch miteinander verbunden. Die physikalischen Verbindungen stehen, dazu gleich mehr.
Der NR2301 hat die IP 10.0.0.1. Der Linux-Laptop bezieht seine IP-Adresse per DHCP vom NR2301 und hat die 10.0.0.100.
Das USB-Netzwerkinterface habe ich per ifconfig auf 10.10.10.1 gesetzt.
Der FreeBSD-Rechner hat die statische Adresse 10.10.10.10.
ping vom Linux auf FreeBSD: ping 10.10.10.10 -> OK
ping vom FreeBSD auf LInux: ping 10.10.10.1 -> nach einigen Sekunden des Nachdenkens, 10 bis 20 s, OK
Schon mal eine Zwischenfrage: Das ist nicht normal, oder?Was überlegt er solange?
Vom FreeBSD: ping 10.0.0.100 (lokales Interface wlan0 auf Linux): OK, aber auch hier erste Meldung nach ca. 15 s oder mehr.
Jetzt die Tests, die mir wirklich Kopfzerbrechen machen:
Vom Linux aus klappt ping -4 google.com, die Zieladresse ist 172.217.16.174.
Vom FreeBSD aus klappt das überhaupt nicht, er kann google.com nicht auflösen, und wenn ich auf die IP-Adresse pinge, sagt er: No route to host.

Weil die Fragen kommen werden, hier schon mal die Antworten, die ich geben kann:

Meine rc.conf:

hostname="T420s"
keymap="de.noacc.kbd"
ifconfig_em0="inet 10.10.10.10. netmask 255.255.255.0"
ifconfig_em0_ipv6="inet6 accept_rtadv" # Keine Ahnung, ob das so gut ist!
sshd_enable="YES"
ntpd_enable="YES"
powerd_enable="YES"
moused_nondefault_enable="NO"
dumpdev="AUTO"
zfs_enable="YES"
font6x12="Spleen-6x12"
allscreens_flags="-f 6x12 spleen-6x12"
kld_list="i915kms"
defaultrouter="10.0.0.1"

Meine resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

Ich danke Euch vorab für Tips, Hinweise und Belehrungen :)

Beste Grüße
 
Okay für mich mal kurz vom setup her:

10.0.0.1 /24 <- WLAN-Router
10.0.0.100 /24 <- Linux-Notebook wifi, linux notebook hat 10.0.0.1 als default gateway
10.10.10.1 /24 <- USB-LAN-Karte vom Linux-Notebook, angeschlossen an einen kleinen Switch
10.10.10.10 /24 <- Interne-Lankarte vom FreeBSD-Notebook, angeschlossen an den gleichen kleinen Switch wie die vom Linux Notebook, das FreeBSD hat 10.10.10.1 (das Linux-Notebook) als gateway

Ja, das der ping FreeBSD -> Linux solange dauert ist schon ungewöhnlich.

Was die weiteren steps angeht: Hast du auf dem Linux-Laptop sowohl ip-forwarding aktiviert als auch bei iptables oder eine der anderen packetfilterkramssachen NAT (Masquerading dort oft noch genannt) vom FreeBSD-Netz zum WLAN-Router aktiviert?

Evtl. hilfreich: Mit welcher geschwindigkeit sind die beiden jeweils mit dem Switch verbunden, kannst du defekte Kabel ausschließend und handelt es sich um einen "ordentlichen" USB-Lan-Adapter der dazu noch gut von Linux unterstützt wird?

/edir Hast du irgendwelche Firewall-Regeln oder sonstwas was "ping" auf dem linux blockieren könnte?
 
änder mal die Netmask in 255.0.0.0 auf der FreeBSD Kiste:

Code: 
ifconfig_em0="inet 10.10.10.10. netmask 255.0.0.0"


Deine FreeBSD Maschine hat ein 24er Netz, von da aus gesehen ist der Router aber doch ein Far-Away-Router (nicht im selben Netz)?
 
Danke für die flotte Antwort!
1. Setup: Ja, alles ist so richtig.
2. Ja, IP-forwarding habe ich aktiviert mit echo 1 >> /proc/sys/net/ipv4/ip_forward
3. NAT: nein
4. Geschwindigkeit/Kabel etc.: 1000 Mb/s, Kabel und Switch getestet, soweit möglich. Gigabit-tauglich und ohne Paarungsfehler.
5. Der USB-NIC am Linux: Hochwertiges Teil, unter anderen Bedingungen schon erfolgreich genutzt.
 
Encabulator schrieb:
Danke für die flotte Antwort!
1. Setup: Ja, alles ist so richtig.
2. Ja, IP-forwarding habe ich aktiviert mit echo 1 >> /proc/sys/net/ipv4/ip_forward
3. NAT: nein
Zum Vergrößern anklicken....

Du brauchst entweder NAT oder der NR2301 braucht eine statische route über 10.0.0.100 ins 10.10.10.0/24
/edir (Das NR2301 Gerät wirkt bei google nicht so als könnte man dort statische routen irgendwie reinbasteln, dann bleibt nur nat)

Encabulator schrieb:
4. Geschwindigkeit/Kabel etc.: 1000 Mb/s, Kabel und Switch getestet, soweit möglich. Gigabit-tauglich und ohne Paarungsfehler.
5. Der USB-NIC am Linux: Hochwertiges Teil, unter anderen Bedingungen schon erfolgreich genutzt.
Zum Vergrößern anklicken....
Das klingt schonmal gut

Äh ich weiß blöde Frage, aber was spricht dagegen das FreeBSD Notebook direkt an dem WLAN vom NR2301 anzumelden?

turrican schrieb:
Deine FreeBSD Maschine hat ein 24er Netz, von da aus gesehen ist der Router aber doch ein Far-Away-Router (nicht im selben Netz)?
Zum Vergrößern anklicken....
Sind unterschiedliche physische netze, da ist nichts gebrückt, AFAIK kann man WLAN auch nicht von nem client auf layer2 brücken, nur am AP.
 
turrican schrieb:
änder mal die Netmask in 255.0.0.0 auf der FreeBSD Kiste:

Code: 
ifconfig_em0="inet 10.10.10.10. netmask 255.0.0.0"


Deine FreeBSD Maschine hat ein 24er Netz, von da aus gesehen ist der Router aber doch ein Far-Away-Router (nicht im selben Netz)?
Zum Vergrößern anklicken....
Habe ich probiert: geändert und Reboot. Leider ist jetzt die Situation schlechter, ich kann vom FreeBSD die 10.0.0.100 auf dem Linux nicht mehr anpingen.

Ich reboote mal den Linux-Rechner...
 
CommanderZed schrieb:
Du brauchst entweder NAT oder der NR2301 braucht eine statische route über 10.0.0.100 ins 10.10.10.0/24
/edir (Das NR2301 Gerät wirkt bei google nicht so als könnte man dort statische routen irgendwie reinbasteln, dann bleibt nur nat)


Das klingt schonmal gut

Äh ich weiß blöde Frage, aber was spricht dagegen das FreeBSD Notebook direkt an dem WLAN vom NR2301 anzumelden?


Sind unterschiedliche physische netze, da ist nichts gebrückt, AFAIK kann man WLAN auch nicht von nem client auf layer2 brücken, nur am AP.
Zum Vergrößern anklicken....
Ist gar keine blöde Frage :)
bsdconfig erkennt den WiFi-Adapter auf dem T420s nicht, sonst hätte ich es schon gemacht. Natürlich bin ich auch prinzipiell am Problem interessiert, wäre natürlich super, hier mehr Verständnis zu erwerben ;)
 
Zur Frage weiter oben: Nein, keine Firewall-Regeln auf dem LInux-Laptop.
Ich recherchiere mal, wie man das NAT auf FreeBSD aktiviert...
Edit:
Ich lese das so, daß NAT eine Rolle spielt, wenn der FreeBSD-Rechner selber Gateway ist. Das ist ja nicht der Fall, er ist Endkunde im Netz.
Die Frage ist, ob der Linux-Rechner vielleicht gegenüber dem NR2301 NAT einsetzen sollte, um die Adresse des FreeBSD-PCs anzupassen...
 
Encabulator schrieb:
..., ich kann vom FreeBSD die 10.0.0.100 auf dem Linux nicht mehr anpingen.
Zum Vergrößern anklicken....
Wie sind z. Zt. in FreeBSD die Ausgaben von:
Code: 
arp -a
route -4n get 10.0.0.100
?

EDIT:

Welche Routen es in deinem FreeBSD gibt, kannst du mit z. B.:
Code: 
netstat -4nr
pfctl -s nat
anzeigen lassen.

In Linux mit z. B.:
Code: 
ip r g 10.10.10.10
ip n s
ip -4 r
iptables -nvx -L -t nat
 
Zuletzt bearbeitet:
Encabulator schrieb:
Zur Frage weiter oben: Nein, keine Firewall-Regeln auf dem LInux-Laptop.
Ich recherchiere mal, wie man das NAT auf FreeBSD aktiviert...
Zum Vergrößern anklicken....
Das wird dir nichts nützen, du must das NAT auf dem Linux-Laptop aktivieren und das FreeBSD-Netz gegenüber dem WLAN naten, so das es für den router aussieht wie als würden die FreeBSD päckchen vom Linux-Notebook kommen.

So wie es jetzt aufgebaut ist bekommt der NR2301 Pakete aus einem Netz das er nicht kennt, er kennt ja nur das WLAN. Er nimmt das Paket, will was zurückschicken und ... weil er das quell-netz des pakets nicht direkt kennt wird er das an sein eigenes default gateway weitergeben (Oder verwerfen weil es aus ner nicht öffentlichen range kommt, das ist etwas firmware abhängig, ggf. auch weil es aus ner unerwarteten richtung kommt)

Das lässt sich entweder durch NAT auf dem Linux-Laptop lösen oder durch eine statische Route auf dem NR2301 - soho router können das oft nicht, die etwas engagiertere Fritzbox kann es z.B. (wenn auch ziemlich versteckt). Durch die statische route würde der NR2301 wissen "Aha, Päckchen aus dem Netz bzw das Netz 10.10.10.0/24, liegen hinter dem router 10.0.0.100, also geht das nicht ans default-gateway sondern an eben diesen.
 
CommanderZed schrieb:
Sind unterschiedliche physische netze, da ist nichts gebrückt, AFAIK kann man WLAN auch nicht von nem client auf layer2 brücken, nur am AP.
Zum Vergrößern anklicken....
ahso, jetzt in Ruhe (vorher hatte mich meine Frau am Küchentisch über ihren Tag vollgetextet und ich hab drübergelesen) hab ich übersehen - sein anderes GW dafür ist 10.10.10.1

die NR2301 müsste dann Routen für beide Netze konfiguriert haben damit das funktioniert
 
morromett schrieb:
Wie sind z. Zt. in FreeBSD die Ausgaben von:
Code: 
arp -a
route -4n get 10.0.0.100
?

EDIT:

Welche Routen es in deinem FreeBSD gibt, kannst du mit z. B.:
Code: 
netstat -4nr
pfctl -s nat
anzeigen lassen.

In Linux mit z. B.:
Code: 
ip r g 10.10.10.10
ip n s
ip -4 r
iptables -nvx -L -t nat
Zum Vergrößern anklicken....
Ich habe es vorhin geschafft, den FreeBSD-PC direkt mit dem NR2301 zu verbinden. Das ist super! Da ich aber am Ausgangsproblem durchaus sehr interessiert bin, werde ich diese Konfiguration erstmal sichern. Anschließend werde ich WiFi wieder deaktivieren, um zur Ausgangsituation zurückzukehren. Das kann ich aber erst morgen machen, werde dann aber alles abarbeiten, was Du aufgeschrieben hast. Ich melde mich dann wieder!
Und vielen Dank!
 
CommanderZed schrieb:
Das wird dir nichts nützen, du must das NAT auf dem Linux-Laptop aktivieren und das FreeBSD-Netz gegenüber dem WLAN naten, so das es für den router aussieht wie als würden die FreeBSD päckchen vom Linux-Notebook kommen.

So wie es jetzt aufgebaut ist bekommt der NR2301 Pakete aus einem Netz das er nicht kennt, er kennt ja nur das WLAN. Er nimmt das Paket, will was zurückschicken und ... weil er das quell-netz des pakets nicht direkt kennt wird er das an sein eigenes default gateway weitergeben (Oder verwerfen weil es aus ner nicht öffentlichen range kommt, das ist etwas firmware abhängig, ggf. auch weil es aus ner unerwarteten richtung kommt)

Das lässt sich entweder durch NAT auf dem Linux-Laptop lösen oder durch eine statische Route auf dem NR2301 - soho router können das oft nicht, die etwas engagiertere Fritzbox kann es z.B. (wenn auch ziemlich versteckt). Durch die statische route würde der NR2301 wissen "Aha, Päckchen aus dem Netz bzw das Netz 10.10.10.0/24, liegen hinter dem router 10.0.0.100, also geht das nicht ans default-gateway sondern an eben diesen.
Zum Vergrößern anklicken....
Das klingt alles nachvollziehbar :) Danke! Und ja, der Zyxel kann nicht viel, das ist kein Business-Device :)
An die NAT-Sache auf Linux gehe ich morgen dran, einfach weil's mich stark interessiert! Der FreeBSD kann ja jetzt WiFi ;)
 
turrican schrieb:
ahso, jetzt in Ruhe (vorher hatte mich meine Frau am Küchentisch über ihren Tag vollgetextet und ich hab drübergelesen) hab ich übersehen - sein anderes GW dafür ist 10.10.10.1

die NR2301 müsste dann Routen für beide Netze konfiguriert haben damit das funktioniert
Zum Vergrößern anklicken....
Ja, das habe ich jetzt verstanden. Da gehe ich morgen ran, heute abend ist keine Zeit mehr dafür. Danke! Bis dann!
 
Ein neuer Tag, eine neue Übersicht mit Änderungen seit gestern:
1) WLAN läuft, beide Rechner können also zeitgleich über den NR2301 ins Internet. Cool!
2) Zwischen den Interfaces 10.10.10.1 (Linux) und 10.10.10.10 (FreeBSD) konnte ich SSH-Verbindungen aufbauen und per sshfs Verzeichnisse mounten. Ob das stabil und persistent funktioniert, weiß ich noch nicht, das will ich erstmal über ein paar Reboots auf beiden Seiten bestätigt sehen.

Letzter Stand ist jetzt der Versuch, auf Linux ip-forwarding dauerhaft einzurichten und das Masquerading einzuschalten gemäß Vorschlag von CommanderZed, danke nochmals!

Um das dann zu testen, habe ich auf FreeBSD das Interface wlan0 einfach heruntergefahren. Danach kann man erfolgreich 10.10.10.1 anpingen, wenn man, komischerweise, 20 s wartet. Ein ping auf 10.0.0.100 dagegen bringt "Network is down".

An dieser Stelle hänge gerade fest. Ich werde mal schauen, ob ich die defaultroute anpassen muß/kann...
 
route flush
route add default 10.10.10.1

Und schon bin ich ein Stück weiter. /etc/resolv angepaßt, die Google-Nameserver sind eingetragen, sonst nichts. Aber dennoch geht kein ping google.com: cannot resolve...
 
Encabulator schrieb:
Danach kann man erfolgreich 10.10.10.1 anpingen, wenn man, komischerweise, 20 s wartet. Ein ping auf 10.0.0.100 dagegen bringt "Network is down".

An dieser Stelle hänge gerade fest. Ich werde mal schauen, ob ich die defaultroute anpassen muß/kann...
Zum Vergrößern anklicken....
Schau mal ob der arp- bzw. der neighbor-Cache nach 20 Sekunden anders aussieht als vorher.
Warum die default Route (die eine undefinierte Route ist) anpassen? Was du brauchst, ist eine geeignete definierte (statische) Route zu dem Host (oder Subnetz) den du erreichen willst.
BTW: Definierte Routen sind gegenüber der nicht definierten (default) Route, priorisiert.
 
morromett schrieb:
Schau mal ob der arp- bzw. der neighbor-Cache nach 20 Sekunden anders aussieht als vorher.
Warum die default Route (die eine undefinierte Route ist) anpassen? Was du brauchst, ist eine geeignete definierte (statische) Route zu dem Host (oder Subnetz) den du erreichen willst.
BTW: Definierte Routen sind gegenüber der nicht definierten (default) Route, priorisiert.
Zum Vergrößern anklicken....
Oh, dann hänge ich wohl alten Legenden an ;) aber ich lerne gerne dazu. Kannst Du mir denn sagen, welche Route ich anlegen muß?
Ausprobieren kann ich es dann aber erst heute abend. Besten Dank!
Nach Diktat verreist :)
 
Ja, das hatte ich mit Deinem Befehl eingeschaltet, ebenso wie das IP-Forwarding. Ich werde morgen weiter an dem Thema arbeiten. Ich denke mal, daß die nötige Route auf dem FreeBSD eingerichtet werden muß. Ich dachte immer, in so einem Fall benötige man eine defaultroute, aber das ist wohl nicht richtig. Also gilt es jetzt herauszufinden, die korrekte Route einzusetzen. Das ist meine Aufgabe für morgen.

Vielen Dank an alle Beteiligten bis hierher!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben