(teilweise gelöst) routing und /etc/network/interfaces?

[Tintom]

gw Router
Alle IP-Pakete für das Zielnetzwerk / -System werden zum angegebenen Router weitergeleitet.

ANMERKUNG: Das angegebene Ziel muß zuerst erreichbar sein.

Vermutung: Das Ziel ist noch nicht erreichbar, weil hostapd zum Zeitpunkt der "up route..."-Anweisung noch nicht soweit ist ?!

[guennid]

Code: Alles auswählen

ANMERKUNG: Das angegebene Ziel muß zuerst erreichbar sein. Üblicherweise bedeutet das, das zuerst eine  statische  Route  zum Router  eingetragen  werden.  Wird die Adresse einer lokalen Schnittstelle angegeben, so wird sie benutzt um zu entscheiden zu welcher Schnittstelle die Pakete weitergeleitet werden. Dieses Merkmal dient der Kompatibilität mit BSD.

Der volle Text der Anmerkung ist in unklarem Deutsch verfasst. Ich nehme an, das "zuerst" interpretierst du so, dass gemeint ist: Bevor das Kommando "up route ..." ausgeführt werden kann, muss der angegebene Router erreichbar sein. Wenn diese Lesart zutrifft, müsste man wohl ein "sleep" oder Ähnliches vor dem Kommando "up route ..." in der /etc/network/interfaces ausführen. Geht das überhaupt? Ansonsten versteh' ich's nicht.

[BenutzerGa4gooPh]

Es funktioniert nicht! Es funktioniert dauerhaft nur, wenn ich die Route außerhalb von /etc/network/interfaces einrichte.

Tintom schrieb:

Vermutung: Das Ziel ist noch nicht erreichbar, weil hostapd zum Zeitpunkt der "up route..."-Anweisung noch nicht soweit ist ?!

Mal in /etc/network/interface ersetzen:

Code: Alles auswählen

up route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
down route del -net 192.168.1.0 netmask 255.255.255.0 dev wlan0

Mal in /etc/network/interfaces hinzufügen (unten/zuletzt):

Code: Alles auswählen

up service hostapd restart
evtl.
up service networking restart

funktioniert wohl noch mit und ohne systemd:

Code: Alles auswählen

up /etc/init.d/hostapd restart
evtl. 
up /etc/init.d/networking restart

Ohne "up" kann man im Terminal testen. Änderungen Schritt für Schritt, dass man weiß, woran es liegt.

[guennid]

Danke für die weitere Hilfe!

Ich kann erst heute abend weitermachen. Den Netzplan habe ich etwas korrrigiert.(1) Aus dem Netz 192.168.1.0 habe ich aus mehr oder weniger ästhetischen Gründen 192.168.102.0 gemacht. R3 hängt jetzt direkt am AP. Bei der Vergabe hoher IP-Zahlen für die Router (251) möchte ich bleiben. (Find ich eigentlich gar nicht so dumm, weil ich denke, dass es hilft, mögliche Konflikte zu vermeiden: Bisher gekaufte Plastikrouter nahmen defaultmäßig immer die kleinen Zahlen). Die Änderungen haben meiner Meinung nach keinen Einfluss auf das Routing-Problem. Wenn doch, sagt es mir.

(1) https://picload.org/view/ddlcaipa/guenn ... a.png.html

OT: Ich habe überhaupt nichts gegen "Krücken" - wenn sie hilfreich sind. Und nach meinen Erfahrungen waren die Skizzen, die ihr Urheber seinem Publikum nicht zu dessen Zufriedenheit erläutern konnte, eigentlich immer entweder fehlerhaft oder der Urheber hatte sie selbst nicht restlos verstanden (Nach meinem Dafürhalten: Powerpoint-Hype ).

Grüße, Günther

[guennid]

Vorschlag Jana, /etc/network/interfaces:

Code: Alles auswählen

up route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0

Routen:

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    0      0        0 eth1
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0

ping 192.168.100.151 auf 192.168.102.159 wird ins Internet geschickt und scheitert erwartungsgemäß

Janas Kommando im Terminal ohne "up"
Routen

Code: Alles auswählen

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.3.1     0.0.0.0         UG    0      0        0 eth1
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.102.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0

ping 192.168.100.151 auf 192.168.102.159

Code: Alles auswählen

~$ ping 192.168.102.159
PING 192.168.102.159 (192.168.102.159) 56(84) bytes of data.
From 192.168.100.251 icmp_seq=1 Destination Host Unreachable

Ich geb' s auf. Fehlermeldungen sehe ich keine und ich finde einfach keine Möglichkeit, die Route in /etc/network/interfaces unterzubringen und ich verliere auch bei diesem Hin und Her den Überblick. Mit (up) /etc/init.d/hostapd restart habe ich ebenfalls blind und erfolglos rumgespielt.
Außerhalb der /etc/network/interfaces funktioniert das routing ja mit den eingangs geposteten Eintragungen. Und dabei belasse ich es jetzt.

Grüße, Günther

[BenutzerGa4gooPh]

Janas Kommando im Terminal ohne "up"
Routen

Code: Alles auswählen

192.168.102.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0

Warum/wie ist diese Route hinzugekommen?

[TomL]

@Jana
Um von R2 die Maschine R3 zu erreichen ist auf dem Router 192.168.3.251 keine Route notwendig. Was definitiv funktionieren würde, ist ein Eintrag in der Fordward-Chain des Paketfilters und das Masquerading in der NAT-Tabelle. Aber das wird speziell hier nicht funktionieren, weil er hinter einem Router mit integriertem Paketfilter einen zweiten Router mit einem zusätzlichen und m.E. LAN-Technisch überflüssigen zweiten Paketfilter konfiguriert hat, der ihm hier den Traffic blockt bzw. nicht korrekt maskiert. Ich hatte von Anfang an den Verdacht, auch schon im anderen Thread, dass das fehlschlagen wird. Hostapd ist auf einem Standard-Debian eigentlich ne Fingerübung, die einfach funktioniert. Ich halte das hier nicht für (einfach) lösbar.... wenn überhaupt.

[guennid]

Aber das wird speziell hier nicht funktionieren, weil er hinter einem Router mit integriertem Paketfilter einen zweiten Router mit einem zusätzlichen und m.E. LAN-Technisch überflüssigen zweiten Paketfilter konfiguriert hat, der ihm hier den Traffic blockt bzw. nicht korrekt maskiert.

Ich vermute mit "Paketfilter meinst du meine "shorewall"? Die gibt's auf Router2 (192.168.101.110/192.168.102.110) nicht. Oder meinst du mit dem implizierten 1. Router den DSL-Router?
192.168.3.251 ist das gw zum DSL-Router.

Im übrigen weiß ich nicht, was du mit "nicht funktionieren" meinst. Das System funktioniert - was nicht funktioniert, ist routing mit /etc/network/interfaces. Sollte dich eigentlich freuen.

Warum/wie ist diese Route hinzugekommen?

Im meinem Laienverstand vermute ich mal, weil das routing via konsole funktioniert, nur nicht mit /etc/network/interfaces.

Grüße, Günther

[BenutzerGa4gooPh]

m von R2 die Maschine R3 zu erreichen ist auf dem Router 192.168.3.251 keine Route notwendig.

Das ist richtig, direct connected, also dem Router bekannt. Um's Routing haben sich im Thread Leute vor mir schon einen Kopf gemacht, ich bin erst bei der Persistenz der Routen eingestiegen.

Ich vermute mit "Paketfilter meinst du meine "shorewall"?

Laut Skizze Router1 mit hostapd und shorewall. Letztere könntest du mal abschalten. Zumindest nehme ich stark an, dass das neue WLAN-Interface in eine Zone integriert werden muss. Entweder in eine vorhandene oder in eine neue Zone, deren erlaubter Traffic zu den anderen Zonen konfiguriert werden muss. Kann es sein, dass shorewall die (alleinige) Verwaltung der etc/network/interfaces übernimmt?

Eine Firewall nimmt man in Betrieb, wenn alle Dienste funktionieren. Zumindest im privaten LAN, dass durch NAT-Plastikrouter geschützt ist.

[guennid]

Laut Skizze Router1 mit hostapd und shorewall. Letztere könntest du mal abschalten.

Letzteres führt zu neuer Baustelle,schon erfolglos probiert, siehe Thread "hostapd einrichten".
Das device wlan0 war und ist für die Zone loc zusätzlich zu eth0 in /etc/shorewall/interfaces eingetragen, siehe a.a.O.

Code: Alles auswählen

net     eth1            detect          tcpflags,nosmurfs,routefilter,logmartians
loc     eth0            detect          routeback,tcpflags,nosmurfs,routefilter,logmartians
loc     wlan0           detect          routeback,tcpflags,nosmurfs,routefilter,logmartians

Eine Firewall nimmt man in Betrieb, wenn alle Dienste funktionieren. Zumindest im privaten LAN, dass durch NAT-Plastikrouter geschützt ist.

Für eine Neueinrichtung stimmt das wohl so, aber hier ging's um die Änderung eines seit Jahren laufenden Systems. Und dass die Firewall ein Störfaktor sein könnte, hatte ich bedacht, deswegen auch der (fehlgeschlagene) Versuch, sie abzuschalten.

[BenutzerGa4gooPh]

Na, dass du die Interfaces den "Allierten Besatzungszonen" zugeordnet hast, ist schon mal gut. Mit Shorewall hast erst du mich flüchtig bekannt gemacht. Helfen kann ich wegen "Flüchtigkeit" nicht weiter.

Letzter Rat: Mir wäre das Netzwerk für 5 Rechner zu kompliziert, würde ich neu planen, so als Überlegungen:
- Die beiden Switches per Kabel verbinden - möglich? Router 2 fällt weg. Bei Bedarf Accesspoint an jeden Switch. WLAN-Billigrouter mit 4 Ports im AP-/Bridge-Modus könnte wohl Switch ersetzen?!
- Router1 (EEE-PC?) mit IPFire oder OPNSense. IPv6 brauchst du nicht und PFSense will neuerdings zwingend AES-NI , was der EEE-PC wohl nicht kann. Auf Router 1 würde mein Augenklimpern oder Augenmerk liegen.
- pro Etage einen (relativ dummen) Accesspoint (oder Billig-Plastikrouter mit 4-Port-Switch im entsprechenden Modus), eventuell Powerline/dlan mit integriertem WLAN-AP?
- bei fehlendem Kabel z. B.: 2 x https://www.amazon.de/Powerline-gleichz ... =dlan+wifi
(Im Allgemeinen wird für die Router-Firewall-Distributionen (IPFire, PFSense, OPNSense) davon abgeraten, WLAN auf dem gleichen Rechner laufen zu lassen. Es geht mehr schlecht als recht - aber nur mit wenigen WLAN-Adaptern. IPFire wegen modernerem Linux vs. _BSD kann da wohl mehr.)

Mein Netz (Eigenheim, 2 Etagen):
Providerrouter
|
NAT / Netzwerkkabel
|
eigener Router nur mit LAN-Ports ohne WLAN (wechselt ab und an, war mal PFSense auf X86_amd64-Hardware (Intel J1900), derzeit Cisco aus Bucht, künftig weiß Frau nicht , wahrscheinlich Cisco + Debian-Miniserver (Intel-NUC) für bind9 oder unbound mit DNSSEC. Plus PiHole als Blocker. Zumindest PFSense kann alles (künftig nur mit AES-NI), von OPNSense nehme ich an, das andere/ältere Technik unterstützt wird.
|
Netzwerkkabel
|
Powerline->WLAN-Adapter für Obergeschoss ) mit 2 LAN-Ports
|
230V-Netz
|
Powerline->WLAN-Adapter für Untergeschoss ) mit 2 LAN-Ports
(Ähnlich Amazon-Link oben, habe selber dlan-Pro-Serie mit VLANs, 2 "Ergänzungsadapter" mit WLAN, VLANs braucht Frau für Gastnetz mit Androiden. Pro-Serie gibt's woanders billiger: https://geizhals.de/devolo-dlan-pro-120 ... 98747.html )

Jedenfalls sämtliche Netzwerkdienste (DNS, DHCP) und Firewall zentral in einem/meinem Router.

Edit: Sorry, Günther, nach nochmaligem Durchlesen ist die unausgelastete Planerin wohl mit mir "durchgegangen".

OT:

Nach meinem Dafürhalten: Powerpoint-Hype

Schon lange bemerkt. Neuerdings gibt es "Fachwissen" auf Youtube. Gemeinsamkeiten? Jedenfalls BILDe ich mich so nicht weiter.

[guennid]

Letzter Rat: Mir wäre das Netzwerk für 5 Rechner zu kompliziert, würde ich neu planen.

Was neu planen angeht, ist da nicht viel möglich/scheue ich den Aufwand. Einzig powerline-Adapter wären mir symphatisch. Aber das hatte ich ursprünglich - vor zig Jahren, und da spielte 1. der damalige Fernseher nicht mit (störte das Netz gewaltig, obwohl physikalisch ausgeschaltet, allein durch sein Vorhandensein im Stromnetz), 2. damals mäßige Geschwindigkeit. Ob die Dinger heute mehr können? Keine Ahnung. Im übrigen habe ich es ja bis jetzt immer noch hingekriegt. Solange nicht doch noch jemand eine schlaue Idee hat, was die /etc/network/interfaces-Konfiguration konkret behindert, betrachte ich das Routing-Problem als erledigt.

Angesichts der mäßigen Signalstärke der Onboard-NIC überlege ich die Anschaffung einer USB-WLAN-NIC für Router1: TP-LINK-WN822N, aber das ist eine neues Thema (1).

(1) viewtopic.php?f=30&t=168235

Grüße, Günther