Bitte beachten: seit Mai 2014 verwende ich FLI4L nicht mehr. Die folgenden Informationen werden nur zu Archivzwecken aufbewahrt.
(Mit kleinen Ergänzungen von Daniel Gehre)
Die Informationen hier beziehen sich auf FLI4L 2.0.8 und sind nicht ohne weiteres auf neuere FLI4L-Versionen übertragbar! Bei FLI4L 3.0.0 oder neuer kann man OpenVPN oder OPT_POPTOP einsetzen und eine ähnliche Lösung erreichen.
Die einfachste Variante, ein WLAN in Betrieb zu nehmen, ist das Anschliessen eines AccessPoints am selben Switch, an dem auch alle übrigen PCs hängen und der Einbau von WLAN-Karten in die Client-PCs. Diese Methode reisst aber ein gravierendes Sicherheitsloch auf, da jeder potentielle Angreifer in der Nähe bequem mit einem Notebook und WLAN-Karte alle Datenpakete mitschneiden kann! Eine Verschlüsselung mit WEP stellt dabei keine ausreichende Sicherheit dar – diese Art Verschlüsselung ist mit vertretbarem Aufwand „knackbar“. Auch ein „Schutz“ durch eintragen berechtigter MAC-Adressen oder „verstecken“ des WLAN-Netzes, indem man die automatische Bekanntgabe der SSID durch den AccessPoint abschaltet, verhindert nicht das passive Lesen der ausgetauschten Daten. MAC-Adressen lassen sich zudem recht leicht „fälschen“.
Als Alternative bleibt daher nur, das WLAN-Netz vom übrigen LAN komplett zu trennen, indem man den AccessPoint an eine eigene Netzwerkkarte anschliesst und den Zugang zusätzlich mit einem VPN absichert.
Ein möglicher Angreifer hat zwar immer noch Zugriff auf das WLAN, aber er kommt nicht sehr weit damit, da der gesamte Datenverkehr verschlüsselt erfolgt und ein Zugriff auf das LAN nur durch einen VPN-Tunnel hindurch möglich ist. Die „öffentliche“ Adresse des AccessPoint ist nur noch für den Aufbau der VPN-Verbindung erreichbar.
Ich habe mich zum Einsatz von OPT_VPND entschlossen, da Windows-Clients hier ohne zusätzliche Software eine Verbindung aufbauen können.
Netzwerkkarten
Im FLI4L sind drei Netzwerkkarten verbaut:
eth0: Anbindung zum LAN (RTL8139, 192.168.2.0/24)
eth1: Anbindung zum WLAN (RTL8139, 192.168.3.0/24)
eth2: DSL (NE2000)
Der Access-Point hängt an der WLAN-Anbindung und erhält seine eigene IP-Adresse, z.B. 192.168.3.2. Das 3er Subnetz dient nur als „Transitnetz“ für die Verbindung zwischen dem VPN-Server, dem Access-Point und den VPN-Clients. Daher braucht das Netz auch nicht maskiert zu werden, da aus diesem Netz keine Anfragen an das WAN gesendet werden (sollten). [dg]
FLI4L selbst ist unter der Adresse 192.168.2.1 erreichbar, der VPN-Server unter 192.168.3.1.
Die Netzkonfiguration dazu:
ETH_DRV_N='2' ETH_DRV_1='8139too' ETH_DRV_1_OPTION='' ETH_DRV_2='ne' ETH_DRV_2_OPTION='irq=9 io=0x300' IP_ETH_N='2' IP_ETH_1_NAME='' IP_ETH_1_IPADDR='192.168.2.1' IP_ETH_1_NETWORK='192.168.2.0' IP_ETH_1_NETMASK='255.255.255.0' IP_ETH_2_NAME='' IP_ETH_2_IPADDR='192.168.3.1' IP_ETH_2_NETWORK='192.168.3.0' IP_ETH_2_NETMASK='255.255.255.0'
Der erste Treiber übernimmt die Ansteuerung der beiden PCI-Karten. Ursprünglich habe ich hier rtl8139 verwendet. 8139too hat sich aber als deutlich stabiler erwiesen. Da der Treiber zuerst geladen wird, erscheinen die Netzwerkkarten als Interface eth0 und eth1. Der zweite Treiber wird für die ISA-Netzwerkkarte verwendet und benötigt zusätzlich die Angabe des Interrupts und der IO-Adresse, die auf der Karte per Jumper eingestellt wurden und in der Plug&Play-Konfiguration des BIOS für ISA-Karten reserviert wurden.
Konfiguration des VPN-Servers
OPT_VPND wurde wie folgt konfiguriert:
OPT_VPND='yes' VPND_DEBUG='no' VPND_IPADDR='192.168.3.1' VPND_REMOTE='192.168.4.1-9' VPND_NTDOMAIN='' VPND_WINSADDR='' VPND_USER_N='1' VPND_USER_1_USER='xxxx' VPND_USER_1_PASS='xxxx' VPND_USER_1_IP=''
Dadurch erhalten Clients, die per VPN verbunden sind, eine IP-Adresse aus dem Adressbereich 192.168.4.1 bis 192.168.4.9. WICHTIG: Für Benutzername und Passwort sollte eine lange und möglichst „wirre“ Zeichenfolge verwendet werden, da man sonst möglicherweise wieder eine andere Sicherheitslücke aufreisst! Damit darüber auch ein Internetzugang möglich ist, wurde in der FLI4L-Grundkonfiguration das Netz zusätzlich maskiert:
MASQ_NETWORK='192.168.2.0/24 192.168.4.0/24'
Die eigentliche Verbindung zum VPN-Server läuft dabei weiterhin über das 3er Subnetz. Der VPN-Tunnel wird jedoch über das virtuelle 4er Netz errichtet. Die Separierung der beiden Netze (Transitnetz und VPN-Tunnel) ermöglicht eine saubere Konfiguration des Paketfilters. [dg]
Weitere Anpassungen
Mit der bisher gezeigten Konfiguration ist die Lösung prinzipiell schon lauffähig, allerdings ist aus dem WLAN heraus immer noch ein Zugriff auf den Router ohne vorherige Anmeldung via VPN möglich. Um nun auch noch den Zugriff vom WLAN aus ausschliesslich auf den VPN-Server zu beschränken, kann das Paket OPT_WLAN_NIC eingesetzt werden. Es sorgt dafür, dass zusätzliche ipchains-Regeln eingefügt werden, die Zugriffe aus dem WLAN-Netz entsprechend beschränken.
Meine früheren Ausführungen zu diesem Thema nehme ich hiermit zurück – sowohl das beschriebene Forwarding in Anlehnung an OPT_BCRELAY als auch die durch OPT_WLAN_NIC hinfällig gewordenen ipchains-Regeln waren ziemlich sinnfrei. Aber man kann immer etwas dazulernen ;-)
Besonderheiten für die Client-Konfiguration
Die WLAN-Netzwerkkarte wird auf das Transitnetz konfiguriert (z.B. 192.168.3.3). [dg]
Der VPN-Server ist mit Windows 2000 und Windows XP direkt nutzbar. Dazu muss lediglich eine neue Netzwerkverbindung für die „Verbindung mit dem Netzwerk am Arbeitsplatz“ unter Verwendung von VPN eingerichtet werden. Als Serveradresse ist 192.168.3.1 anzugeben, Benutzername und Passwort entsprechend den Angaben der OPT_VPND-Konfiguration. Damit auch DNS-Anfragen klappen, muss man allerdings die Adresse des Nameservers in den Verbindungseigenschaften fest vorgeben und dafür die Adresse 192.168.2.1 eintragen – der VPN-Server liefert nämlich normalerweise 192.168.3.1 als DNS-Adresse zurück. Da aber über diese Adresse aber kein Nameserver erreichbar ist, müssen die Anfragen explizit über 192.168.2.1 laufen.
Probleme mit „Hängern“ bei Dateiübertragung zwischen LAN und WLAN
Mittlerweile (Stand März 2004) wurde auch von anderen Leuten bestätigt, dass es bei der Übertragung grösserer Datenmengen zwischen LAN und WLAN Probleme mit dem PPTP-Server gibt, wenn die Bandbreite eine bestimmte Grenze überschreitet. Solange man nur die Internet-Verbindung im Router nutzt (bei mir derzeit max. 180 kB pro Sekunde), ist es auch über Stunden problemlos nutzbar. Sobald man aber grössere Dateien direkt aus dem LAN in Richtung WLAN übertragen will, „hängt“ irgendwann die PPTP-Verbindung nach kurzer Zeit. Leider gibt es auch keine Einträge im syslog, anhand derer man das Problem genauer eingrenzen könnte.
PPTP-Zugang auch für Clients im Internet
Prinzipiell ist die hier gezeigte Konfiguration auch für Clients nutzbar, die von außen zugreifen. Allerdings reagiert der Server nur „intern“ auf der Adresse 192.168.3.1 und ist daher von außen nicht ansprechbar.
Abhilfe ist die Verwendung der Adresse 0.0.0.0, die dafür sorgt, dass der Server auf allen Netzwerkschnittstelllen ansprechbar ist – also auch über die Internetverbindung von außen:
VPND_IPADDR='0.0.0.0'
Ggf. sind dafür auch Paketfilterregeln anzupassen – der Port 1723 tcp/udp muss von außen zugänglich sein, d.h. dieser Port darf nicht gesperrt sein. Des weiteren ist es sinnvoll, einen DynDNS-Dienst und das Paket OPT_DYNDNS zu verwenden, damit der Router über einen Domain-Namen ansprechbar ist.
