FreeBSD DSL Router auf Basis von pf

buebo

Well-Known Member
Einleitung
Wie vielleicht einige in einem anderen Threat schon mitbekommen haben ist es wegen der mangelnden Unterstützung von OpenBSD für einen UDMA-Controller für mich erforderlich meinen Router von OpenBSD auf ein anderes BSD umzusteigen. Eigentlich habe ich mit NetBSD geliebäugelt da dort auch RAIDFrame integriert ist, ein Soft-Raid das meiner Meinung nach wesentlich einfacher und eleganter zu konfigurieren ist als Vinum bei FreeBSD (mein Router macht nebenher auch noch als Fileserver dienst).
Trotzdem habe ich mich letztendlich für FreeBSD entschieden, aus zwei einfachen Gründen, zum Einen stehe ich auf halbwegs Familiären Fuß mit FreeBSD, zum Anderen habe ich vor auf der Maschine noch einige zusätzliche Serverdienste laufen zu lassen und FreeBSD bietet mit Portupgrade eine narrensichere Lösung installierte Pakete zu updaten.
Die Entscheidung für pf als Firewall ist mir leichtgefallen. pf bietet wunderbare Features und lässt sich in meinen Augen viel einfacher und eleganter verwalten als ipfw, der Standard-Firewall von FreeBSD. Abgesehen davon bin ich auch mit pf mehr vertraut als mit ipfw, so das ich keinen Grund sehe mich in das (imho) schlechtere ipfw einzuarbeiten.
Die Schattenseite ist allerdings das man auf die Security Features, wie z.B. W^X, verzichtet.
Natürlich lässt sich über den Sinn und Unsinn dieser Features ganz vortrefflich streiten, vor allem auf einem Firewall System das im wesentlichen die meisten Ports nach aussen geschlossen hällt und im Internet keine Serverdienste anbietet.

Was kann der Router wenn es fertig ist?
Ich werde mich in dieser Hinsicht auf das Notwendige beschränken, nach durcharbeiten des Howtos wird der Rechner folgendes erledigen:

  • Er wird ein Netzwerk per NAT (Network Adress Translation) in's Internet einbinden
  • Er wird neuen Rechnern im Netz automatisch eine IP-Adresse zuweisen per DHCP
  • Er wird den Rechnern im Netzwerk einen Nameserver zur Verfügung stellen, der sich allerdings darauf beschränkt die Anfragen an den Nameserver eures Providers durchzureichen
  • Er wird aus dem Internet ankommende Pakete mittels des mächtigen und modernen Paketfiler 'pf' filtern.
  • Er wird einen FTP-Proxy betreiben der den Zugang zu allen Arten von FTP-Seiten, also sowohl active wie auch passive FTP, für die Rechner im LAN ermöglicht
  • Er wird bald die Fähigkeit haben Traffic-Shaping zu betreiben, das heisst bestimmten Diensten (etwa dem eDonkey oder einem Webserver) eine bestimmte Bandbreite zur Verfügung zu stellen, selbst bei hoher Netzlast. Das heisst natürlich das anderer Netzwerk-Verkehr, etwa Browsen oder andere Uploads dadurch langsamer werden. Leider ist ALTQ noch in einer wilden Testphase und nicht stabil, aber die Entwicklung scheint mir zügig vorranzuschreiten.

Die Schritte dazu sind relativ einfach und schnell, wobei man sich etwas Zeit mitbringen sollte. Es ist erforderlich den Kernel neuzubauen und das kann auf einem typischen Router (Pentium 1 Klasse mit relativ wenig RAM) doch schon mal etwas länger dauern. Im einzelnen werden wir folgendermassen vorgehen:

  1. Erstellen eines angepassten Kernels für PPPoE und pf
  2. Konfiguration der Internetverbindung mit ppp, gegebenenfalls noch ein update der Ports
  3. Installieren von pf aus den Ports und aktivieren der Gateway-Funktion
  4. Erstellen eine Regeldatei für pf
  5. Erstellen der Konfiguration für named (den DNS) und dhcpd (Vergabe von IP-Adressen im LAN)
    [/list=1]

    Dieses Howto versucht möglichst unkompliziert die Nutzung des FreeBSD Rechners als Gateway zu erklären, bei längerer Benutzung erlöst einen eine einmalig funktionierende Konfiguration jedoch nicht von der Aufgabe sich selbst mit Informationen zu versorgen, deshalb werde ich an den relevanten Stellen auf weiterführende Doku hinweisen.
    Vorraussetzungen für die Durchführung ist auf Hardware-Seite ein System mit zwei Netzwerkkarten, von denen eine an das DSL-Modem und eine an das Interne Netz angeschlossen wird, auf der Wissens-Seite setze ich ein verständniss für die funktion eines Netzwerks vorraus und das Wissen um das grundlegende Handling eines BSD-Systems vorraus, etwa das Übersetzen eines Kernels oder das Updaten des Systems und der Ports. An Software wird als OS ein FreeBSD System der 5er Reihe vorrausgesetzt, also etwa 5.0; 5.1 oder ein aktuelles -current, da meines Wissens pf auf 4-Stable und Konsorten nicht läuft. Bei der Installation sollte man darauf achten die Kernel-Sourcen zu installieren, da wir noch bevor eine Internetverbindung aufgesetzt wird einen neuen Kernel erstellen, man diese also nicht aus dem Netz installieren kann.

    Anmerkung: Ich schreibe das hier nebenher und bin selbst grade dabei es umzusetzen, es besteht also die Möglichkeit das ich mich verrenne und die Informationen hier für einige Zeit ungenau oder falsch stehen.
    Zum Schluss muss ich noch anmerken das ich keine Verantwortung für defekte Hardware, enttäuschte Erwartungen oder zerschlagene Monitore übernehme, Anwendung auf eigenes Risiko!

    Bitte nicht in diesem Threat kommentieren!
    To be Continued...
 
Zuletzt bearbeitet:
1. Erstellen eines angepassten Kernels

1.1 Installation der Kernel-Sourcen von CD

PPPoE (Point to Point Protocoll over Ethernet - das Protokoll für DSL) und pf brauchen bestimmte Optionen im Kernel, theoretisch kann man zumindest die Optionen von PPP auch nach oder bei dem booten dynamisch laden lassen, dazu sollte man sich die /boot/loader.conf ansehen und die entsprechenden Einstellungen tätigen, die entsprechende Manpage hilft dafür weiter. Ich gehe davon aus das man die Optionen fest in den Kernel kompiliert.
Man sollte am besten alle Sourcen bei der Installation mit installieren da man über Kurz oder Lang sowieso nicht daran vorbeikommt diese zu per CVSup zu downloaden wenn man Patches und Security-Fixes installieren will, dabei verkürtzt es die Zeit für den Download erheblich wenn man schon halbwegs aktuelle Sourcen auf der Platte liegen hat.
Sind die Sourcen noch nicht installiert kann man das mit Systinstall und einer FreeBSD-CD nachholen.
Dazu auf der Konsole /stand/sysinstall eingeben. Dann im Menu über "Configure" -> "Distributions" -> "Src" zur Auswahl der einzelnen Quelle-Code-Teile durchhangeln. Im Grunde genommen kann man sich bei der Auswahl auf "Sys" beschränken, aus den oben genannten Gründen empfehle ich aber die Auswahl von "All". Hat man einen funktionierenden Gateway im Netz kann man natürlich die Quellen auch von einem FTP-Mirror installieren, das Vorgehen dabei ist das gleiche.
Abhängig von der Computer-Geschwindigkeit hat man nun vielleicht schon Zeit für die erste Kaffee-Pause, ansonten kommt das beim Kernel übersetzen.

1.2 Übesetzen des Kernels
Nachdem wir die Sourcen installiert haben Wechseln wir in das Verzeichniss /usr/src/sys/{arch}/conf wobei {arch] für die verwendete Architektur, in den meisten Fällen also i386 steht.
Nun erstellen wir eine angepasste Konfigurations-Datei, dazu wird zuerst GENERIC (die Datei auf der der Standard-Kernel basiert) kopiert und danach editiert.

Code:
# cd /usr/src/sys/i368/conf
# cp GENERIC MYKERNEL
# edit MYKERNEL

Das bringt uns in den Texteditor, anders als bei Linux basiert die FreeBSD-Kernel Configuration auf einer einzigen Textdatei. In den ersten Zeilen findet man den Wert "Ident", diesen sollte man auf den Namen der eigenen Konfigurationsdatei setzen, in diesem Beispiel also MYKERNEL.
Folgende Optionen fügen wir am Ende der Datei an, wobei die Gross und Kleinschreibung beachtet werden muss.

Code:
# Eigene Einträge
options         NETGRAPH
options         NETGRAPH_SOCKET
options         NETGRAPH_PPPOE
options         NETGRPAH_ETHER
options         PFIL_HOOKS
options         RANDOM_IP_ID
options         INET6

Ist man unerfahren in der Erstellung des eigenen Kernels empfehle ich erstmal die Finger von allen anderen Optionen zu lassen, es kann recht frustrierend sein sich in den eigenen Optimierungen zu verhedern. Zudem bringt das Rauswerfen von Optionen und Treibern nicht unbedingt einen Merkbaren Geschwindigkeitsvorteil, dafür aber die Gefahr etwas zu entfernen das man eigentlich braucht.
Recht gefahrlos ist es allerdings in den ersten Zeilen den Wert für CPU auf den für die eigene Maschine gültigen zu setzen, den bekommt man durch dmesg.
Wenn dir das nichts sagt, lass es einfach, es funktioniert auch so mehr als zufriedenstellend.
Durch drücken von "Esc" beenden wir den Editor, wobei wir im fogenden Dialog "Save Changes" auswählen.
Nun gehen wir daran einen neuen Kernel zu erstellen.

Code:
# config MYKERNEL
Kernel build directory is ../compile/MYKERNEL
Don't forget to do a ``make depend''
# cd ../compile/MYKERNEL
# make depend && make && make install && reboot

Nun sollte auf dem Bildschirm nur noch Kauderwelsch erscheinen, das wird sich auch erstmal nicht ändern, FreeBSD ist beim übersetzen des Kernels sehr mitteilungsfreudig. Abhängig von der Rechnergeschwindigkeit wird es nun etwas dauern, auf einem P1 100Mhz bei mir waren es ca. 3 Stunden, auf einem 333Mhz P3 ca. 40 Min. Nach dem Übersetzen des Kernels wird der Rechner neu booten und damit alle unsere Änderungen übernommen haben.
Zeit für eine Kaffeepause!

Bitte nicht in diesem Threat kommentieren!
To be continued...
 
Zuletzt bearbeitet:
2.1 Internet-Zugang mit ppp
An dieser Stelle ist eine Warnung angebracht: Ich gehe hier davon aus das man eine Flatrate besitzt und somit lange eingewählt bleiben will, für Zeitabhängige Tarife sollte man einen anderen Schalter bei ppp verwenden, aber dazu später mehr.

Um die Verbindung zu unserem Provider aufzubauen benutzen wir das Programm ppp. Dessen Zentrale Konfigurationsdatei ist gut kommentiert und liegt in /etc/ppp/ppp.conf und da sie vielleicht später noch für Referenz-Zwecke gebraucht werden kann löschen wir sie nicht einfach sondern geben ihr einen anderen Namen. Danach starten wir einen Editor und geben unsere eigene Konfiguration ein. Dabei ist zu beachten das jedes Leerzeichen wichtig ist, fehlende Leerzeichen oder Schreibfehler bringen ppp dazu unter einem Wust von obskuren Fehlermeldungen abzubrechen. Ich empfehle meine Datei zu übernehmen und sie nur um Passwort und Username zu ergänzen.

Code:
# mv /etc/ppp/ppp.conf /etc/ppp/ppp.conf.old
# edit /etc/ppp/ppp.conf

Unsere ppp.conf sieht folgendermassen aus:

Code:
default:
 set device PPPoE:[i]interface[/i] [color=red][1][/color]
 set MTU 1492 [color=red][2][/color]
 set MRU 1492 [color=red][2][/color]
 set dial
 set crtscts off
 set speed sync
 accept lqr
 disable deflate
 disable pred1
 disable vjcomp
 disable acfcomp
 disable protocomp
 set log Phase LCP IPCP CCP Warning Error Alert
 set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
 add default HISADDR
 set login
 set authname "Benutzernamen" [color=red][3][/color]
 set authkey "Passwort" [color=red][3][/color]

[1] Interface sollte man durch den namen der Netzwerkkarte ersetzen die man am DSL-Modem angeschlossen hat, in meinem Fall sieht die Zeile folgendermassen aus:
set device PPPoE:ed0

[2]Die Zeilen MTU 1492 und MRU 1492 sind eine Spezialität von T-Online, bei denen ein Paket zwei mal den Pfad von T-Online-Server zum Kunden zurücklegt und somit mehr Platz für Header benötigt, wodurch die maximale Größe von Nutzdaten sinkt.
Bei manchen Providern nennt sich diese Technik "Interleaving" während das Auslassen davon als "Fastpath" bezeichnet wird.
Grundsätzlich empfehle ich die Zeilen erst einmal zu benutzen, sie schaden auf keinen Fall. Wenn ansonsten alles funktioniert kann man es ohne versuchen.

[3] Der Aufbau des T-Online-Benutzernamens ist bestenfalls kryptisch zu nennen, wird aber unter folgendem URL beschrieben: http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html#AUTHNAME
Man sollte auch darauf achten den Benutzernamen unbedingt in Anführungszeichen zu setzen, ppp interpretiert sonst ein evtl. vorkommendes Raute-Zeichen als Kommentar, wodurch die Hälfte des Benutzernamens ungültig wird und die Einwahl scheitert.
Hat man einen anderen Provider der gescheite Benutzernamen vergibt kann man sich die Zeichen sparen, schaden tuen sie aber auf keinen Fall.

2.1 Start von ppp und evtl. Fehlersuche
ppp sollte sich nun ohne grosse Umschweife starten lassen:
Code:
# ppp
Working in interactive mode
Using interface: tun1
ppp ON gwen> dial
Wenn nun das ppp zu ppP, pPP und anschliessen PPP wird ist ein erfreutes Grinsen durchaus angebracht. Klappt etwas nicht sollte man einen Blick in die Logfiles werfen, höchstwahrscheinlich liegt ein Tippfehler vor.
Um ersteinmal für die Aktualisierung der Ports ins Netz zu können sollte man den Nameserver seines Providers in die /etc/resolv.conf eintragen, bei T-DSL ist das meines Wissens 194.25.2.129, bei QSC ist es 193.189.244.197, bei NGI 193.159.187.130
Am besten erkundigt man sich vorher bei seinem Provider.
Ein andere Weg ist es die ppp.conf um 'enable dns' zu ergänzen, wodurch ppp den dns-server vom Priovider empfängt und in die /etc/resolv.conf einträgt. Man sollte daran denken diesen Eintrag aus der ppp.conf zu entfernen bevor man einen eigenen Nameserver aufsetzt, was wir noch machen werden.
Wenn die ppp Konfiguration funktioniert spricht nichts dagegen das Programm schon beim Booten zu starten damit der Rechner jederzeit bereit ist uns ins Internet zu bringen.
Dafür ergänzen wir die Datei /etc/rc.conf um folgende Einträge:
Code:
ifconfig_[i]interface[/i]="up" [color=red][1][/color]
ppp_enable="YES"
ppp_mode="ddial" [color=red][2][/color]
ppp_profile="default"
[1] Hier muss wieder "interface" durch den Namen der Netzwerkkarte ersetzt werden
[2] Auch hier wieder für Flatrates, Leute mit Volumen oder Zeit-Tarif sollten sich die Einstellung 'auto' ansehen die im Gegensatz zu 'ddial' die Verbindung nur aufbaut wenn wirklich Datenverkehr stattfindet.

2.2 Aktualisieren der Ports
Ich gehe davon aus das die Ports schon installiert sind, ansonsten ist das Vorgehen um sie zu installieren äquivalent zu dem um die Sourcen zu instalieren, ausserdem ist eine aktive Internet-Verbindung erforderlich, die sich mit 'ppp -ddial' auch im Hintergrund aufbauen lässt.
Nun installieren wir CVSup, das Tool um unter FreeBSD seinen Quellen und Ports aktuell zu halten.

Code:
# cd /usr/ports/net/cvsup-withou-gui
# make install clean

Will man den Rechner auch unter X Benutzen kann man natürlich auch cvsup statt cvsup-without-gui benutzen, der Unterschied liegt rein darin das cvsup noch ein X-Frontend mitbring, dafür aber auch gleich einige XFree86-Libaries benötigt und entsprechend länger zum Übersetzen braucht.
Während wir auf die Übersetzung von cvsup warten wechseln wir mittels [ALT]+[F2] auf eine neue Konsole, loggen uns als root ein und schreiben erstellen die Datei /etc/ports-sup

Code:
# nano /etc/ports-sup
*default tag=.
*default host=cvsup2.de.freebsd.org
*default prefix=/usr
*default base=/usr/
*default release=cvs delete use-rel-suffix compress

ports-all

Wichtig: Diese Datei weist CVSup an nur die Ports zu aktualisieren da es wir an dieser Stelle nicht darauf warten wollen bis der ganze Sourcecode durch die Leitung gekrochen ist. Man sollte sich aber unbedingt auch eine Datei erstellen die aktualisierungen für den Sourcecode enthällt, mehr dazu im Handbuch
Die Aktualisierung wird nun wieder etwas dauern, was für uns heisst es ist Zeit für den nächsten Kaffee.

Bitte nicht in diesem Threat kommentieren!
To be continued
 
Zuletzt bearbeitet:
3.1 Installieren von pf aus den Ports
Dieser Schritt ist schnell hinter sich gebracht, vorher aber noch ein paar Worte über die Funktionsweise von pf.
pf ist eine Portierung von OpenBSD die ziemlich schnell vorranschreitet, aber auf der anderen seite noch nicht wirklich den Status erreicht hat den man als Stable versteht.
Grundsätzlich läuft pf zwar Stabil aber es existieren noch nicht die Erfahrungswerte die man mit ipfw gesammelt hat. Für den Anwender bedeutet das, das man sich unbedingt auf der pf Mailingeliste eintragen sollte, Updates erfolgen recht häufig und beseitigen oftmals Bugs, ausserdem sind die Entwickler immer an Feedback intressiert, selbst wenn es ausser einem lapidaren "Funktioniert" nichts zu berichten gibt.
pf installieren wir aus dem Ports.

Code:
# cd /usr/ports/security/pf
# make install clean

Im Zuge der Installtion werden wir noch gefragt ob wir Benutzer und Gruppen für den FTP-Proxy haben wollen, dies bejahen wir.
pf selbst besteht aus drei Kernel-Modulen die manuell nachgeladen werden müssen und in /usr/local/modules liegen. dazu gibt es noch die Userland-Programme pfctl und pflogd die beide in /usr/local/sbin liegen.
Damit pf und damit auch NAT funktionieren laden wir die Module und bringen die virtuellen Interfaces hoch.

Code:
# kldload /usr/local/modules/pflog.ko
# ifconfig pflog0 up
# kldload /usr/local/modules/pfsync.ko
# ifconfig pfsync0 up
# kldload /usr/local/pf.ko

Theoretisch könnten wir das nach jedem Reboot eintippen und damit pf manuell laden, dann ppp aufrufen und von ppp.linkup den pflogdaemon starten und die interfaces hochbringen lassen, aber immerhin benutzen wir ein Unix Betriebssystem und nicht etwas winzig Weiches ;-)
Die Lösung heisst natürlich /etc/rc.conf und darin muss stehen:

Code:
gateway_enable="YES"
ifconfig_[i]interface[/i]="up"
pf_enable="YES"
pf_logd="YES"
pf_conf="/etc/pf.conf"
ifconfig_pflog0="up"
ifconfig_pfsync0="up"
ppp_enable="YES"
ppp_mode="ddial"
ppp_profile="default"

Dabei ist zu beachten das die Reihenfolge eingehalten werden sollte. In der ersten Zeile wird auch gleich noch das Pakteforwarding eingeschaltet. Wir wollen aber nicht bis zum nächsten Reboot warten und schalten es deshalb noch manuell ein und machen setzen bennen danach noch das script zum start von pf um damit es beim booten Gestartet wird und die entsprechenden pf-Einträge in der rc.conf ausführen kann.

Code:
# sysctl -w net.inet.ip.forwarding=1
# cp /usr/local/etc/rc.d/pf.sh.sample /usr/local/etc/rc.de/pf.sh

Danach legen wir noch zwei neue Dateien an, die sobald ppp sich einwählt die Loginterfaces von pf hochfährt und das Regelset läd. Beim Verbindungsverlusst wird wieder der Originalzustand hergestellt.

Zuerste die /etc/ppp/ppp.linkup

Code:
MYADDR:
 ! sh -c "/sbin/ifconfig pflog0 up"
 ! sh -c "/sbin/ifconfig pfsync0 up"

danach die /etc/ppp/ppp.linkdown

Code:
MYADDR:
 ! sh -c "/sbin/route delete default"

Zeit für Kaffee!

Bitte nicht in diesem Threat kommentieren!
To be Continued...
 
Zuletzt bearbeitet:
4.1 Das Regelset
Grundsätzlich funktioniert ein Paketfilter sehr simpel, jedes Pakete das er empfängt wird mit einer Reihe von Regeln verglichen und danach behandelt. Besagt eine Regel verwerfe alle Pakete die von Joe kommen macht der Filter das.
Pf hat einen wie ich finde sehr eleganten Stil mit Regeln umzugehen und so werden die Dateien recht übersichtlich und einfach zu verstehen.
Ich werde meinen Regelsatz hier nicht grossartig kommentieren, wer sich mit pf beschäftigen will (und das sollte man ;-)) findet bei der OpenBSD pf User Guide eine vorzuügliche Einführung, wobei für FreeBSD keinerlei besonderheiten zu beachten sind, ausser das ALTQ noch nicht funktioniert.
Einige Optionen habe ich auskommentiert, diese sind optional.
Code:
# cat /etc/pf.conf
Intern = "[i]interface[/i]"  #Device im Internen Netz, bei mir rl0
Extern = "tun0"  # Das ppp-Device
IntNet = "192.168.0.0/24" # Adressraum des internen Netzes
RouterIP = "192.168.0.100" # IP Adresse des Routers
Loop = "lo0" # Loopback Device

# Ports die wir öffnen wollen:
# $ServicePortsTCP = { eintrag1, eintrag2 } #an dieser Stelle alle Ports eintragen 
#die man nach aussen öffnen will
# entweder mit Namen (z.B. "ssh") oder als Nummer (z.B. 22) 
# eine Liste der Namen findet ihr unter /etc/services

# Hier die UDP-Ports, z.B. edonkey
# $ServicePortsUDP = { eintrag1, eintrag2 } # nach dem gleichen Schema wie oben.

set loginterface $Extern
set optimization aggressive
scrub in on $Exter all fragment reassemble random-id

# NAT aktivieren
nat on $Extern from $IntNet to any -> tun0 static-port


# Falls Active FTP gewünscht ist, folgendes Auskommentieren:
# rdr on $Int proto tcp from !$RouterIP to !$IntNet port 21 -> 127.0.0.1 port 8021

rdr-anchor redirect

block on $Extern
block return log on $Extern

pass quick on $Loop

# Erschwert scannen mit nmap und co.
block in log quick on $Extern inet proto tcp from any to any flags FUP/FUP
block in log quick on $Extern inet proto tcp from any to any flags SF/SFRA
block in log quick on $Extern inet proto tcp from any to any flags /SFRA

# IP Spoofing verhindern
block in log quick on $Extern inet from $NoRoute to any
block in log quick on $Extern inet from any to $NoRoute

# Falls Active FTP gewünscht wird (empfehlenswert)
# pass in quick on $Extern inet proto tcp from any to any port > 49151 user proxy flags S/SAFR keep state

# Ping akzeptieren (ablehnen ist uebrigends wenig sinnvoll)
pass in quick on $Extern inet proto icmp all icmp-type 8 code 0 keep state

# Ports nach aussen oeffnen
# Die folgenden Regeln nur auskommentieren wenn ihr oben Ports eingetragen habt die geöffnet werden sollen.
# pass in quick on $Ext inet proto tcp from any to any port $ServicePortsTCP flags S/SAFR keep state label ServicesTCP
# pass in quick on $Extern inet proto tcp from any to any port $ServicePortsUDP flags S/SAFR keep state label ServicesUDP

anchor passin
pass out quick on $Extern keep state

Wenn Active FTP gewünscht wird, muss der inetd veranlasst werden bei Bedarf den FTP-Proyx von pf starten, dazu muss folgende Zeile in die /etc/inetd.conf eingetragen werden.

Code:
ftp-proxy stream tcp nowait root /usr/local/libexec/ftp-proxy ftp-proxy

Danach starten wir noch den inetd neu und laden unser pf Regelset

Code:
# inedt
# pfctl -e -F all -f /etc/pf.conf

Nun haben wir es schon zum größten Teil geschafft, unser Router leitet fleissig Pakete weiter und wir können auf FTP-Server zugreifen, allerdings müssen wir unseren Clients noch manuell den Nameserver mitgeben, deswegen werden wird im nächsten Kapitel unser eigener Nameserver aufgesetzt.
Aber erst: Kaffee!

Bitte in diesem Threat nicht kommentieren!
To be Continued...
 
Zuletzt bearbeitet:
5.1 DNS
Das einrichten des DNS ist eine wirklich schnelle angelegenheit, allerdings möchte ich darauf hinweisen das an dieser Stelle Experimente nicht angebracht sind, DNS ist ein ziemliches Sensibelchen und man hat damit schnell mal sich oder im Extremfall sogar andere aus dem Netz gekickt.
Bei FreeBSD ist im Basis-System schon ein Nameserver dabei der nur noch Konfiguriert und gestartet werden muss, wobei das zentrale Verzeichniss dafür unter /etc/namedb zu finden ist. dorthin begeben wir uns nun und erzeugen eine Konfigurationsdatei die danach nur noch leicht angepasst werden muss.

Code:
# cd /etc/namedb
# sh make-localhost

Im nun folgenden Schritt brauchen wir definitiv die Adresse des DNS von unserem Provider. Danach öffnen wir die Datei named.conf und entfernen die Kommentarzeichen rund um den Eintrag forwarders und vor dem Eintrag query source address * port 53
Die Datei sollte danach folgendermassen aussehen (Änderungen fett):

Code:
// $FreeBSD: src/etc/namedb/named.conf,v 1.14 2003/02/07 20:58:38 keramida Exp $
//
// Refer to the named.conf(5) and named(8) man pages for details.  If
// you are ever going to set up a primary server, make sure you
// understand the hairy details of how DNS works.  Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.

options {
        directory "/etc/namedb";
        pid-file "/var/run/named/pid";

// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:


//
//      forward only;

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
[b]
        forwarders {
                [i]IP des DNS[/i];};
        forward only;
[/b]
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        [b]query-source address * port 53;[/b]

Den Rest der Datei lassen wir unangetastet.
In der Datei /etc/resolv.conf darf nun nur noch ein Nameserver stehen und das ist natürlich der von uns selbst, also verändern wir sie hin zu folgendem und starten danach unseren Nameserver:

Code:
# cat /etc/resolv.conf
nameserver 127.0.0.1
# named -u bind -g bind

Wenn der Server ohne weiteren Kommentar gestartet wird sollte man vorsichtshalber noch einen Blick in /var/log/messages werfen, sieht man dort nix was auf einen Fehler hindeutet darf man sich freuen.

5.2 DHCP
Hierbei handelt es sich um ein Protokoll mit dem Clients, ohne schon konkrete Netzwerkdaten zu haben, von einem zentralen Server sich eine IP-Adresse, Hostname, einen Gateway und einen DNS zuweisen lassen können.
Persönlich finde ich es vor allem intressant wenn man ab und an mal Freunde zu Besuch hat, die sich nur mal schnell mit ihrem Laptop einwählen wollen. Abgesehen davon kann man auch IP-Adressen fest an Hardware-Adressen zu binden.
Auf der anderen Seite ist es natürlich ein weiterer Netzwerkdienst, der eigentlich nicht zwingen nötig ist. Ob es das Risiko wert ist kann daher nicht ganz eindeutig beantwortet werden.
Persönlich benutze ich den dhcpd sehr gerne, unter anderem weil ich hier einige Kisten stehen habe die beim booten eine IP-Verbindung aufbauen müssen um sich per nfs das eigene Filesystem zu mounten. Wer sowas nicht hat muss es sich überlegen, bequemer ist es alle mal.
Haben wir uns für die installation eines dhcp Servers entschieden wechseln wir in das entsprechende Ports-Verzeichniss und installieren ihn mit der üblichen Prozedur.

Code:
# cd /usr/ports/net/isc-dhcp3 
# make install clean

Wurde der Server ohne Probleme installiert müssen wir noch eine Konfigurationsdatei names dhcpd.conf in /usr/local/etc/ anlegen mit folgendem Inhalt:
Code:
option domain-name "local-lan.local";
option domain-name-servers NAMESERVERIP;
option subnet-mask 255.255.255.0;

default-lease-time 3600;
max-lease-time 86400;
ddns-update-style none;

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.1 192.168.0.99;
  option routers GATEWAYIP;
}

Natürlich sollte man für NAMESERVERIP und GATEWAYIP noch die entsprechenden Werte eingeben, wenn man diesem Howto gefolgt ist dann ist das in beiden Fällen die interne Adresse unseres Routers.
Bei Range gibt man einen Bereich von IP-Adressen ein, die der DHCP-Server frei an neue Clients vergeben soll, das schränkt natürlich nicht ein, welche IP-Adresse über den Router in's Internet geht, sondern eben nur in welchem Bereich neue IP-Adressen vergeben werden. Ist der Bereich ausgeschöpft werden keine mehr Vergeben.
Zu beachten ist auch das Nameserver, Subnet und Range in einem Subnet sein müssen.
Eine Range von 192.168.1.1 bis 192.168.2.100 wird genauso zu problemen führen wie eine falsche Gateway-IP, allerdings wird sich der DHCP-Server nur beschwehren wenn die Range nicht in dem Adressbereich seiner eigenen IP-Adresse ist, Nameserver und Gateway können theoretisch beliebig gesetzt werden.
Ein weiteres Intressantes Feature finde ich auch die Möglichkeit bestimmten Rechnern über DHCP eine feste IP-Adresse zuzuteilen. Um das umzusetzen braucht man erstmal die Ethernet-Adresse der Netzwerkkarten des Clients. Unter FreeBSD lässt man sich diese mittels ifconfig anzeigen oder fischt sie aus dem dmesg (Beispielhaft an meiner Konfiguration):

Code:
# ifconfig de0 | grep ether
        ether 00:c0:95:ec:cd:c2

oder

Code:
gwen% dmesg | grep address
rl0: Ethernet address: 00:48:54:1c:70:84
de0: address 00:c0:95:ec:cd:c2
gwen%

Wie man unter Windows dran kommt weiss ich leider nicht, wenn jemand Infos dazu hat möchte er sich bitte an mich wenden.
Mit den folgenden Einträgen in der dhcpd.conf kann man nun den Ethernet-Addressen bei jedem Boot die gleiche IP-Adresse zuschiessen lassen (wieder beispielhaft an meiner Konfiguration):

Code:
host rechner-name {
        hardware ethernet 00:50:04:56:2b:79;
        fixed-address 192.168.0.102;
}

Der dhcpd installiert ein Startscript in /usr/local/etc/rc.d das wir mit den folgenden Komando zum nächsten Systemstart ausführen.

Code:
# cp /usr/local/etc/rc.d/dhcp.conf.sample /usr/local/etc/rc.d/dhcp.conf

Damit sind wir fertig.

Im Anschluss möchte ich noch auf besonders gute Dokumentation verweisen, die mir beim Schreiben des Howtos und vor allem beim Aufsetzen der Konfiguration sehr oft geholfen hat und die ich jedem an's Herz legen kann.
Zum ersten ist Jürgen Graf's exzellentes Howto über das aufsetzen eines OpenBSD Routers zu nennen, gleich danach natürlich auch Udo Erdelhoff's Howto über das Aufsetzen eines FreeBSD Routers.
Mein Wissen über pf verdanke ich vor allem der pf FAQ des OpenBSD Projects.
Last but not Least sind hier auch noch asg, Maledictus und verbalhoodz zu nennen, die mir dabei geholfen haben einige Unstimmigkeiten zu beseitigen.
Wenn du dieses Howto befolgt hast, dir dabei Unstimmigkeiten oder Seltsamkeiten aufgefallen sind oder du einfach nur eine Frage hast, ist dieser Thread die richtige Anlaufstelle.

Gruß
buebo
 
Zuletzt bearbeitet:
Zurück
Oben