Host und Jails in unterschiedlichen Subnetzen

dagnu

Well-Known Member
Hallo,

mich stören seit einer Weile arplookup Syslog-Meldungen der Art:
Code:
Oct 11 15:44:19 server kernel: arplookup 213.133.127.33 failed: host is not on local network

Diese beruhen auf der derzeitigen Konfiguration, nur leider ist
mir auch nach längerer Suche und einer Menge Jail Literatur
immer noch nicht ganz klar wie ich das ändern kann.

Folgende Situation beim Provider Hetzner:

Host: IP 85.*.*.14/27, Router 85.*.*.1
Jails: IPs 213.*.*.34 bis 213.*.*.38, 29'er Subnetz, Router 213.*.*.33

Konfiguriert hatte ich damals folgendes:
Code:
defaultrouter="85.*.*.1"
ifconfig_vr0="inet 85.*.*.14 netmask 255.255.255.224"
ifconfig_vr0_alias0="inet 213.*.*.34/32"
ifconfig_vr0_alias1="inet 213.*.*.35/32"
ifconfig_vr0_alias2="inet 213.*.*.36/32"
ifconfig_vr0_alias3="inet 213.*.*.37/32"
ifconfig_vr0_alias4="inet 213.*.*.38/32"

Da sich bei dieser Konfiguration der vorgesehene Router
213.*.*.33 in keinem der Netzwerke befindet ist ein arplookup
nicht möglich.

Wie kann ich den Host und die Jails so konfigurieren, dass sie
unabhängig von einander in unterschiedlichen Subnetzen
mit zwei Standardroutern arbeiten?

Danke, dagnu
 
Code:
defaultrouter="85.*.*.1"
ifconfig_vr0="inet 85.*.*.14 netmask 255.255.255.224"
ifconfig_vr0_alias0="inet 213.*.*.34/32"
ifconfig_vr0_alias1="inet 213.*.*.35/32"
ifconfig_vr0_alias2="inet 213.*.*.36/32"
ifconfig_vr0_alias3="inet 213.*.*.37/32"
ifconfig_vr0_alias4="inet 213.*.*.38/32"
Änder das einfach in
Code:
defaultrouter="85.*.*.1"
ifconfig_vr0="inet 85.*.*.14 netmask 0xffffffe0"
ifconfig_vr0_alias0="inet 213.*.*.34 netmask 0xfffff8"
ifconfig_vr0_alias1="inet 213.*.*.35 netmask 0xfffff8"
ifconfig_vr0_alias2="inet 213.*.*.36 netmask 0xfffff8"
ifconfig_vr0_alias3="inet 213.*.*.37 netmask 0xfffff8"
ifconfig_vr0_alias4="inet 213.*.*.38 netmask 0xfffff8"
und schon hast du keine arplookup Probleme mehr.

Deine Routingtabelle sollte dann folgende Einträge haben:
Code:
85.*.*.*/27     link#1             UC          0        0    vr0
213.*.*.32/29   link#1             UC          0        0    vr0

Jetzt landet allerdings eventuell ein Broadcast einer Jail in einer anderen, ja. Wenn das ein Problem ist, dann musst die Jails auf lo0 legen und redirect spielen.

Wie FreeBSD auf ein
Code:
route add -net 213.*.*.34 213.*.*.33
reagiert bin ich mir gerade gar nicht sicher. Gateway ausserhalb des Subnetzes klingt aber fishy. Dein aktuelles Setup dürfte vmtl nur funktionieren, weil die beiden Gateway IPs eh der gleiche Port sind, und daher passend ankommen.
 
Danke für die Antwort.

Die Umstellung der Jails auf die /29 Maske hatte ich bisher nicht
gemacht, da ich keine Testmaschine habe und ich mir nicht sicher
war ob das so geht - werde ich dann im nächsten Wartungsintervall
mal probieren - vorallem kann ich dann endlich den defaultrouter
in den Jails entsprechend setzen.

Das die aktuelle Konfiguration überhaupt funktioniert liegt sicherlich
daran, dass der Router für beider Netze der selbe ist, da stimme ich
Dir zu. Bzgl. Jails auf lo0 in einem privaten Netz habe ich leider noch
keine Erfahrungen, dann müsste ich alle Dienste auf der jeweils
internen IP laufen lassen und mit ipfw den ganzen Traffic natten, oder?
Um den Traffic zwischen den Jails zu unterbinden (eventuelle Broadcasts)
reicht doch aber eigentlich auch eine Firewall auf dem Host.
 
Jo, das wird alles ziemlich schnell sehr wild.

Ich hab 10.0.0.0/24 (nicht /32 wie ich gerade sehe, kA warum) Aliase auf lo0, darauf dann die Jails und darin die meisten Sachen. Anfragen werden über rdr Zeilen in der pf.conf dann passend verteilt. Geht mit ipfw und IPFIREWALL_FORWARD sicher auch.

Gibt da aber ettliche Fußangeln. ftp stresst wie immer rum, selbst wenn pftpx installiert is, ganz koscher lief das trotzdem nicht. Ohne enc(4) das erst mit 6.2 in releng_6 einzieht kann man nix was über IPSEC reinkommt weiterleiten - hat man Transport-Mode IPSec zwischen seinen DNS Servern is da dann schonmal Essig mit einsperren. Usw.
 
nicht das schönste, aber wenn sonst alles läuft, einfach das Logging der arp Fehler abstellen:

sudo sysctl net.link.ether.inet.log_arp_wrong_iface=0
 
Das tolle daran ist, dass das bei dem Fehler um den es geht (arplookup funktioniert nicht) exakt gar nichts hilft.

Das schaltet nämlich nur diese Art Fehlermeldungen ab:
Code:
arp: 172.16.23.25 is on fxp0 but got reply from 00:00:f8:76:34:54 on fxp1
 
Zuletzt bearbeitet:
Hi Leute,

hatte genau das gleiche Problem. Nach den von Elessar bereits angemerkten Änderungen läuft es jetzt aber seit geraumer Zeit einwandfrei. Das einzige, was mir etwas unklar ist, ist die Tatsache, dass die Aliases über die neue Notation in der rc.conf nicht ALLE mit der angegebenen Netzmaske versehen werden. Bsp:
Code:
ipv4_addrs_vr0="87.17.221.194/27 81.19.247.178-182/29"
inder rc.conf ergibt folgende IPs
Code:
inet 87.17.221.197 netmask 0xffffffe0 broadcast 87.17.221.223
inet 81.19.247.178 netmask 0xfffffff8 broadcast 81.19.247.183
inet 81.19.247.179 netmask 0xffffffff broadcast 81.19.247.179
inet 81.19.247.180 netmask 0xffffffff broadcast 81.19.247.180
inet 81.19.247.181 netmask 0xffffffff broadcast 81.19.247.181
inet 81.19.247.182 netmask 0xffffffff broadcast 81.19.247.182
Hab ich da einen Fehler in meiner Syntax oder will man sich damit RFC-konform halten?

Gruß,

Ice
 
rc.conf(5) schrieb:
One can configure more than one IPv4 address with the ipv4_addrs_<interface> variable. One or more IP addresses must be provided in Classless Inter-Domain Routing (CIDR) address notation, whose last byte can be a range like 192.168.0.5-23/24. In this case the address 192.168.0.5 will be configured with the netmask /24 and the addresses 192.168.0.6 to 192.168.0.23 with the non-conflicting netmask /32 as explained in the ifconfig(8) alias section.
Glückwunsch! Wenn das bei dir so fehlerlos klappt, dann hast du vmtl gerade die richtige Konfigurationsoption gefunden :)
 
Zuletzt bearbeitet:
Ahh, die Passage hatte ich mal wieder geflissentlich überlesen. Macht aber ja laut RFC auch wirklich Sinn.
Naja, da fand das berühmte Huhn halt doch mal wieder ein Korn.......... ;-)

Gruß,

Ice
 
Die Konfiguration von Ice scheint ja so zu funktionieren - so hatte ich mir das auch
gedacht, da die zweite Routeradresse sich so in einem bekannten und erreichbarem
Subnetz befindet. Allerdings vermute ich mal, dass die vier Jails im /32 Netz
über die Routeradresse des Hosts kommunizieren, was eigentlich immer noch
ein wenig unsauber scheint - Fast unglaublich finde ich mittlerweile, das es dafür
anscheinend keine wirklich einfache Lösung gibt. Das sauberste ist wohl wirklich
ein privates Netz auf lo0.

Die Notation "ipv4_addrs_*" kannte ich noch gar nicht - seit wann gibt's die? In 6.0
anscheinend noch nicht - wird wohl Zeit für ein Update.
 
Die Notation "ipv4_addrs_*" kannte ich noch gar nicht - seit wann gibt's die? In 6.0
anscheinend noch nicht - wird wohl Zeit für ein Update.

Jo, die gibt's erst in 6.1.

Nachtrag:
Meine Terminangabe bezueglich des Releases war falsch. Es handelte sich dabei, um die Angaben auf freebsd.org. Jedoch haben sich die ganzen Termine ein wenig nach hinten verschoben. Wie elessar im naechsten Beitrag sagt, ohne ReleaseCandidate wird es kein Release geben. Zumindest war das bisher so.
 
Zuletzt bearbeitet:
@dagnu: die saubere Lösung ist eine eigene Routingtabelle für jedes lokal verwendete Subnetz (mit jeweils eigenem Gateway). Das geht in FreeBSD aber noch nicht, und das Problem hat man immer, wenn ein Device Adressen aus mehr als einem Subnetz hat - dazu braucht es keine Jails.

@cnopers: genau, ein FreeBSD das ohne RC direkt von BETA zu RELEASE hypft. Sehr wahrscheinlich.
 
Das tolle daran ist, dass das bei dem Fehler um den es geht (arplookup funktioniert nicht) exakt gar nichts hilft.

Das schaltet nämlich nur diese Art Fehlermeldungen ab:
Code:
arp: 172.16.23.25 is on fxp0 but got reply from 00:00:f8:76:34:54 on fxp1

Stimmt! Aber toll ist das dann in diesem Zusammenhang ja nicht gerade - da hbe ich wohl ein paar fehlermeldungen durcheinander geworfen :rolleyes:
 
Zurück
Oben