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
'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
'tcpdump' und 'nmap' zur Netzwerkanalyse installiertZunä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.
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:
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 Clientnetze angepasst und am Server entsprechende Routen gepusht (siehe Konfiguration).