ReviloEgros
Anmeldungsdatum: 21. Dezember 2018
Beiträge: Zähle...
|
Hallo liebe Gemeinde, nun bräuchte ich mal euer geballtes Schwarmwissen, um vielleicht bei meinem Problem weiterkommen zu können. Ich habe schon einiges durch, aber nichts davon war bisher von Erfolg gekrönt. Folgendes Setup:
| Internet -> Router1 192.168.2.1/24 -> Router2 192.168.188.1/24 -> Ubuntu Server 192.168.188.200 -> VPN -> Internet
|
Folgendes Problem:
Ich habe in beiden Routern (Ja, 2 Router, nicht fragen, geht hier nicht anders) eine Portweiterleitung eingerichtet, um so z.B. auf Port 80 meines Servers zu gelangen. Das Funktioniert auch alles wunderbar, solange ich keine VPN Verbindung aufbaue. Nun haben wir uns aber dazu entschlossen, den Server auch als VPN Gateway zu benutzen. Wenn ich nun die VPN Verbindung zu Perfect Privacy aufbaue, komme ich aus dem Internet nicht mehr auf Port 80 des Servers. Der Zugriff soll hierbei über die normale öffentliche IP unseres Routers passieren, und NICHT über das VPN. Wake-On-Lan habe ich mir somit auch zunichte gemacht. Das NAS im Keller fuhr nicht mehr hoch nach absetzen des Magic Packets. Das habe ich allerdings lösen können, mit einem:
| route add -host 255.255.255.255 gw 192.168.188.1
|
Somit habe ich dem Broadcast den 2. Router als Gateway vorgegeben. Vielleicht gibt es hier noch eine elegantere Lösung, für Vorschläge bin ich offen. Aber wie ich es auch drehe und wende, ich bekomme es einfach nicht hin, über die öffentliche IP meines Routers auf den Server zu gelangen, wenn die VPN Verbindung aktiv ist. Hilfe! ☹ Routing mit VPN (ExterneIP:80 geht nicht)
| Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.1.214.1 128.0.0.0 UG 0 0 0 tun0
default 192.168.188.1 0.0.0.0 UG 100 0 0 eno1
10.1.214.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
hostedby.bla.ne 192.168.188.1 255.255.255.255 UGH 0 0 0 eno1
128.0.0.0 10.1.214.1 128.0.0.0 UG 0 0 0 tun0
192.168.188.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1
192.168.188.1 0.0.0.0 255.255.255.255 UH 100 0 0 eno1
255.255.255.255 192.168.188.1 255.255.255.255 UGH 0 0 0 eno1
|
Routing ohne VPN (ExterneIP:80 geht)
| Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.188.1 0.0.0.0 UG 100 0 0 eno1
192.168.188.0 0.0.0.0 255.255.255.0 U 0 0 0 eno1
192.168.188.1 0.0.0.0 255.255.255.255 UH 100 0 0 eno1
|
iptables Konfiguration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 | *nat
-A POSTROUTING -o tun0 -j MASQUERADE
-A PREROUTING -s 0.0.0.0/32 -i eno1 -p udp -m udp --dport 67 -j DNAT --to-destination 0.0.0.0:6767
COMMIT
*filter
-I INPUT -s 127.0.0.0/24 -j ACCEPT
-I OUTPUT -s 127.0.0.0/24 -j ACCEPT
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 192.168.188.0/24 -j ACCEPT
-A INPUT -d 192.168.2.0/24 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 8088 -j ACCEPT
-A INPUT -s 0.0.0.0/32 -i eno1 -p udp -m udp --dport 6767 -j ACCEPT
-A OUTPUT -p udp -d 255.255.255.255 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -p icmp -j ACCEPT
-A OUTPUT -d 192.168.188.0/24 -j ACCEPT
-A OUTPUT -d 192.168.2.0/24 -j ACCEPT
-A OUTPUT -p tcp -m tcp --sport 8088 -j ACCEPT
-A OUTPUT -d 31.x.x.x -j ACCEPT
-A OUTPUT -d 95.x.x.x -j ACCEPT
-A OUTPUT -d 31.x.x.x -j ACCEPT
-A OUTPUT -d 31.x.x.x -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1194 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 148 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 149 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 150 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 151 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1148 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1149 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1150 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1151 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 300 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 301 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 142 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 152 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 1142 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 1152 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A FORWARD -i eno1 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o eno1 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb:
..., ich bekomme es einfach nicht hin, über die öffentliche IP meines Routers auf den Server zu gelangen, wenn die VPN Verbindung aktiv ist. Hilfe! ☹
Benutzt Du in diesem Fall, die öffentliche IP deines Routers für den Zugriff aus dem Internet (d. h. von einem ganz fremden Internetanschluss)? Wenn ja, dann starte mal auf deinem Server:
sudo tcpdump -c 40 -vvveni eno1 tcp port 80
und mache danach einen Zugriff aus dem _Internet_ auf deinen Server:
nc -zv <öffentliche IP deines Routers> 80
(oder gleichwertig).
Gibt es danach eine Ausgabe mit tcpdump?
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Ja, ich benutze die öffentliche IP des Routers. Es kommt auch was auf dem Server an, aber es kommt nichts zurück. Ich bekomme von Extern immer eine Zeitüberschreitung. tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:21:58.214303 38:10:d5:xx:xx:xx > 94:c6:91:xx:xx:xx, ethertype IPv4 (0x0800),
length 78: (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 64)
80.187.x.x.28988 > 192.168.188.200.80: Flags [S], cksum 0x54ae (correct),
seq 4203279948, win 65535, options [mss 1400,nop,wscale 7,nop,nop,TS val 1352061285 ecr 0,sackOK,eol], length 0
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb: Ja, ich benutze die öffentliche IP des Routers.
Diese Information allein reicht nicht. Meine Frage war auch, von wo nutzt Du die öffentliche IP des Routers? Es gibt user, die nutzen (absichtlich oder nicht absichtlich) die öffentliche IP auch aus dem eigenen (W)LAN. ReviloEgros schrieb: Es kommt auch was auf dem Server an, aber es kommt nichts zurück. Ich bekomme von Extern immer eine Zeitüberschreitung. tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:21:58.214303 38:10:d5:xx:xx:xx > 94:c6:91:xx:xx:xx, ethertype IPv4 (0x0800),
length 78: (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 64)
80.187.x.x.28988 > 192.168.188.200.80: Flags [S], cksum 0x54ae (correct),
seq 4203279948, win 65535, options [mss 1400,nop,wscale 7,nop,nop,TS val 1352061285 ecr 0,sackOK,eol], length 0
Ist das alles? Nur eine Anfrage mit dem syn-Flag [S]? Warum versucht der Server nicht mit syn+ack[S.] (vom source-Port 80) zu antworten? tcpdump sollte das doch auch anzeigen, oder? Oder ist der Server so schlau und antwortet deshalb nicht, weil er schon weiß, dass für die Antwort das Routing/Masquerading/Source-NAT/etc. nicht richtig gesetzt/konfiguriert ist? Oder geht die Antwort [S.] (syn+ack) über ein anderes Interface (des Servers) raus und wird deshalb hier von tcpdump nicht gezeigt?
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Die öffentliche IP nutze ich von außerhalb des heimischen Netzes, von unterwegs aus. Und ja, tcpdump hat leider nur den einen Eintrag ausgegeben. Ein tcpdump auf tun0 bringt nichts hervor.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb: Und ja, tcpdump hat leider nur den einen Eintrag ausgegeben. Ein tcpdump auf tun0 bringt nichts hervor.
Welche Interfaces hat der Server noch, außer lo, tun0 und eno1? EDIT: Evtl. erreicht diese Anfrage mit dem syn-Flag, den lauschenden(?) Port 80 des Servers gar nicht? ... und wird nur im Vorfeld (auf dem Weg zum Server) von tcpdump erkannt und gezeigt?
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Es gibt noch ein WLAN Interface wlp0s20f3, aber auch hier kommt mit tcpdump nichts raus. Wie gesagt, sofort wenn ich die VPN Verbindung trenne, läuft alles wie es soll. Die Pakete müssen irgendwo in dem Routing verloren gehen bzw. hängen bleiben oder falsch geroutet werden. Ich habe iptables sozusagen als Kill-Switch konfiguriert. Droppt die VPN Verbindung, gehen keine Pakete über ein anderes Interface in das Internet. Dachte zuerst daran lag es, aber auch wenn ich iptables komplett zurücksetze, also alle Ports/Hosts/ifaces wieder offen sind, geht es auch nicht. EDIT
Gerade noch was bemerkt. Auch wenn ich aus dem internen Netzwerk auf die öffentliche IP zugreife, kommt nichts.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb: Die Pakete müssen irgendwo in dem Routing verloren gehen bzw. hängen bleiben oder falsch geroutet werden.
Naja, aber "die Pakete" sind doch mit tcpdump auf dem lauschenden Port 80 zu sehen. Kannst Du den Server evtl. so konfigurieren, dass dieser eine tatsächliche Anfrage/Verbindung zum Port 80, in seinem Log anzeigt?
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Leider kann ich kein loging aktivieren. Aber ich habe den dienst mal beendet und mit netctat -l 80 gelauscht. Weder von der öffentlichen IP von ausserhalb, noch über die öffentliche IP innerhalb des Netzwerkes kommt was an. Nur wenn ich auf die lokale Server-IP zugreife kommt was.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb: Leider kann ich kein loging aktivieren. Aber ich habe den dienst mal beendet und mit netctat -l 80 gelauscht.
Wie ist mit netcat und mit dem lauschenden Server, auf dem Server die Ausgabe von:
sudo netstat -tlpena | grep -i 80
?
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Der Dienst:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 999 30352 1481/perl Und mit netcat das selbe:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 46816 6402/netcat
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb: Und mit netcat das selbe:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 46816 6402/netcat
Evtl. liegt es an der iptables-Konfiguration, denn Du hast die default policy auf DROP, für alle chains.
Schau dir die Regeln bzw. deren counter mal an.
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Liegt es leider nicht. Wie ich bereits sagte, kann ich die iptables rules alle zurücksetzen, trotzdem kommt nichts durch ☹
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ReviloEgros schrieb: Liegt es leider nicht.
Das kann ich mir nicht vorstellen, denn ein lauschender netcat der mit syn [S] auf Port 80 erreicht wird, antwortet immer mit einem syn+ack [S.].
|
ReviloEgros
(Themenstarter)
Anmeldungsdatum: 21. Dezember 2018
Beiträge: 9
|
Nach weiteren erfolglosen versuchen das Routing zu verbiegen mit und ohne mangle/mark/sonstwas bin ich durch Zufall im OpenVPN Forum auf die Lösung für mein Problem gestoßen. Hier nochmal für die, die vielleicht vor dem selben Problem stehen wie ich: ip rule add from <interne lokale IP des PCs/VPN Clients> table 10
ip route add default via <interne lokale IP des Routers/Gateway> table 10
|