scifire
Anmeldungsdatum: 5. Mai 2013
Beiträge: Zähle...
|
Hallo zusammen, ich stehe derzeit vor folgendem Problem und vielleicht kann mir ja hier einer weiterhelfen:
Mein vServer hat 2 VPN´s am laufen:
das erste ist OpenVPN welches ich nutze um mich zum Beispiel mit dem Smartphone o.ä. in öffentlichen WLAN abzusichern. (IP Bereich 10.8.0.X/24)
das zweite ist fastd hier besteht eine dauerhafte Verbindung in ein bestehendes Netzwerk (IP Bereich 10.185.X.X/16) Vom Server aus kann ich logischerweise beide Netze voll nutzen.
Ich würde jedoch gerne auch vom Smartphone auf das andere VPN zugreifen können. Hier meine rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
iptables -t nat -F POSTROUTING
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 172.31.1.100
#Internet Route VPN
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -o eth0 -i tun0 -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#Freifunk Rote
exit 0
Wäre cool wenn mir hierbei jemmand weiterhelfen könnte. Grüße
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Deine rc.local hilft da wenig. Wie sieht denn die OpenVPN-Konfiguration aus? Welche Routen pushst du auf das Smartphone?
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
Folgendes push ich aufs Smartphone push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 2XX.67.2XX.222"
push "dhcp-option DNS 2XX.67.2XX.220"
Ich habe auch schon versucht eine route ins 10.185 zu pushen, da hat leider jedoch nicht funtkioniert.
push "route 10.185.0.0 255.255.0.0" Ansonsten dürfte die Konfig sehr standart sein bzw so wie es hier im Wiki beschrieben wird.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
scifire schrieb: Ich habe auch schon versucht eine route ins 10.185 zu pushen, da hat leider jedoch nicht funtkioniert.
push "route 10.185.0.0 255.255.0.0"
Der zweite Parameter soll nicht die Subnetmaske sein, sondern das Gateway:
| push "route 10.185.0.0 <Gateway-IP>"
|
Da du aber eh den VPN-Server als Default-Gateway nutzt, ist das eigentlich nicht nötig. Gibt es irgendwelche iptables-Regeln die das verhindern? Ist IP-Forwarding auf dem Server aktiviert?
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
IP-Forwarding ist aktiviert. IP-tables dürfte nichts drinnen stehen, zumindest ist mir nichts aufgefallen.
Chain INPUT (policy ACCEPT)
target prot opt source destination
fail2ban-dovecot tcp -- anywhere anywhere multiport d ports smtp,urd,submission,imap2,imap3,imaps,pop3,pop3s
fail2ban-postfix tcp -- anywhere anywhere multiport d ports smtp,urd,submission
fail2ban-vsftpd tcp -- anywhere anywhere multiport dp orts ftp,ftp-data,ftps,ftps-data
fail2ban-ssh tcp -- anywhere anywhere multiport dport s ssh
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.8.0.0/24 anywhere ctstate NEW
ACCEPT all -- anywhere anywhere ctstate RELATED,ES TABLISHED
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain fail2ban-dovecot (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-postfix (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-vsftpd (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Wenn ich statt der Subnetmask das gateway angebe kommt auf dem Client die fehlermeldung "Die Route 10.185.0.0 mit der Netzmaske ... ist keine Route mit einer CIDR-netzmaske..." Sonst noch eine Idee woran das liegen könnte?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
scifire schrieb: Wenn ich statt der Subnetmask das gateway angebe kommt auf dem Client die fehlermeldung "Die Route 10.185.0.0 mit der Netzmaske ... ist keine Route mit einer CIDR-netzmaske..."
Hm, stimmt. Keine Ahnung, wie ich darauf gekommen bin, dass der zweite Parameter das Gateway sein sollte 🙄
Sonst noch eine Idee woran das liegen könnte?
Kannst du von einem Client aus ein traceroute machen? Ich weiß, dass es für Android entsprechende Apps gibt, bei iOS bin ich nicht sicher. Wie sieht eigentlich das Routing auf dem Server aus?
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
Routing: default via 172.31.1.1 dev eth0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
10.185.0.0/18 dev br-fffd proto kernel scope link src 10.185.1.2
172.31.1.0/24 dev eth0 proto kernel scope link src 172.31.1.100 tracert von Windows:
Routenverfolgung zu 10.185.0.2 über maximal 30 Hops
1 63 ms 53 ms 62 ms 10.8.0.1
2 * * * Zeitüberschreitung der Anforderung.
...
Unter Android das gleiche. Es funktioniert auch keine DNS auflösung. So kann ich vom Server aus z.b. scifire.abcd pingen (zeigt entsprechend auf meinen Server) aus dem VPN heraus jedoch nicht (Host niocht gefunden).
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Also ich finde keinen offensichtlichen Fehler. Ich würde fast sagen, dass das IP-Forwarding noch aus ist... Was sagt
| cat /proc/sys/net/ipv4/ip_forward
|
(auf dem Server)
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
1 Ohne IP-Forwarding habe ich ja kein Internet über VPN.
Eventuell ist das jetzt eine blöde Frage aber ich habe bisher ja nur openvpn(bzw dem client) gezeigt wohin das packet gehen soll(push route...), woher weiß das packet den Rückweg?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
scifire schrieb: Eventuell ist das jetzt eine blöde Frage aber ich habe bisher ja nur openvpn(bzw dem client) gezeigt wohin das packet gehen soll(push route...), woher weiß das packet den Rückweg?
Sofern der Server nicht Default-Gateway für das 10.185.0.0-Netz ist muss natürlich dort bei den Clients eine Route gesetzt werden. Das geht aber meines Wissens nicht per fastd, sondern müsste händisch passieren. Ich bin davon ausgegangen, dass der Server Gateway für beide Netze ist.
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
Ich wollte jetzt den server als gateway in /etc/network/interfaces eintragen, jetzt stellt sich mir nur grade die frage "welchen server" ich da eintrage?
Ich habe es mit den Adressen 127.0.0.1, 10.8.0.1 bzw 10.8.0.2 für den OVPN versucht und mit 10.185.1.2 für den fastd. Leider hat keines von beidem funktioniert.
So sieht der eintrag dann aus.
iface br-fffd inet static
address 10.185.1.2
netmask 255.255.192.0
gateway 10.8.0.2
edit: Wie mir grade aufgefallen ist hatte ich eine falsche subnetmask in der OVPN Config stehen. Die habe ich grade korrigiert, leider jedoch ohne veränderung.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
scifire schrieb: Ich wollte jetzt den server als gateway in /etc/network/interfaces eintragen, jetzt stellt sich mir nur grade die frage "welchen server" ich da eintrage?
Das hat nichts mit dem Server zu tun. Du musst den Clients im 10.185.0.0/24-Netz sagen, dass das 10.8.0.0/24-Netz über den Server geroutet wird. Alternativ kannst du auch NATen, also die Source-IP maskieren, genau wie du es für das Internet auch machst (Source-NAT in deiner rc.local).
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
Den Clients kann ich das nicht mitteilen, das ist ein bestehndes Netz an dem ich teilnehme. Wäre das dann richtig?
iptables -t nat -A POSTROUTING -o tun0 -s 10.185.0.0/18 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.185.0.0/18 -j SNAT --to-source 10.8.0.0/24
und
iptables -A FORWARD -o tun0 -i br-fffd -s 10.185.0.0/18 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
scifire schrieb: Wäre das dann richtig?
Nein, meines Erachtens sollte es so aussehen, sofern das Interface an dem das 10.185-Netz anliegt tun0 heißt: iptables -t nat -A POSTROUTING -o <fastd-Interface> -s 10.8.0.0/24 -j MASQUERADE Und das sollte auch schon reichen.
|
scifire
(Themenstarter)
Anmeldungsdatum: 5. Mai 2013
Beiträge: 34
|
Nein an 10.185.0.0/18 liegt br-fffd als interface an. Aber wenn ich dieses eintrage funktioniert es leider immer noch nicht. tun0 ist mein OVPN interface
|