====== Vorbereitende Maßnahmen ======
* Scan des Rechners von Niklas ( ich nehme an, der Router)
martin@smart:~/FernUni/FaPra$ sudo nmap -sU -sT niklas-nordhausen.homelinux.net
Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-14 21:57 CEST
Interesting ports on p54890ED1.dip0.t-ipconnect.de (84.137.14.209):
Not shown: 1997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
8089/tcp open unknown
5060/udp open|filtered sip
Nmap done: 1 IP address (1 host up) scanned in 1093.97 seconds
Mir fehlt der Port 1194/udp - aber das kann auch am Scan liegen
* Einrichtung des Terminalprogramms '''screen'''. Dieses Programm ermöglicht die gemeinsame Arbeit
an einem Terminal.
Starten des Programms
# screen
Auflisten aktiver Sessions
# screen -ls
There is a screen on:
5460.pts-1.smart (23.07.2010 23:12:34) (Attached)
1 Socket in /var/run/screen/S-martin.
Einhängen in eine aktive Session
# screen -x 5460
* Zusätzlich zur Minimalinstallation von Debian wurden die Programme '''tcpdump''' und '''nmap''' zur Netzwerkanalyse installiert
====== Konfiguration der Firewall ======
Zunächst habe ich versucht, mit Policy DROP zu arbeiten. Das hat leider nicht geklappt - es war kein
Verbindungsaufbau mehr möglich (weder OpenVPN, noch SSH). Die Firewall arbeitet nun mit Policy ACCEPT und sperrt nach den Regeln alles.
vpn-gateway:/home/bley# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere 192.168.55.22 udp dpt:openvpn state NEW,ESTABLISHED
ACCEPT tcp -- anywhere 10.3.0.1 tcp dpt:ssh state NEW,ESTABLISHED
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- 192.168.55.22 anywhere udp spt:openvpn state RELATED,ESTABLISHED
ACCEPT tcp -- 10.3.0.1 anywhere tcp spt:ssh state RELATED,ESTABLISHED
DROP all -- anywhere anywhere
Im Verzeichnis ''/home/bley'' liegen die beiden Scripte ''fw.sh'' zum starten der FW und ''fw_stop.sh''
zum stoppen. Bei Änderungen an dem Script, erstelle ich zunächst einen CRON-Job mit dem Kommando ''crontab -l'', der die Firewall zur angegebenen Zeit zunächst wieder zurücksetzt - somit ist gewährleistet, dass man
den Server wieder erreichen kann.
Im Verzeichnis ''/tmp/'' werden die Ausgabe des CRON-Jobs, sowie die zuletzt aktivierten Regeln ausgegeben.
====== Konfiguration des OpenVPN Servers ======
Die Dokumentation zu den einzelnen Parametern bitte der Konfigurationsdatei ''/etc/openvpn/server.conf'' entnehmen. Hier noch einige ergänzende Hinweise.
Die IP Adressen können nicht wie geplant vergeben werden. Jeder Client benötigt für die VPN Verbindung ein eigenenes /30 Netzwerk. Als Erklärung folgendes aus dem OpenPVN Wiki:
----
**Why does OpenVPN's "ifconfig-pool" option use a /30 subnet (4 private IP addresses per client) when used in TUN mode?**
OpenVPN allocates one /30 subnet per client in order to provide compatibility with Windows clients due to the limitation of the TAP-Win32 driver's TUN emulation mode.
If you know that only non-Windows clients will be connecting to your OpenVPN server, you can avoid this behavior by using the ifconfig-pool-linear directive.
In OpenVPN 1.6, when you had to run one OpenVPN instance per client, then it would be more like you expected: a PtP link between the server and each client.
In 2.0 however, OpenVPN can handle multiple clients with only one tun interface on the server. To handle this, you can think of the PtP link you see on server as a link between the operating system and OpenVPN. Then when you're inside OpenVPN, another PtP link needs to created to each client. If all O/S would have supported true PtP links over the tun interface, this could have been done with the OpenVPN server using only one IP address and each client using another IP address.
But, as the TUN/TAP driver implementation on Windows does not support true PtP links, this is emulated through a /30 subnet.
So, you first have a PtP link 192.168.1.1 <-> 192.168.1.2 between your server O/S and OpenVPN on the server.
Then OpenVPN assigns a /30 subnet for each client that connets. The first available /30 subnet (after the one the server is using) is:
* 192.168.1.4/30
* 192.168.1.4 -- Network address
* 192.168.1.5 -- Virtual IP address in the OpenVPN Server
* 192.168.1.6 -- Assigned to the client
* 192.168.1.7 -- Broadcast address.
Then to reach the rest of the network on behind the OpenVPN server, you push a route to the client, so traffic is routed through 192.168.1.5.
As 192.168.1.5 is only a virtual IP address inside the OpenVPN server, used as an endpoint for routes, OpenVPN doesn't bother to answer pings on this address, while the 192.168.1.1 is a real IP address in the servers O/S, so it will reply to pings.
It does cause a little waste of IP addresses, but it's the best way to allow a consistent configuration that works on all O/S supported by OpenVPN.
The TAP-Win32 driver includes a DHCP server which assigns the 192.168.1.6 address to you, that's why you see 192.168.1.5 as DHCP server address.
Hope I made things a little clearer.
Mathias Sundman
----
Deshalb wurden die [[fernuni:netzwerk|Clientnetze]] angepasst und am Server entsprechende Routen gepusht (siehe Konfiguration).
===== Offene Fragen =====
* Warum UDP?
* Warum TUN. Unterschied zu TAP (Layer 2/3)