"Zwischenrouter"

[syssi]

Ach ich seh gerade. In der Shorewall-Config steht /16. Das entspricht einer Netmask von 255.255.0.0 und reicht fuer deine Zwecke aus. Du musst also nichts aendern. Es sollte nun alles funktionieren, wenn du fuer 1er IPs die 192.168.1.1 als Standard-Gateway nutzt.

[guennid]

So, es scheint zu funktionieren. Da ich auch noch squid auf dem Router betreibe (und dnsmasq), ohne dass ich nach mehrmonatiger Nichtbeschäftigung damit noch wüsste, was ich da eigentlich tue - komme ich aus dem 1er Netz nicht nur ins 100er Netz (ja, ich geb's zu, ich war zu faul, das in meinem "Gemälde" korrekt anzugeben) und umgekehrt; sondern, nachdem ich diesen Eintrag in /etc/squid/squid.conf:

Code: Alles auswählen

acl localnet src 192.168.100.0/24	# RFC1918 possible internal network

ersetzt hatte durch

Code: Alles auswählen

acl localnet src 192.168.100.0/16	# RFC1918 possible internal network

funktionierte auch die Internet-Anbindung aus dem 1er Netz heraus. Das schmeckt mir nicht mit dem "/16" (war'n default von shorewall) aber vielleicht kommen wir später noch mal darauf zurück.

Was ich noch nicht verstehe ist, dass ich von einem Klienten aus dem 100er Netz aus alles Mögliche im 1er Netz anpingen und mich sogar mit ssh verbinden kann, außer einem ping auf 192.168.1.1, also der Ethernet-Nic des Druckservers.

Code: Alles auswählen

@buch3:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.100.251: icmp_seq=1 Redirect Host(New nexthop: 192.168.100.110)
From 192.168.100.92: icmp_seq=1 Redirect Host(New nexthop: 192.168.100.251)
From 192.168.100.251 icmp_seq=1 Time to live exceeded

[syssi]

Wer ist denn die 100.92? Buch3?

Anstatt das Netz per /16 aufzubohren koenntest du auch einfach zwei Regeln definieren fuer jeweils ein kleines /24 Netz.

Code: Alles auswählen

# /etc/shorewall/masq
ppp0                    192.168.100.0/24
ppp0                    192.168.1.0/24

Obiges ist nur geraten. Ich weiss nicht, ob Shorewall alle Zeilen der Datei entsprechend interpretieren kann. Squid:

Code: Alles auswählen

acl localnet src 192.168.100.0/24
acl localnet src 192.168.1.0/24

Zum Vergleich: Ich habe zwei Netzwerke per VPN verbunden. Die Konfiguration ist deiner recht aehnlich. Der Druckserver ist in meinem Fall ein VPN-Server. Ich pinge von einer Maschine aus dem 178er Netz:

Code: Alles auswählen

$ ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.178.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.178.10)
64 bytes from 192.168.1.100: icmp_req=1 ttl=64 time=56.0 ms
64 bytes from 192.168.1.100: icmp_req=2 ttl=64 time=51.9 ms

Man sieht: Die Pakete streifen die Fritzbox, diese wirft sie zurueck zum VPN-Gateway dort kommen sie dann irgendwann beim Ziel an. Deine Ausgabe sieht im Vergleich ein wenig kurious aus.

[guennid]

Also, irgendwo ist da noch der Wurm drin.

192.168.100.92 ist der Repeater

Wenn ich aus dem 100er Netz ins 1er Netz pingen will, kommt das hier:

Code: Alles auswählen

~$ ping 192.168.1.154
PING 192.168.1.154 (192.168.1.154) 56(84) bytes of data.
From 192.168.100.251: icmp_seq=1 Redirect Host(New nexthop: 192.168.100.110)
From 192.168.100.92: icmp_seq=1 Redirect Host(New nexthop: 192.168.100.251)
From 192.168.100.251 icmp_seq=1 Time to live exceeded
[...]
--- 192.168.1.154 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3011ms

Also, wenn ich recht verstehe, landet der ping zunächst beim Router (100.251). Von da geht's zum Repeater (100.92). Soweit in Ordnung. Aber warum der jetzt wieder den Router kontaktiert, statt weiterzuleiten an den Druckserver (100.110) verstehe ich nicht.

Grüße, Günther

[syssi]

Ich verstehe garnicht wieso der Repeater etwas im Verkehr verloren hat. Normalerweise sind diese Dinger transparent. Von welchem Hersteller ist er und um was genau handelt es sich da? Ggf. muss man dem Geraet beibringen, dass das Netzwerk nun groesser ist und nicht mehr nur das 100er Netz umfasst.

[guennid]

das ist ein noname-Gerät. Hängt einfach an der Steckdose, verfügt aber über web-gui zur Administration. Ich habe mir die config schon angeschaut. Ich habe bei der Einrichtung ein "Default-"Gateway eingetragen:100.251. Wie man dem beibingen kann, dass es jetzt auch ein 1er Netz gibt, dazu habe ich noch keine Option gefunden. Interessanter erscheint mir die Frage, warum er nicht weiß, dass er an 100.110 weiterreichen muss, denn zumindest die IP sollte er kennen.

Aus dem 1er Netz funktioniert übrigens jeder ping. Auch IN-Anbindung klappt. (Die Stromnetz-Verbindung habe ich übrigens gekappt, die ist eh so gut wie überflüssig).

[syssi]

Kannst du das Default-Gateway aus diesem Geraet entfernen und/oder die Netmask auf 255.255.0.0 aufweiten?

[guennid]

Geht wohl beides. Was ist dir denn lieber?

Da es für mich alten Mann schon recht spät ist und ich heute nicht mehr mit einer Antwort rechne, probier ich erst mal die netmask.

[syssi]

Die Netmask reicht grundsaetzlich.

[guennid]

Will er aber nicht. Und der Entzug des Routers schmeckt ihm genauso wenig.

[syssi]

Was kann ein Geraet an einer groesseren Netmask nicht wollen? Was genau meinst du damit?

[guennid]

Ich kann nach wie vor nicht aus 100 nach 1 pingen.

[syssi]

Sicher, dass die Netmask akzeptiert und gesetzt wurde? Repeater einmal neu gestartet? Es gibt keinen Grund, dass der Repeater sich in die Kommunikation einklinkt, wenn die Netmask auf 255.255.0.0 steht.

[guennid]

Repeater einmal neu gestartet?

Nicht nur einmal. Ich denke, es reicht. Ich probier jetzt die bridging-Methode.

Grüße, Günther

[syssi]

Als Arbeitserleichterung:

Code: Alles auswählen

# /etc/network/interfaces

allow-br0 eth0
iface eth0 inet manual

allow-br0 wlan0
iface wlan0 inet manual
# ... hier fehlen noch ein paar Einstellungen: WPA, SSID, etc.

auto br0
iface br0 inet static
address 192.168.100.110
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
gateway 192.168.100.251
bridge_ports eth0 wlan0
pre-up ifup --allow "$IFACE" wlan0
pre-up ifup --allow "$IFACE" eth0
post-down ifdown --allow "$IFACE" eth0
post-down ifdown --allow "$IFACE" wlan0

Bei den letzten 4 Zeilen bin ich mir nicht hundertprozentig sicher.

[guennid]

Ein großes Dankeschön für deine große Geduld!

Ich war zwischenzeitlich auch nicht untätig, aber was man so zu lesen bekommt, ist leider häufig mehr verwirrend als erhellend.

Du bist dir dahingehend sicher, dass die beiden realen Karten (eth0 und wlan1 bei mir) keine IPs, netmask, usw bekommen? Und die wlan-NIC lediglich den WPA-Kram? Alles andere wird nur für die Brücke konfiguriert? Frag mich nicht warum wlan1, das hat udev veranstaltet, weil ich vor Zeiten mal mal eine andere PCMCIA-WLAN-NIC testweise auf dem Druckserver verwendet habe. Und bevor ich mir eine weitere Fehlerquelle zurecht fummele, belass' ich es lieber mal bei den udev-Vorgaben.

Grüße, Günther

[syssi]

Ja, das ist quasi der Trick. Man schnuert zwei Geraete IP-seitig "unkonfiguriert" zusammen und gibt dieser Bruecke die IP-Konfiguration.

[guennid]

Erstmal Kern neu kompilieren:

Code: Alles auswählen

CONFIG_Bridge is not set

[guennid]

Den Kern habe ich kompiliert, aber es funktioniert genausowenig reibungslos, wie vorher die Versuche mit den zwei Netzen. Bedauerlicherweise scheint es keine ultimative Anleitung zu geben, weder für eine Konfiguration von zwei Netzen, noch für das Bridging mit eth/wlan, vor allem nicht in Deutsch.
Ich bin jetzt wieder zurück zu den zwei Netzen. Also von vorn. Kein DHCP.

Auf dem Shorewall-Router steht jetzt das in der /etc/network/interfaces:

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet static
        address 192.168.100.251
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        up route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.100.110 dev eth0


auto dsl-provider
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth1 up # line maintained by pppoeconf
provider dsl-provider

auto eth1
iface eth1 inet manual

Auf dem "Druckserver", der zwischen 192.168.100. und 192.168.1 vermitteln soll, steht jetzt das in /etc/network/interfaces:

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet static
        address 192.168.1.110
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        up route add -net 192.168.100.0 netmask 255.255.255.0 dev wlan1

allow hotplug wlan1
iface wlan1 inet static
        address 192.168.100.110
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        gateway 192.168.100.251
        up route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
        dns-nameservers 192.168.100.251
        dns-search diddi
        wpa-driver wext
        wpa-ssid "Verstaerker"
        wpa-proto RSN
        wpa-psk "Peter Snowden"

1. Versuch: ping von 192.168.100.151 nach 192.168.1.154:

Code: Alles auswählen

~$ ping 192.168.1.154
PING 192.168.1.154 (192.168.1.154) 56(84) bytes of data.
From 192.168.100.251: icmp_seq=1 Redirect Host(New nexthop: 192.168.100.110)
From 192.168.100.92: icmp_seq=1 Redirect Host(New nexthop: 192.168.100.251)
From 192.168.100.92 icmp_seq=1 Time to live exceeded
...
^C
--- 192.168.1.154 ping statistics ---
7 packets transmitted, 0 received, +7 errors, 100% packet loss, time 6038ms

2. Versuch: ping von 192.168.1.154 nach 192.168.100.151:

Code: Alles auswählen

$ ping 192.168.100.151
PING 192.168.100.151 (192.168.100.151) 56(84) bytes of data.
64 bytes from 192.168.100.151: icmp_req=1 ttl=63 time=2.82 ms
64 bytes from 192.168.100.151: icmp_req=2 ttl=63 time=2.23 ms
64 bytes from 192.168.100.151: icmp_req=3 ttl=63 time=3.78 ms
64 bytes from 192.168.100.151: icmp_req=4 ttl=63 time=2.42 ms
^C
--- 192.168.100.151 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 2.236/2.818/3.787/0.599 ms

3. Versuch (wie 1. Versuch, also ping von 192.168.100.151 nach 192.168.1.154):

Code: Alles auswählen

# ping 192.168.1.154
PING 192.168.1.154 (192.168.1.154) 56(84) bytes of data.
64 bytes from 192.168.1.154: icmp_req=1 ttl=63 time=2.38 ms
64 bytes from 192.168.1.154: icmp_req=2 ttl=63 time=4.31 ms
64 bytes from 192.168.1.154: icmp_req=3 ttl=63 time=2.17 ms
^C
--- 192.168.1.154 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2013ms
rtt min/avg/max/mdev = 2.175/2.960/4.319/0.964 ms

Zwei Stunden später war's wieder Essig mit 'nem ping von 192.168.100.151 nach 192.168.1.154
Erst nachdem ich umgekehrt gepingt hatte, ging das wieder. Leute, ich bin kein ITler und ich blick hier absolut nicht durch.

Grüße, Günther

[edit:]

Irgendwie ist das abenteuerlich: Wenn 192.168.100.151 die route ins 1er Netz verloren hat, kann ich mich von diesem Rechner aus per ssh zunächst auf dem "Druckserver" (19.168.100.110) einloggen, von da weiter auf den Rechner mit der singulären Ethernet-NIC 192.168.1.154, dort einen ping auf 192.168.100.151 durchführen (also den Rechner, vor dem ich sitze) und kann dann anschließend wunderbar von 192.168.100.151 nach 192.168.1.154 pingen.?

[syssi]

Es traegt nicht zur Problemloesung bei aber die beiden statischen Routen ("up"-Zeilen in der interfaces) auf dem Druckserver sind nicht notwendig. Diese sind zwar korrekt werden aber automatisch vom System erstellt, an Anhand der Geraetekonfiguration. In anderen Worten: Wenn du einem Geraet eine IP und eine Netmask gibst, dann weiss dein System automatisch, dass es dieses Netzwerk auf einem Netzwerkgeraet geben muss und legt die Route an.

Das es manchmal funktioniert und manchmal nicht hoert sich nach ARP-Caches an.

Ah, dann habe ich doch noch eine Idee: Dein Repeater funkt ja dazwischen, weil er ein solches Verhalten an den Tag legt: "Oh, ein Paket fuer ein fremdes Netzwerk (192.168.1 != 192.168.100) - also Default-Gateway nutzen!" Und wirft darauf das Paket zurueck gegen dein Internet-Gateway. Es waere also sehr praktisch, wenn es im Konfigurations-Interfaces deines Repeaters ebenfalls die Moeglichkeit gibt statische Routen zu setzen. Dort wuerdest du dann definieren: Das Netzwerk 192.168.1.1 befindet sich hinter dem Druckserver. Daraufhin sollte die "Ich werfe alles fremde gegen das Default-Gateway"-Regel nicht mehr greifen.

[guennid]

Ich habe die statischen Routen vom "Druckserver" entfernt. Die Phänomene sind die gleichen. Ich kann mich hinterrücks in 192.168.1.154 reinschleichen und anschließend diesen Rechner normal von 192.168.100.* aus erreichen.

Es waere also sehr praktisch, wenn es im Konfigurations-Interfaces deines Repeaters ebenfalls die Moeglichkeit gibt, statische Routen zu setzen.

Leider nein, jedenfalls habe ich nichts gefunden.

Grüße, Günther

[syssi]

Schade, dann habe ich keine Idee mehr, wie man dem Repeater Benehmen beibringen koennte.

[dufty]

Man kann sich des Eindrucks nicht erwehren, dass hier auf "Biegen und Brechen" versucht wird,
aus einem "repeater" einen router zu zimmern

Warum kann Dein kernel kein bridging? Ist das nicht der default (bei debian):
CONFIG_BRIDGE=m
CONFIG_BRIDGE_NETFILTER=y
?

[guennid]

Man kann sich des Eindrucks nicht erwehren, dass hier auf "Biegen und Brechen" versucht wird,
aus einem "repeater" einen router zu zimmern

Ich schätze definitv, dass der Eindruck täuscht! Aber der thread ist auch schon ziemlich lang.

Wir versuchen einen stinknormalen Debian-Rechner (hier "Druckserver" genannt, weil er ursprünglich lediglich dafür bestimmt war) als "Zwischenrouter" zu konfigurieren.

Die beiden Module für's bridging sind vohanden und aktiv. Es gibt leider keine eindeutige - deutsche - Beschreibung im Netz, wie dieses bridging mit debian, eth und wlan zu realisieren wäre, insbesondere die Einrichtung der interfaces wird ziemlich disaparat dargestellt. Aber das nur am Rande.
Grüße, Günther

[syssi]

Man kann sich des Eindrucks nicht erwehren, dass hier auf "Biegen und Brechen" versucht wird,
aus einem "repeater" einen router zu zimmern

Sollte ein Repeater nicht transparent sein und wenn nicht, wieso kann er ein 24er Netz repeaten aber kein 16er? Er macht seine Aufgabe also nicht gut.