Brauch' mal 'ne Übersetzung: iptables zu ipfw

[Rosendoktor]

Hallo,

erst mal bisschen Text vorweg

Also, ich war bei der Installation von FreeBSD sehr positiv überrascht, dass der Installer gleich die Installation eines lokalen validierenden Resolvers anbot. Genau sowas habe ich mir nämlich mit einigem Aufwand auch auf meinen Linux Notebooks und Android Phone+Tablet eingerichtet, unter Linux mit bind9 und unter Android mit einem selbstcompilierten unbound (das meiste an Vorarbeit hat da schon ein irgendein Tscheche gemacht).

Dabei gebe ich den Resolvern aber keine Forwarder, sondern lasse sie die Auflösung selbst über die Rootserver machen. Damit aber in lokalen, vertrauenswürdigen Netzen auch die internen Adressen aufgelöst werden können, soll der lokale Resolver in solchen Netzen nicht benutzt werden.

Jetzt ist die Frage, wie man das automatisiert. Da bieten sich ja mehrere Möglichkeiten an. Unter Linux erledigt das sehr bequem der ... tadaaaaaaaaaaaaa! ... NetworkManager! Bitte keine Diskussion darüber... Unter Android habe ich einfach die Holzhammermethode genommen und per iptables Regel alle ausgehenden DNS Pakete nach 127.0.0.1 zum lokalen unbound umgeleitet, ausser sie kommen vom lokalen unbound selbst oder sie gehen an die Adresse(n) vertrauenswürdiger Resolver in bekannten Netzen.

Das möchte ich unter FreeBSD auf dem Notebook auch so machen, bisher aber leider erfolglos. Eine Art NetworkManager gibt es... okay, lassen wir das. Also hab' ich versucht, mit dem recht filigranen Setup aus dhcp, dhcpv6, resolvconf uws. herumzuspielen, irgendwelche hooks zu suchen wo ich mich mit einem Skript einklinken kann, aber alles hat bisher immer mehr kaputtgemacht als dass es funktioniert hätte.

Also doch erst mal die aus Android bekannte Holzhammermethode. Ich habe noch keinerlei Ahnung von ipfw, daher wär's nett wenn mir hier jemand helfen könnte. Die iptables Regel die den Redirect macht sieht so aus:

iptables -t nat -I OUTPUT -m owner ! --uid-owner <uid von unbound> ! -d 88.xxx.yyy.146 -p udp --dport 53 -j DNAT --to 127.0.0.1:53
iptables -t nat -I OUTPUT -m owner ! --uid-owner <uid von unbound> ! -d 88.xxx.yyy.146 -p tcp --dport 53 -j DNAT --to 127.0.0.1:53

Also alles ausgehende zu remote port 53, was nicht vom lokalen unbound kommt und nicht zur ip 88.xxx.yyy.146 geht, soll an den lokalen unbound auf 127.0.0.1:53 umgeleitet werden. ipv6 lassen wir jetzt erst mal weg...

Kann das mit ipfw auch so realisiert werden, und kann mir jemand helfen das zu übersetzen?

Danke und Gruss,

Robert

 

[Crest]

Du brauchst keine Firewall um deinen lokalen DNS Resolver zu verwenden. Ich vermute mal das dein Laptop überall sich per DHCP IPv4 Adressen zieht. In dem Fall reicht es in der /etc/dhclient.conf in einem supersede Block die per DHCP gelernten DNS Resolver mit 127.0.0.1 zu überschreiben. Das FreeBSD Basissystem enthält schon unbound du brauchst dir also noch nicht etwas dazu installieren.

 

[Rosendoktor]

Danke für die Antwort, aber das war nicht die Frage.

Es geht darum, den lokalen Resolver in bestimmten Netzen (in denen bereits ein vertrauenswürdiger validierender Resolver zur Verfügung steht) eben NICHT zu verwenden. Also entweder die Erstellung der /etc/resolv.conf abhängig vom WLAN Netz in dem man ist zu beeinflussen, oder eben per Firewallregel die gelernten Resolver zuzulassen (anhand deren eindeutiger ip) oder die DNS Anfragen zu redirecten.

 

[Crest]

In dem Fall bietet es sich an not table(1) als Ziel zu verwenden und in table(1) mit ipfw table 1 add 1.2.3.4/32 usw. die passenden Resolver aufzunehmen. So reicht es den Inhalt der IPFW Table zu verändern um neue DNS Resolver hinzufügen oder zu entfernen anstatt die Regeln zu verändern.

 

[Rosendoktor]

Danke, hab' jetzt eine andere funktionierende Lösung gefunden: Ich hab' das /sbin/dhclient-script leicht modifiziert und ersetze dort einfach alle vom dhclient gelieferten Nameserver durch 127.0.0.1, ausser wenn die ip 88.xxx.yyy.146 ist (also der DNS in meinem eigenen Netz). Damit funktioniert das einwandfrei.

Gruss,
Robert

 

[derOliver]

Bedenke, dass die Änderungen beim nächsten Update vom Basissystem weg sein können.

 

[Rosendoktor]

Genau, deswegen ist der Code jetzt in den offiziellen Hook /etc/dhclient-enter-hooks umgezogen und das /sbin/dhclient-script wieder original.