49110
Goto Top

PPTP Server auf Linux Rootserver Defaulroute Probleme

PPTPD läuft, Anmeldung per MS-Chap V2 128 bit funktioniert ebenfalls, Clients können Server pingen, Server kann Clients pingen...Jedoch können die Clients sich nicht untereinander pingen / erreichen, auch das surfen über den PPTP Tunnel ist nicht möglich wenn Standardgateway verwendet wird über den VPN Tunnel.

Beispielhaftes Szenario mit einem Rootserver, einer öffentlichen IP wo die Defaultoute nicht funktioniert:

Bei meinem Rootserver habe ich ein eth interface mit einer festen öffentlichen IP Adresse, diese ist auch extern aus dem internet von überall aus auf der Welt erreichbar und kann deswegen nicht für die Konfiguration des PPTP Servers verwendet werden, hier ein Beispiel. Ihr habt die externe IP Adress 95.95.95.95 unter dieser ist euer Rootserver erreichbar, diese könnt ihr ja schlecht für den PPTP Server verwenden, also verwende ich hier nun z.B. die IP 192.168.0.1 (IP Adresse des PPTP Servers) und den Bereich für die Clients die connecten (192.168.0.2-166). Wie oben beschrieben wählen sich nun zwei Windows XP Cleints ein und bekommen die IP Adressen 192.168.0.2 und 192.168.0.3, beide können den Server 192.168.0.1 pingen, der Server kann auch beide Clients pingen aber untereinander finden sich die zwei Kollegen innerhalb des Tunnels nicht, meine Vermutung, das routing stimmt nicht weil er nicht aus dem 192.168.0.0 netz einfach mal das Gateway für das 95.95.95.1 setzen kann

Beispielhaftes Szenario mit einem Heimnetz, wo die Defaulroute richtig gesetzt wird:

Ihr habt z.B. eine DynDNS Adresse schiessmichtot.dyndns.biz diese zeigt auf euren Router, dort habt ihr GRE und den PPTP Port auf eure Heimische Linuxkiste geforwarded, Diese befindet sich im Netz 192.168.0.0 und hat die IP 192.168.0.2, der Gateway hier ist die 192.168.0.1 also wird im PPTP Server lokale Server IP 192.168.0.2 genommen und die Clients dürfen im bereich 192.168.0.3-166 eine IP belegen. So, nun wählen sich 2 Clients ein, bekommen die 192.168.0.3 und die 192.168.0.4. Beide können den Server pingen, der Server kann die Clients pingen und untereinander können sich die Clients ebenfalls pingen! Hier wird die Defaultroute richtig gesetzt, ich kann auch surfen über den VPN Tunnel wenn ich den Standardgateway des Tunnels nutze.

Meine Frage ist nun, wie kann ich dies auf meinem Rootserver umsetzen? Mit einer Bridge!? Mit iptables und NAT? Ich steh etwas auf dem schlauch wo ich anfangen soll und wie. Ich kann ja nicht einfach auf dem root den Gateway in dem Netzwerk verwenden und irgendeine 95.95.95.0 IP weil diese direkt öffentlich geschaltet ist!

Content-Key: 106920

Url: https://administrator.de/contentid/106920

Printed on: April 19, 2024 at 21:04 o'clock

Member: aqui
aqui Jan 23, 2009 at 10:26:27 (UTC)
Goto Top
Du machst einen Denkfehler beim Thema PPTP Server !! Natürlich muss dein PPTP Server über die 95.95.95.95 erreichbar sein, denn sonst könntest du niemals von überallher einen VPN Tunnel auf bauen...logisch ! Wie du ja sicher selber weisst ist das IP Netz 192.168.0.0 /24 ein RFC 1918 IP Netz was im Internet gar nicht geroutet wird bzw. nicht vorhanden ist !!!
Intern vergibt der VPN Server dann 192.168.0.0 /24 als internes LAN. Vermutlich über eine Loopback Adresse bei dir im Server ???

Dazu eine wichtige Anmerkung zum Thema VPN: Es zeugt nicht gerade von Intelligenz und Nachdenken bei der Planung bei der Einrichtung von VPN als internes Netzwerk die 192.168.0.0 /24 zu wählen !!! Sorry...
Grund: Jeder dumme DSL Router vom Blödmarkt vom Grabbeltisch, jedes Hotelnetz und jeder der sich NICHT mit IP Adressen auskennt nimmt als Default dieses Netzwerk.
Bei mindestens jedem 2ten VPN Zugriff stürzt dich das dann in große Probleme, denn wenn du lokal 192.168.0.0 /24 als Netzwerk hast und dann in deinem VPN nochmal das gleiche IP Netz bekommst ist dir auch klar, das damit keine saubere VPN Verbindung funktioniert, da du nun 2mal das gleiche IP Netz am Client hast und kein Client damit umgehen kann face-sad

Es wäre also weitaus intelligenter bei einem VPN Netz serverseitig etwas exotischeres als IP Netz aus dem RFC 1918 Pool:
http://de.wikipedia.org/wiki/Private_IP-Adresse
zu verwenden, damit es nicht zu lokalen IP Konflikten im Client Netz kommt !!!
Also solltest du besser sowas verwenden wie 172.28.7.0 /24 mit einer 24 Bit Maske 255.255.255.0 um dem sicher vorzubeugen !!

Vermutlich ist das auch die Ursache deines Problems...doppelte IP Netzemit der 192.168.0.0 !!??
Wenn nicht, dann ist es die Firewall der Clients, die nur IPs aus dem lokalen Netz zulässt, niemals aber IPs aus dem VPN Netz !!
Du musst also die lokale Firewall entsprechend customizen und öffnen für das VPN IP Netz, dann wirds auch was mit der Client zu Client Verbindung !!
Ein route print oder tracert zeigt dir immer die Wege im Netz an !!
Mitglied: 49110
49110 Jan 23, 2009 at 11:04:54 (UTC)
Goto Top
Danke für deine Antwort aqui klar habe ich einen denkfehler sonst würde es ja auch funktionieren, eins vorweg, klar setze ich für das VPN netz nicht die 192.168.0.0 oder 192.168.1.0 ein face-smile das war nur ein Beistpiel für eine IP Adresse um mal schnell zu erklären um was es hier überhaupt geht!

RFC 1918 IP Netz hin oder her, folgendes:

Auf dem Rootserver hat das eth0 Interface eine IP die direkt ohne Router oder Firewall im WAN / GAN hängt, sinngemäß ohne Hardware Firewall oder Router, man ist bei einem Rootserver selbst verantwortlich eine Firewall zu betreiben, Grundsätlich steht die Linuxkiste also direkt im Netz, so wie wenn du deinen Linux PC direkt ohne Router per PPOE einwählst. Das ist das Grundprinzip eines Rootservers ;) klar du musst ja auch alles selbst machen können. Noch einen schritt weiter...es gibt ein riesiges Routingproblem wenn ich mich also z.B. mit dem PPTP ins das 95.95.95.0 klinken würde. Weil z.B. auf 95.95.95.2 dein rootserver liegt und sich mein Win XP client jetzt die IP Adresse innerhalb des Tunnels reserviert also könnte ich deinen Root nicht mehr erreichen ;)

Nun zu einem Heimischen Linuxrechner,der hat das eth0 Interface, eben eine IP in einem LAN hinter einem Router und hängt nicht direkt im Internet, also ein Himmelweiter unterschied. Der Router bringt dich mittels Gateway erst ins WAN / GAN. In diesem Sinne hast du beim Rootserver kein LAN sondern hängst direkt im WAN, verstehst du was ich meine?

Ich bin in der Materia schon etwas fitter, traceroute, route unter linux oder auch tracert und route print unter Windows sind mir durchaus gängige Begriffe. Auf den Clients sind alle Firewalls deaktiviert damit eben mittels traceroute und ping getestet werden kann.

Nun, es geht also nach wie vor um die Defaultroute auf dem Rootserver. Ich bin mir sicher dass es hier jemand gibt der mir gleich sagen wird dass dies mittels IPTables machbar ist, oder einer virtuell Konfigurierten eth1 und oder eine bridge...In die Richtung geht das, bin ich mir fast sicher, hab ich aber noch nie gemacht ausser bei VMWare / VBox, so schwierig kanns nicht sein!
Member: aqui
aqui Jan 23, 2009 at 11:20:53 (UTC)
Goto Top
Scheinbar ist dir die Funktion von PPTP nicht wirklich bekannt.
Der Tunnel hat niemals eine Verbindung ins 959595.0er Netz und stellt auch niemals so eine her...da bleibt es bei deinem Denkfehler !! Der auch klar wird, liest man mal dieses:
http://technet.microsoft.com/en-us/library/cc768084.aspx

Die 95.95.95.2 stellt lediglich den Tunnelendpunkt her, hat aber mit dem eigentlichen VPN nichts zu tun. Innerhalb dieses Tunnels vergibt dein Linux Server dann ein RFC 1918 IP Netz, welches auch immer du intelligent auswählst.....
Dein Client bekommt auch eine Interface IP Adresse aus diesem RFC 1918 Bereich, was du auch ganz klar mit ipconfig am Client sehen kannst wenn der Tunnel steht.
Das VPN Netz verhält sich also routingtechnisch wie eine direkte Kabelverbindung zwischen Client und Server ! Logischerweise muss der Server dafür ein Loopback Interface in diesem VPN Netzwerk haben !

Das 95er Netz ist dabei völlig irrelevant und spielt für den Client keine Rolle, denn dahin geht er ja über die normale öffentliche Verbindung sei es DSL oder was auch immer....niemals aber über die VPN Verbindung !!!
Deinen Server kannst du also über die öffentliche verbindung und 95er Adresse erreichen oder über den VPN Tunnel über die Loopback Adresse ! Die Loopback ist ja ein weitere virtueller Adapter.

Stellst du nun den VPN Client so ein das bei aktivem Tunnel das VPN Gateway (sprich der Server) dann sein default Gateway ist schickt der PPTP Client ALLES was nicht für sein lokales Netz am LAN ist in den Tunnel.

Das macht man ja normalerweise nicht, nur wenn man den Internetzugang wirklich komplett über den Tunnel abwickeln will, was ja auch geht...keine Frage.

Logischerweise muss nun natürlich der Server mit IP Tables NAT machen auf sein 95.95.95.2er Interface, damit der Traffic aus dem VPN Tunnel ins Internet kann.
DAS musst du also customizen am Server !! Mit Routen hat das nix zu tun, das das VPN Interface ja direkt am Server hängt und er es folglich also kennt und dafür nicht routen muss !!
Mitglied: 49110
49110 Jan 23, 2009 at 14:39:47 (UTC)
Goto Top
Okey, danke für die infos. Demnach ein NAT mit source 192.168.0.0/24 auf destination 95.95.95.0/24 !?

Meinst es reicht als Beispiel ein:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNAT --to-destination 95.95.95.0/24
Mitglied: 49110
49110 Jan 29, 2009 at 10:33:50 (UTC)
Goto Top
Also ich komm kein stück weiter mit den "iptables" hab jetzt 3 tage mit googeln verbracht und irgendwie komm ich nicht zurecht, die tcpdumps aufm root hauen mir kilometerlange logs um die ohren, ich hab ungefähr 10x den Server neu starten müssen (hab zusätzlich noch versucht ne VMWare mit bridge/host/nat zum laufen zu bringen, vergeblich, aber das ist ne andere geschichte)...dabei sind das bestimmt 2 zeilen die reichen würden das es funktioniert....zumindest hab ich es niemals hinbekommen dass sich die PPTP Clients untereinander finden (egal ob ping oder sonst was 2x windows xp OHNE FIREWALL), da scheint mir ebenfalls ein iptables eintrag zu fehlen, wenn ich meine iptables basierende firewall abschalte können sich die pptp clients untereinander auch nicht pingen, die defaultroute funktioniert ebenfalls immer noch nicht ;) also könnte ich innerhalb des tunnels (wenn man den standardgateway des tunnels verwendet) kein google.de oder sonstiges auflösen weil das RFC 1918 IP Netz nicht richtig genattet wird. Hier mal meine IPTables Firewall...: klar fehlen ein paar einträge diese wurden absichtlich entfernt und die IP's sind andere (Zeile 91 bis 98)....:

#!/bin/bash
# ---- My Ruley Firewall xD ----

case "$1" in  
  start)
    echo "Starte IP-Paketfilter"  
    echo "1" > /proc/sys/net/ipv4/ip_forward  
    echo "1" > /proc/sys/net/ipv4/ip_dynaddr  

    # iptables-Modul
    modprobe ip_tables
    # Connection-Tracking-Module
    modprobe ip_conntrack
    # Das Modul ip_conntrack_irc ist erst bei Kerneln >= 2.4.19 verfuegbar
    modprobe ip_conntrack_irc
    modprobe ip_conntrack_ftp

    # Tabelle flushen
    iptables -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -X
    iptables -t nat -X
    iptables -t mangle -X

    # Default-Policies setzen
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP
    iptables -P FORWARD DROP

    # MY_REJECT-Chain
    iptables -N MY_REJECT

    # MY_REJECT fuellen
    iptables -A MY_REJECT -p tcp -m limit --limit 7200/h -j LOG --log-prefix "REJECT TCP "  
    iptables -A MY_REJECT -p tcp -j REJECT --reject-with tcp-reset
    iptables -A MY_REJECT -p udp -m limit --limit 7200/h -j LOG --log-prefix "REJECT UDP "  
    iptables -A MY_REJECT -p udp -j REJECT --reject-with icmp-port-unreachable
    iptables -A MY_REJECT -p icmp -m limit --limit 7200/h -j LOG --log-prefix "DROP ICMP "  
    iptables -A MY_REJECT -p icmp -j DROP
    iptables -A MY_REJECT -m limit --limit 7200/h -j LOG --log-prefix "REJECT OTHER "  
    iptables -A MY_REJECT -j REJECT --reject-with icmp-proto-unreachable

    # MY_DROP-Chain
    iptables -N MY_DROP
    iptables -A MY_DROP -m limit --limit 7200/h -j LOG --log-prefix "PORTSCAN DROP "  
    iptables -A MY_DROP -j DROP

    # Alle verworfenen Pakete protokollieren
    iptables -A INPUT -m state --state INVALID -m limit --limit 7200/h -j LOG --log-prefix "INPUT INVALID "  
    iptables -A OUTPUT -m state --state INVALID -m limit --limit 7200/h -j LOG --log-prefix "OUTPUT INVALID "  

    # Korrupte Pakete zurueckweisen
    iptables -A INPUT -m state --state INVALID -j DROP
    iptables -A OUTPUT -m state --state INVALID -j DROP

    # Stealth Scans etc. DROPpen
    # Keine Flags gesetzt
    iptables -A INPUT -p tcp --tcp-flags ALL NONE -j MY_DROP

    # SYN und FIN gesetzt
    iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j MY_DROP

    # SYN und RST gleichzeitig gesetzt
    iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j MY_DROP

    # FIN und RST gleichzeitig gesetzt
    iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j MY_DROP

    # FIN ohne ACK
    iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j MY_DROP

    # PSH ohne ACK
    iptables -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j MY_DROP

    # URG ohne ACK
    iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j MY_DROP

    # Loopback-Netzwerk-Kommunikation zulassen
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT

    # Connection-Tracking aktivieren
    iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT





    #Erlaube PPTP / GRE
    iptables -A INPUT -d 95.95.95.95 -m state --state NEW -p gre -j ACCEPT
    iptables -A OUTPUT -d 95.95.95.95 -m state --state NEW -p gre -j ACCEPT
    iptables -A INPUT -d 95.95.95.95 -m state --state NEW -p tcp --dport 1723 -j ACCEPT

    #Erlaube Datenverkehr PPTP VPN
    iptables -A INPUT -d 192.168.0.0/24 -s 192.168.0.0/24 -j ACCEPT
    iptables -A OUTPUT -d 192.168.0.0/24 -s 192.168.0.0/24 -j ACCEPT





    #Default-Policies mit REJECT
    iptables -A INPUT -j MY_REJECT
    iptables -A OUTPUT -j MY_REJECT

    # Max. 500/Sekunde (5/Jiffie) senden
    echo 5 > /proc/sys/net/ipv4/icmp_ratelimit

    # Speicherallozierung und -timing füDe/-Fragmentierung
    echo 262144 > /proc/sys/net/ipv4/ipfrag_high_thresh
    echo 196608 > /proc/sys/net/ipv4/ipfrag_low_thresh
    echo 30 > /proc/sys/net/ipv4/ipfrag_time

    # TCP-FIN-Timeout zum Schutz vor DoS-Attacken setzen
    echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

    # Maximal 3 Antworten auf ein TCP-SYN
    echo 3 > /proc/sys/net/ipv4/tcp_retries1

    # TCP-Pakete maximal 15x wiederholen
    echo 15 > /proc/sys/net/ipv4/tcp_retries2

    ;;

  stop)
    echo "Stoppe IP-Paketfilter"  
    # Tabelle flushen
    iptables -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -X
    iptables -t nat -X
    iptables -t mangle -X
    echo "Deaktiviere IP-Routing"  
    echo 0 > /proc/sys/net/ipv4/ip_forward

    # Default-Policies setzen
    iptables -P INPUT ACCEPT
    iptables -P OUTPUT ACCEPT
    iptables -P FORWARD ACCEPT
    ;;

  status)
    echo "Tabelle filter"  
    iptables -L -vn
    echo "Tabelle nat"  
    iptables -t nat -L -vn
    echo "Tabelle mangle"  
    iptables -t mangle -L -vn
    ;;

  restart)
    /etc/init.d/firewall stop
    sleep 2
    /etc/init.d/firewall start
    ;;

  *)
    echo "Fehlerhafter Aufruf"  
    echo "Syntax: $0 {start|stop|restart|status}"  
    exit 1
    ;;

esac