ubuntuusers.de

OpenVPN Server Webseite kann nicht durch den Tunnel aufgerufen werden

Status: Gelöst | Ubuntu-Version: Server 14.04 (Trusty Tahr)
Antworten |

s3993

Anmeldungsdatum:
24. Oktober 2018

Beiträge: Zähle...

Hallo

Ich habe einen OpenVPN Server erfolgreich am laufen. Die Clients verbinden sich und der gesamte Traffic läuft durch den Tunnel, so soll es ja auch sein. Auf dem OpenVPN Server laufen nun auch noch ein paar Webseiten. Und jetzt zu meinem Problem. Ich kann alles über den VPN Tunnel erreichen AUßER die Webseiten, die auf dem OpenVPN Server liegen. Warum geht das nicht, ist das aus so gewollt? Ich hoffe ich konnte mich einigermaßen verständlich ausdrücken.

Server Config

port 1194

proto tcp-server
mode server
tls-server
dev tun0

tun-mtu 1492
mssfix

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/xxxxxxx.crt
key /etc/openvpn/easy-rsa/keys/xxxxx.key

dh /etc/openvpn/easy-rsa/keys/dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option WINS 8.8.8.8"

push "redirect-gateway def1 bypass-dhcp"


push "topology subnet"
topology subnet

client-to-client

keepalive 10 120

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

management 127.0.0.1 5555

status /var/log/openvpn-status.log 30
log-append    /var/log/openvpn.log
verb 3

Client Config

client
dev tun
proto tcp

tun-mtu 1492
#fragment 1300
mssfix

remote let-it-worxx.com 1194
resolv-retry infinite
nobind
persist-key
#persist-tun
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

comp-lzo
verb 1

<ca>
-----BEGIN CERTIFICATE-----
xxxxxx
-----END CERTIFICATE-----
</ca>
<cert>
xxxxxx
</cert>
<key>
xxxxxx
</key>

Danke für eure Hilfe.

Grüße s3993

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

Ich kann alles über den VPN Tunnel erreichen AUßER die Webseiten, die auf dem OpenVPN Server liegen. Warum geht das nicht, ist das aus so gewollt?

Wie sind auf dem Server, die Ausgaben von:

sudo netstat -tlpena
ip a
route -n

?

s3993

(Themenstarter)

Anmeldungsdatum:
24. Oktober 2018

Beiträge: 6

netstat -tlpena
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      0          3846806527  24996/openvpn   
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      105        1129835     953/mysqld      
tcp        0      0 127.0.0.1:587           0.0.0.0:*               LISTEN      0          1032858     977/sendmail: MTA: 
tcp        0      0 127.0.0.1:5555          0.0.0.0:*               LISTEN      0          3846806524  24996/openvpn   
tcp        0      0 127.0.0.1:5557          0.0.0.0:*               LISTEN      0          3846806446  24990/openvpn   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          1031511     487/sshd        
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      0          1032857     977/sendmail: MTA:      
tcp        0      0 xxxxxxxx:1194      xxxxxxxxx:54068    VERBUNDEN   65534      3972629341  24996/openvpn   
tcp6       0      0 :::80                   :::*                    LISTEN      0          2713670139  27561/apache2   
tcp6       0      0 :::22                   :::*                    LISTEN      0          1031521     487/sshd        
tcp6       0      0 :::443                  :::*                    LISTEN      0          2713670143  27561/apache2   
root@xxxxxx:✓ ~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/void 
    inet 127.0.0.1/32 scope host venet0
    inet xxxxxxxxxx/32 brd 85.214.42.132 scope global venet0:0
    inet6 ::2/128 scope global 
       valid_lft forever preferred_lft forever
7: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.11.1/24 brd 10.8.11.255 scope global tun2
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
root@xxxxxxx:✓ ~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.8.11.0       0.0.0.0         255.255.255.0   U     0      0        0 tun2
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 venet0

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          1031511     487/sshd           
tcp6       0      0 :::80                   :::*                    LISTEN      0          2713670139  27561/apache2   
tcp6       0      0 :::22                   :::*                    LISTEN      0          1031521     487/sshd        
tcp6       0      0 :::443                  :::*                    LISTEN      0          2713670143  27561/apache2   
7: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.11.1/24 brd 10.8.11.255 scope global tun2
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0

Mach mal vom Linux-Client, wenn dieser per VPN mit dem Server verbunden ist, einen Portscan:

nc -zv 10.8.11.1 22 80 443
nc -zv 10.8.0.1 22 80 443
nc -zv -6 10.8.11.1 22 80 443
nc -zv -6 10.8.0.1 22 80 443

und poste das Ergebnis.

s3993

(Themenstarter)

Anmeldungsdatum:
24. Oktober 2018

Beiträge: 6

root@xxx:/etc/openvpn# nc -zv 10.8.0.1 22 80 443
Connection to 10.8.0.1 22 port [tcp/ssh] succeeded!
root@xxx:/etc/openvpn# nc -zv 10.8.11.1 22 80 443
Connection to 10.8.11.1 22 port [tcp/ssh] succeeded!
root@xxx:/etc/openvpn# nc -zv -6 10.8.11.1 22 80 443
nc: getaddrinfo for host "10.8.11.1" port 22: Address family for hostname not supported
root@xxx:/etc/openvpn# nc -zv -6 10.8.0.1 22 80 443
nc: getaddrinfo for host "10.8.0.1" port 22: Address family for hostname not supported

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

root@xxx:/etc/openvpn# nc -zv 10.8.0.1 22 80 443
Connection to 10.8.0.1 22 port [tcp/ssh] succeeded!
root@xxx:/etc/openvpn# nc -zv 10.8.11.1 22 80 443
Connection to 10.8.11.1 22 port [tcp/ssh] succeeded!

Die Ports 80 und 443 sind durch den Tunnel erreichbar. Kann es sein, dass es evtl. am apache oder am Browser liegt?

s3993

(Themenstarter)

Anmeldungsdatum:
24. Oktober 2018

Beiträge: 6

Ich bin für jeden Tipp dankbar.

hier mal ein traceroute auf die betreffende webseite. Der traffic geht gar nicht erst in den tunnel rein.

traceroute xxxxxxxxxx
traceroute to xxxxxxxxxxx (xxxxxxxxxxx), 30 hops max, 60 byte packets
 1  _gateway (192.168.111.1)  0.625 ms  0.912 ms  0.967 ms
 2  192.168.2.1 (192.168.2.1)  7.827 ms  7.803 ms  7.752 ms
 3  62.155.247.82 (62.155.247.82)  11.207 ms  11.505 ms  11.589 ms
 4  217.5.101.54 (217.5.101.54)  18.090 ms  18.969 ms  19.171 ms
 5  217.5.101.54 (217.5.101.54)  19.133 ms  19.088 ms  19.611 ms
 6  xe-0-1-0.core-b2.as6724.net (80.150.171.78)  19.176 ms  13.038 ms  13.313 ms
 7  vl443.dcata-b9.as6724.net (85.214.0.119)  13.158 ms  13.193 ms  13.694 ms
 8  * * *
 9  xxxxxxxxxxx (xxxxxxxxxx)  16.083 ms  13.796 ms  14.520 ms

und zum vergleich ein traceroute auf web.de

traceroute web.de
traceroute to web.de (82.165.229.138), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  13.605 ms  26.954 ms  26.976 ms
 2  10.169.31.36 (10.169.31.36)  26.986 ms  26.994 ms  26.876 ms
 3  ae4.425.core-b1.as6724.net (85.214.0.112)  26.884 ms  26.894 ms  26.897 ms
 4  ae2.0.atuin.as6724.net (85.214.0.71)  26.898 ms  26.899 ms  26.901 ms
 5  te-0-1-1-88.bb-a.fra3.fra.de.oneandone.net (212.227.112.82)  26.899 ms  26.901 ms  39.445 ms
 6  ae-10-0.bb-a.bap.rhr.de.oneandone.net (212.227.120.147)  93.535 ms  31.881 ms  32.249 ms
 7  ae-2-0.bb-a.tp.kae.de.oneandone.net (212.227.120.44)  46.230 ms  46.270 ms  46.269 ms
 8  ae-0-0.gw-diste2-a.bs.kae.de.oneandone.net (212.227.116.212)  46.292 ms  46.231 ms  46.235 ms

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

hier mal ein traceroute auf die betreffende webseite. Der traffic geht gar nicht erst in den tunnel rein.

Naja, warum willst Du die externe IP-Adresse verwenden, wenn der apache doch auf dem VPN-Server ist? web.de ist ja nicht auf dem VPN-Server, sondern im Internet und kann dort auch via VPN erreicht werden.

s3993

(Themenstarter)

Anmeldungsdatum:
24. Oktober 2018

Beiträge: 6

OK die Frage ist gut. Wie kann ich denn dem Apache beibringen das eine webseite unter einem FQDN und einer anderen IP erreichbar ist? Wenn ich das könnte, dann wäre mir geholfen. Aber das Verhalten ist doch schon seltsam oder ?

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

Aber das Verhalten ist doch schon seltsam oder ?

Ich denke nicht, dass das Verhalten seltsam ist. Denn wenn der apache die identische externe IP-Adresse wie der OpenVPN-Server hat, dann ist doch klar, dass für das Routing ein anderes gateway (hier der Router) verwendet werden muss und nicht das OpenVPN-gateway (das auch als gateway für die default route fungiert), durch das web.de und das restliche Internet erreicht werden kann.

s3993

(Themenstarter)

Anmeldungsdatum:
24. Oktober 2018

Beiträge: 6

leider ist mir das nicht klar, warum ich den Server unter seinem FQDN nicht durch den Tunnel erreichen kann. Sorry da stehe ich jetzt auf dem Schlauch. Aber danke für deine Mühe, mir zu helfen.

Gruß s3993

TomLu

Anmeldungsdatum:
23. August 2014

Beiträge: 603

Wenn der Web-Server via FQDN erreicht werden soll, also via DDNS, hat das imho nix mit OpenVPN zu tun, auch nicht, wenn beides auf der gleichen Maschine läuft. Zunächst mal kommt ja der tcp-Traffic für beide Services auf dem gleichen physischen interface an, und die Pakete für Port 80 und 443 gehen meiner Meinung nach gar nicht ans tun-Device, sondern erreichen den lokalen Prozess des Webservers direkt.

Ich frage mich an der Stelle, ob neben udp/1194 zusätzlich auch tcp/80 und tcp/443 im DSL-Router freigegeben sind und zum Webserver geforwarded werden. Wenn nicht, kann das imho gar nicht funktionieren.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

leider ist mir das nicht klar, warum ich den Server unter seinem FQDN nicht durch den Tunnel erreichen kann.

Weil für diese IP-Adresse (Auflösung der FQDN) ein anderer (richtig) definierter Weg (route, gateway):

traceroute to xxxxxxxxxxx (xxxxxxxxxxx), 30 hops max, 60 byte packets
 1  _gateway (192.168.111.1)  0.625 ms  0.912 ms  0.967 ms
 2  192.168.2.1 (192.168.2.1)  7.827 ms  7.803 ms  7.752 ms

genommen wird und nicht die default route:

traceroute to web.de (82.165.229.138), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  13.605 ms  26.954 ms  26.976 ms

durch das VPN-gateway bzw. durch den VPN-Tunnel.

lubux

Anmeldungsdatum:
21. November 2012

Beiträge: 14347

s3993 schrieb:

root@xxx:/etc/openvpn# nc -zv 10.8.0.1 22 80 443
Connection to 10.8.0.1 22 port [tcp/ssh] succeeded!
root@xxx:/etc/openvpn# nc -zv 10.8.11.1 22 80 443
Connection to 10.8.11.1 22 port [tcp/ssh] succeeded!
root@xxx:/etc/openvpn# nc -zv -6 10.8.11.1 22 80 443

BTW: Hast Du diese Portscans (so wie gefordert) auf deinem VPN-Server oder auf deinem VPN-Client gemacht?

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

s3993 schrieb:

Ich kann alles über den VPN Tunnel erreichen AUßER die Webseiten, die auf dem OpenVPN Server liegen.

"Funktioniert nicht" ist keine Fehlerbeschreibung. Welche Fehlermeldung kommt? Was genau sagt

curl -i <Webseiten-URL>

wenn man es auf einem Client ausführt? Hier mit irgendwelchen Netzwerk-Traces rumzuhantieren führt IMHO nicht zum Ziel.

Meine Vermutung: Da der OpenVPN-Client mit dem OpenVPN-Server kommunizieren muss, gibt es eine spezifische Route für die IP des OpenVPN-Servers, die über das normale Internet-Gateway des Clients geht. Daher wird der Traffic auch nicht durch den Tunnel geschickt. Dafür gibt es verschiedene Lösungsmöglichkeiten. Ich würde den Apache auch an der VPN-Adresse lauschen lassen, und die Hostnamen auf dem Client über die /etc/hosts umbiegen:

/etc/hosts:
  10.8.0.1    deinedomain.de

Dann geht der Traffic in den Tunnel. Wenn du mehrere gleichartige Clients hast, kannst du auch einfach einen Proxy-Server auf dem VPN-Server aufsetzen, und diesen mit deinen VPN-Clients nutzen. Der Proxy-Dienst seinerseits kann dann problemlos auf alles zugreifen.

Antworten |