Viele nutzen Linux im privaten bereich als Gateway für das eigene LAN zum Internet. Ich persönlich bevorzuge FreeBSD da ich mit FreeBSD besser klar komme als mit irgendeiner Linux Distribution. Folgender Text soll zeigen, wie man eine frisch-installierte FreeBSD Box dazu bringt sich via T-DSL mit ins Internet „einzuwählen“ und das LAN über IPFW und NATd ins Internet bringt.
Der Text bezieht sich auf ein FreeBSD System (4.6 bis 5.0) mit funktionierendem TCP/IP-Stack!
Kernelkonfiguration
cd /usr/src/sys/i386/conf
cp GENERIC FIREWALL # anstatt FIREWALL kann ein beliebiger Name gewählt werden
edit FIREWALL # edit kann durch den Editor deiner Wahl ersetzt werden (vi, vim, joe)
Zu den bestehenden Kernel-Optionen werden folgende hinzugefügt:
options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT # ! VORISCHT ! Alles was nicht explizit Verboten ist, ist erlaubt
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=30
options DUMMYNET
options IPDIVERT
options IPFILTER
options IPFILTER_LOG
options IPSTEALTH
options RANDOM_IP_ID
options TCP_DROP_SYNFIN
Nun wird der Kernel konfiguriert:
config -r FIREWALL
cd ../../compile/FIREWALL
make depend; make; make install
Nun packst du dir deine Freundin/deinen Freund, setzt dich mit ihr/ihm an den Tisch, trinkst in Ruhe ein Käffchen und quatsch euch mal aus…
Wenn alles gut ging, dann sollte der neue Kernel dann fertig kompiliert und installiert sein. Jetzt das große Hoffen und Daumendrücken:
reboot
Im Normalfall bootet das System anständig neu mit dem neuen Kernel (wenn nicht, wenden sie sich an ihren Administrator oder den nächsten Experten ihrer Wahl)
Routing
Als nächstest erstellen wir uns eine Konfigurationsdatei die Network Address Translation (NATd):
edit /etc/natd.conf
Für die jenigen, die Battlecom nutzen wollen, hier die Zeilen für NATd:
redirect_port tcp 192.168.0.1:2300-2400 2300-2400
redirect_port tcp 192.168.0.1:47624 47624
redirect_port udp 192.168.0.1:2300-2400 2300-2400
Nachdem wir die Datei gespeichert haben, müssen wir das Forwarding aktivieren:
sysctl -w net.inet.ip.forwarding=1
echo firewall_enable="YES" >> /etc/rc.conf
(x) echo firewall_logging="YES" >> /etc/rc.conf
echo firewall_script="/etc/fw.rc" >> /etc/rc.conf
echo gateway_enable="YES" >> /etc/rc.conf
echo natd_enable="YES" >> /etc/rc.conf
echo natd_interface="tun0" >> /etc/rc.conf
echo natd_flags="-dynamic -config /etc/natd.conf" >> /etc/rc.conf
(x) echo tcp_drop_synfin="YES" >> /etc/rc.conf
(x) echo icmp_log_redirect="YES" >> /etc/rc.conf
(x) echo icmp_drop_redirect="YES" >> /etc/rc.conf
Legende: (x) = optionale (aber empfohlene) Sicherheitsoptionen, haben nichts mit dem Forwarding zu tun
Als nächstes legen wir die Datei für die Filterregeln an:
edit /etc/fw.rc
fwcmd="/sbin/ipfw"
$fwcmd -f flush
$fwcmd add divert natd all from any to any via tun0
$fwcmd add 400 allow tcp from any to any out xmit tun0 setup
$fwcmd add 500 allow tcp from any to any via tun0 established
### einzelne Ports freigeben für den externen Zugriff auf interne Dienste ###
$fwcmd add 600 allow tcp from any to any 80 setup # httpd
$fwcmd add 650 allow tcp from any to any 21 setup # ftpd
$fwcmd add 650 allow tcp from any to any 20 setup # ftpd
$fwcmd add 700 allow tcp from any to any 22 setup # sshd
### Nur Rechnern aus dem Netz 192.168.0.0/24 den Zugriff auf den SQLd gewähren ###
$fwcmd add 850 allow tcp from 192.168.0.0/24 to 3306 setup
### Zugriffe auf einzelne Ports verweigern und loggen ###
$fwcmd add 900 reset log tcp from any to any 113 in recv tun0
### Den Datentransfer zwischen den LAN und den DNS-Servern erlauben ###
$fwcmd add 1000 allow udp from any to 212.185.253.70 53 out xmit tun0
$fwcmd add 1100 allow udp from any to 217.5.115.205 53 out xmit tun0
$fwcmd add 1200 allow udp from any to 194.25.2.129 53 out xmit tun0
$fwcmd add 1300 allow udp from 212.185.253.70 53 to any in recv tun0
$fwcmd add 1400 allow udp from 217.5.115.205 53 to any in recv tun0
$fwcmd add 1500 allow udp from 194.25.2.129 53 to any in recv tun0
Das waren mal ein paar Beispielregeln für IPFW. Hier sind soweit keine Grenzen gesetzt. Das Forwarding wäre hiermit erledigt!
Einwahl
Einwahl bei t-online über tdsl (PPPoE)
Editiere /etc/ppp/ppp.conf :
#################################################################
# PPP Sample Configuration File
# Originally written by Toshiharu OHNO
# Simplified 5/14/1999 by wself@cdrom.com
#
# See /usr/share/examples/ppp/ for some examples
#
# $FreeBSD: src/etc/ppp/ppp.conf,v 1.2.2.5 2001/07/13 10:55:23 brian Exp $
#################################################################
default:
set log Phase Chat LCP IPCP CCP tun command
ident user-ppp VERSION (built COMPILATIONDATE)
# Ensure that "device" references the correct serial port
# for your modem. (cuaa0 = COM1, cuaa1 = COM2)
#
set device /dev/cuaa1
set speed 115200
set dial "ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5
"" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT"
set timeout 180 # 3 minute idle timer (the default)
enable dns # request DNS info (for resolv.conf)
tdsl:
set device PPPoE:dc1 # dc1 ist meine NIC die einwählen soll
set MTU 1492
set MRU 1492
set timeout 0
set dial
set crtscts off
set speed sync
accept lqr
disable deflate
disable pred1
disable vjcomp
disable acfcomp
disable protocomp
#enable dns
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 "<12-stellige-anschlusskennung><12-stellige-anschluss-Nummer>#0001@t-online.de"
set authkey "dein-passwort"
Der teil „default“ ist eher unwichtig, uns geht es um den Abschnitt „tdsl“.
Mit folgendem Befehl stellen wir nun die Verbindung zum Internet her und wir können fröhlich drauflos surfen, chatten, zocken oder was immer man da so machen kann und will:
ppp -ddial tdsl
Mit dem Befehl
ppp -auto tdsl
richtet man Dial on Demand ein.
Viel Spaß!
redbrick
redbrick (01.04.2008 22:00:12)
Ich habe nochmal etwas gegoogled und habe u.U. etwas passendes für das Problem gefunden.
Schau dir mal http://mpd.sourceforge.net/ an.
redbrick (01.04.2008 14:23:05)
Vielen Dank für das Lob.
Leider muss ich dir sagen, dann ich in der von dir beschriebenen Thematik nicht wirklich viel Ahnung habe. Als ich vor einigen Jahren mit FreeBSD begonnen habe, habe ich mir von den Jungs aus dem Quakenet IRC-Channel #freebsd.de Hinweise geben lassen und nach erfolgreicher Umsetzung alles dokumentiert und als Tutorial online gestellt.
Aus diesem Grund empfehle ich dir, einfach mal in dem Quakenet-Channel #freebsd.de vorbeizuschauen und ihnen was auf die nerven zu gehen. ;) Keine Angst, die sind ganz nett .oO(wenn sie nicht gerade gestresst sind *g*).
Wenn dir die Jungs bei deinem Problem helfen können, dann kannst du hier ja nochmal ein Comment hinterlassen.
Ein Blick in die FreeBSD-Doku lohnt in der Regel auch immer. Aber ehrlich gesagt bezweifle ich, dass du dort die Lösung auf dein doch recht spezilles Problem finden wirst. Aber vielleicht verbergen sich dort ja Hinweise, die dich weiterbringen!
Uwe (01.04.2008 13:58:19)
Redbrick,
Super posting! Gibt mir als freeBSD Newbie einen sehr guten Einstieg in die Problematik!
Ich hab mal ne Frage zur anderen Seite:
Ich betreibe einen freeBSD Server.
Die Welt „draussen“ soll sich ueber ihn und
per MODEM(!!)
in ein dahinterliegendes Netzwerk einwaehlen konnen.
(Ja, ich weiss Verbindungsaufbau per Modem / dialup / PPP ist „etwas ausder Mode gekommen“ und ja, ich bin mir der Risiken bewusst.)
Solange ich TCP/IP benutze kann ich mich reibungslos per Modem / PPP / dial einwaehlen. Zu Testzwecken habe ich auf einem Windows(!) Rechner eine Dialup Verbindung mit einem 33.600 Standard Modem erzeugt und ein prg. geschrieben das auf der einen Seite einen virtuellen COM port zur Verfuegung stellt, diese virtuelle Schnittstelle zum Modem hin handhabt und auf der anderen Seite eine Verbindung zum freeBSD Server aufbaut. Klingt kompliziert – und ist es auch ;-)
Solange die Seite zum freeBSD Server TCP/IP benutzt funktioniert alles wunderbar!
(User und PW sind in der Windows Dialup Definition hinterlegt).
Da Problem ist nun, das ich auch UDP (also „Verbindungslos“) verwenden moechte. Und genau das klappt irgendwie nicht.
Das ganze bleibt in der Phase „Verifying User and PW“ stehen.
Ich vermute, das ich zuerst per TCP/IP die Verbindung als solche (also mit User/PW Abfrage, handshakes, etc., etc.) erledigen muss und erst danach, wenn ich connectet bin auf UDP umschalten kann. ODer liege ich (auch) hier falsch ?
Jeglich Hilfe waere echt Klasse.
Vielen, vielen Dank im Voaus!
Kommentare