TL;DR – Ich möchte eine FreeBSD-VM mit einer Netzwerkkarte in meinem Heim-LAN (192.168.1.0/24) und einer in einem privaten, internen Netzwerk zur Virtualbox (10.9.9.0/24) einrichten und den gesamten Datenverkehr zwischen den beiden hin und her leiten.
Bin schon seit langem Linux-Benutzer (Debian auf Servern), verwende FreeBSD aber erst seit etwa einem Tag :)
Wie auch immer, für meine Experimente habe ich eine Virtualbox-Maschine mit 2 Netzwerkschnittstellen - eine ist mit meinem Heim-LAN verbunden, eine mit einem rein internen Netzwerk. Diese Maschine ist als Block-Nothing-Router eingerichtet, der Pakete einfach zwischen eth0 und eth1 weiterleitet, unabhängig von Quelle und Ziel. Das geht ganz einfach mit iptables -
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
Aber ich habe versucht, dies mit pf zum Laufen zu bringen, und hatte nur teilweisen Erfolg.
Mit
gateway_enable="YES"
pf_enable="YES"
pf_rules="/etc/pf.conf"
in meinem /etc/rc.confund /etc/pf.confenthält
pass from em1:network to any keep state
pass from em0:network to any keep state
pass in inet proto tcp to any keep state
pass in inet proto udp to any keep state
pass out inet proto tcp to any keep state
pass out inet proto udp to any keep state
Ich kann eine Live-Disk-VM starten, die nur intern angeschlossen ist, und die IP von em1 als Standard-Gateway festlegen und em1 und em0 anpingen, aber ich kann weder den Host-Rechner anpingen, auf dem vbox läuft, noch irgendeinen anderen Rechner in meinem LAN, und auch keine Verbindung über http, ssh usw. herstellen.
[root@bsdtest ~]# pfctl -sa
FILTER RULES:
pass in inet proto tcp all flags S/SA keep state
pass in inet proto udp all keep state
pass out inet proto tcp all flags S/SA keep state
pass out inet proto udp all keep state
pass inet from 10.9.9.0/24 to any flags S/SA keep state
pass inet from 192.168.1.0/24 to any flags S/SA keep state
STATES:
all tcp 192.168.1.90:22 <- 192.168.1.10:48102 ESTABLISHED:ESTABLISHED
all udp 192.168.1.2:53 <- 10.9.9.5:59075 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:59075 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:34207 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:34207 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:43515 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:43515 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:1636 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:1636 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:60124 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:60124 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:8866 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:8866 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:25534 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:25534 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
all udp 192.168.1.2:53 <- 10.9.9.5:30141 NO_TRAFFIC:SINGLE
all udp 10.9.9.5:30141 -> 192.168.1.2:53 SINGLE:NO_TRAFFIC
INFO:
Status: Enabled for 0 days 00:08:28 Debug: Urgent
State Table Total Rate
current entries 17
searches 1990 3.9/s
inserts 253 0.5/s
removals 236 0.5/s
Counters
match 253 0.5/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 0 0.0/s
proto-cksum 0 0.0/s
state-mismatch 0 0.0/s
state-insert 0 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 0 0.0/s
map-failed 0 0.0/s
TIMEOUTS:
tcp.first 120s
tcp.opening 30s
tcp.established 86400s
tcp.closing 900s
tcp.finwait 45s
tcp.closed 90s
tcp.tsdiff 30s
udp.first 60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 30s
interval 10s
adaptive.start 6000 states
adaptive.end 12000 states
src.track 0s
LIMITS:
states hard limit 10000
src-nodes hard limit 10000
frags hard limit 5000
table-entries hard limit 200000
OS FINGERPRINTS:
758 fingerprints loaded
[root@bsdtest ~]#
Irgendwelche Ideen? Die Zeilen bezüglich des UDP-Verkehrs zu 192.168.1.2 von 10.9.9.5 (meiner Live-Disk) wären für DNS zu meinem Heim-LAN-Nameserver, aber es kommen nie Antworten an... Hier ist, was eine HTTP-Anfrage zeigt -
[root@bsdtest ~]# pfctl -sa | grep 80
all tcp 192.168.1.10:80 <- 10.9.9.5:59436 CLOSED:SYN_SENT
all tcp 10.9.9.5:59436 -> 192.168.1.10:80 SYN_SENT:CLOSED
all tcp 192.168.1.10:80 <- 10.9.9.5:59438 CLOSED:SYN_SENT
all tcp 10.9.9.5:59438 -> 192.168.1.10:80 SYN_SENT:CLOSED
Ideen?
Antwort1
OK, Lösung gefunden.
Meine /etc/rc.conf ist in Ordnung, so wie sie ist ...
Die Datei /etc/pf.conf muss
# cat /etc/pf.conf
ext_if="em0"
int_if="em1"
boxnet = $int_if:network
homenet = $ext_if:network
nat on $ext_if from $boxnet to any -> ($ext_if)
pass quick from { lo0, $boxnet, $homenet } to any keep state
Wahrscheinlich viel zu viele Variablen, ich könnte einfach die ursprünglichen em0/em1 verwenden. Wie auch immer, das gibt Ihnen -
[root@bsdtest ~]# pfctl -vnf /etc/pf.conf
ext_if = "em0"
int_if = "em1"
icmp_types = "echoreq"
boxnet = "em1:network"
homenet = "em0:network"
nat on em0:network inet from 10.9.9.0/24 to any -> 192.168.1.0/24
nat on em1:network inet from 192.168.1.0/24 to any -> 10.9.9.0/24
pass quick inet from 127.0.0.0/8 to any flags S/SA keep state
pass quick inet from 192.168.1.0/24 to any flags S/SA keep state
Antwort2
Nachfolgend einige Vermutungen, also Vorsicht beim Kauf. Es handelt sich jedoch um eine sehr typische Konfiguration, die viele Leute verwirrt, die zunächst Routing, Paketfilterung (Firewall) und NAT (Network Address Translation) verwechseln.
Sie drücken es nicht klar aus, aber ich würde vermuten, dass Ihr Netzwerk folgendermaßen aussieht:
Internet <-A-> SOHO Router <-B-> Server/workstation <-C-> VM
Ihr DNS-Server befindet sich im B-Netzwerk, also 192.168.1.0/24
Ich vermute, dass Ihr Internet-SOHO-Router die Nummer 192.168.1.1 hat und als Standard-Gateway für das Netzwerk eingestellt ist. Dies wäre eine äußerst gängige Konfiguration.
Sie geben selbst an, dass der DNS-Server auf 192.168.1.2 liegt und die überbrückte Schnittstelle des Servers 192.168.1.10 ist. Dahinter liegt das Netzwerk 10.9.9.0/24.
Ihr iptables-Setup leitet weiterallePakete auf demSchnittstelle. In der Praxis senden Sie alle Pakete von einem Netzwerk zum anderen - auch lokale Pakete. Das ist der wichtige Unterschied.
In Ihrer PF-Konfiguration führen Sie Folgendes aus:nichtnach vorneallePakete auf demSchnittstelleSie haben eineNetzwerk em1:network. Wir haben nicht die vollständige Konfiguration, aber ich würde vermuten, dass Sie eigentlich eine schöne und funktionierende Barebone-Konfiguration haben. Was Sie stört, sind die fehlenden Routen.
Wenn Sie ein Paket vom 10.9.9.0/24-Netz senden, erreicht es das 192.168.1.0/24-Netz. Ihr Server hat einen Abschnitt in dieses Netz, sodass Sie Ihren DNS direkt erreichen. Aber der DNS-Server im B-Netz hat keine Ahnung, wie er das nicht lokale C-10.9.9.0/24-Netz erreichen soll. Alle Antworten würden dann an den „Standardrouter“ gesendet, der vermutlich Ihr SOHO-Router ist. Dieser Router weiß auch nur, wo sich das 192.168.1.0/24-Netz befindet (nicht 10.9.9.0/24) und würde normalerweise alles an Ihren externen Internet-Link weiterleiten. In diesem Fall verwenden Sie richtige private Adressen – das Paket würde also stattdessen verworfen, da private Adressen im Internet nicht weitergeleitet werden.
Die „richtige“ Lösung wäre, auf Ihrem SOHO-Router eine Route einzurichten, die ihn anweist, Pakete für 10.9.9.0/24 an 192.168.1.10 zu routen. Ein guter Router ermöglicht Ihnen dies. Viele billige SOHO-Router tun dies leider nicht. In diesem Fall könnten Sie die Route auf Ihrem DNS-Server hinzufügen, um sie zu testen.
- Der Grund, warum es bei Ihnen mit iptables funktioniert, ist, dass das Antwortpaket auf der eth0-Schnittstelle angezeigt wird und alle Pakete weitergeleitet werden. Der gesamte Datenverkehr im B-Netz wird an das C-Netz gesendet (und umgekehrt). Dies schließt Datenverkehr ein, der lokal hätte bleiben können/sollen. Tatsächlich haben Sie eine Netzwerkbrücke eingerichtet.
- Der Grund, warum es bei Ihnen mit Ihrem ersten PF-Setup nicht funktioniert, ist, dass Sie angegeben haben, welches Netzwerk Sie erwarten. Nur eine Maschine im B-Netz weiß, wo das C-Netz zu finden ist. Dies ist 192.168.1.10, da sie eine Schnittstelle zum C-Netz hat. Im Endeffekt haben Sie eine einfache Firewall eingerichtet. Die Filterung ist bereit, aber Sie filtern noch nichts. Aber das Routing fehlt.
- Der Grund, warum es in Ihrer zweiten PF-Konfiguration funktioniert (Ihre eigene Antwort), ist, dass Sie das Netzwerk 10.9.9.0/24 per NAT in den Adressraum 192.168.1.0/24 verschieben. Der gesamte Datenverkehr aus dem C-Netz 10.9.9.0/24 wird im B-Netz so aussehen, als käme er von 192.168.1.10.NAT sollte vermieden werdenwann immer möglich und nur als letztes Mittel eingesetzt werden.
Wenn Sie keine Pakete filtern müssen/wollen, würde ich Ihnen raten, keine Firewall zu verwenden. Was Sie versuchen, sollte erledigt werden vonEinfaches Routing.
Antwort3
Wenn Sie ein „alles offenes“ Gateway wünschen, können Sie das mit nur einer einzigen Regel erreichen:
pass all allow-opts
Es war kein Herumspielen mit explizitem „Status beibehalten“ oder mit Flags erforderlich.