sangul
(Themenstarter)
Anmeldungsdatum: 27. Juli 2013
Beiträge: 207
|
Hallo kb, danke für deine Antwort. Ohne Nat wird es wohl nicht klappen. Um meine Gerät von extern zu erreichen muss ich vom internen netz einen vpn tunnel nach außen aufbauen, da ich über lte ins internet gehe und mir mein Provider eine private Ip Adresse zuteilt. Diese private IP Adresse ist hinter einer öffentlichen Adresse genat-ed z.B. 10.0.0.250 ←–→ 39.128.12.15 . Die public IP teilen sich dann mehrere tausend User, man kann von daher seine interne Geräte nicht ohne weiteres erreichen. Der VPN Tunnel wird nach außen aufgebaut und ich kann dann durch den Zugriff auf den Server bestimmte Ports hinter dem VPN Client erreichen. Bei mir ist das ganze so aufgebaut (vereinfacht): |
Fritzbox LTE 6820 (eth0 192.168.178.1)---------Switch----Alarmanlage (eth0 192.168.178.4)
|
|
|
Raspberry Py (eth0 192.168.178.10)
(tun0 10.12.3.126)
|
Normalerweise hängt am Switch auch noch eine Sophos die eine S2S Verbindung zu einer anderer Sophos aufbaut, über die ich dann auch ins interne Netz am Standort der Fritzbox LTE 6820 komme. Die Lösung mit dem Raspberry Py soll nur eine Backuplösung sein. Über einen VPN Provider habe ich nun hier bestimmte Ports freigeschaltet um die Alarmanlage zu erreichen. Z.b. Zielport 443 wird über 15620 erreicht. Wenn ich im tcpdump schaue passt das alles soweit, ich rufe von extern meinen dns Namen auf z.B. http://testalarm.de:15620 und sehe dann auf dem tun0 interface die Anfragen an die tun0 Schnittstellen IP laufen (10.12.3.126). Jetzt müssten diese Anfragen natürlich an das richtige Gerät weitergeleitet werden (Alarmanlage). D.h. vom tun0 Interface vom raspberry müssten Sie an die eth0 Schnittstelle des respberrys weitergeleitet werden (diese Schnittstelle hängt wie die Alarmanlage im gleichen Netz) und die Rückantwort der Alarmanalge müsste dann wohl auch wieder durch den Tunnel geleitet werden, wie du geschrieben hast. gruß sangul
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8618
Wohnort: Münster
|
Dafür benötigst Du kein NAT und somit auch iptables gar nicht. Du musst nur vom entfernten Rechner einen Tunnel zum Raspberry Pi graben und zusätzlich:
Den entfernten Rechner in ein anderes Netz stecken, also nicht 192.168.178/24 , sondern z.B. 192.168.222/24 . Am entfernten Rechner den IP-Verkehr zu 192.168.178/24 in den Tunnel schicken, also einen entsprechenden Leitweg (Route) einrichten. Den RPi als Router betreiben. Auf der Alamanlage einen Leitweg für 192.168.222/24 einrichten, der über den RPi als Router führt.
|
sangul
(Themenstarter)
Anmeldungsdatum: 27. Juli 2013
Beiträge: 207
|
Nach einigem rumspielen mit dem iptables sieht es jetzt so aus das die Pakete über die eth0 Schnittstelle an die alarmalange oder auch fritzbox weitergeleitet werden. Hier mal eine Übersicht: tun0: Gw Adresse 10.12.0.1
Schnittstellen ip: 10.12.3.126 Kommen jetzt Anfragen von außen, sieht man diese wenn man auf tun0 dumpt (wie bisher auch), diese sieht man dann aber auch auf der eth0 Schnittstelle in Richtung Alarmanlage laufen.
Habe zum testen auch mal eine Rule angelegt, dass die Pakete auch an die Fritzbox gehen (192.168.178.1)
Man sieht sie auch auf der Fritzbox Schnittstelle ankommen, allerdings gehen die Pakete nicht mehr zurück (was ja auch klar ist, da die Fritzbox/Alarmanalge das Netz nicht kennt. Ich denke das Problem ist eine falsche Eintragung der iptable Rule.
Wenn man im Dump von eth0 schaut, kann man als src die Gw Adresse des tun0 Adapters sehen: Src 10.12.0.1 und als Destination die Fritzbox 192.168.178.1 oder Alarmanalge 192.168.178.4 Als src sollte hier aber eingeltich die Schnittstellen von eth0 des raspberry stehen, dann würde die Fritzbox und die Alarmanalge auch den Rückweg kennen. Folgende Ip Tables habe ich verwendet: iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 192.168.178.1 iptables -A FORWARD -i tun0 -p tcp --dport 443 -d 192.168.178.1 -j ACCEPT Kann mir jemand helfen die so anzupassen, dass es funktioniert? danke und gruß sangul
|
sangul
(Themenstarter)
Anmeldungsdatum: 27. Juli 2013
Beiträge: 207
|
Ok, habe heute nochmal weiter versucht, diesesmal mit einem Gerät wo man die Pakete mitdumpen kann. Habe auf dem Raspberry die eth0 Schnittstelle (192.168.1.100) mit der Sophos (192.168.1.1) verbunden. Der Webadmin der Sophos lässt sich über den Port 4444 aufrufen. Über den Raspberry baue ich außerdem wie schon beschrieben einen VPN Tunnel zu feste-ip.net. (tun0 interface). 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 |
ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::64c8:19a5:6b45:770c prefixlen 64 scopeid 0x20<link>
ether 0c:54:a5:2b:44:34 txqueuelen 1000 (Ethernet)
RX packets 5530 bytes 4528052 (4.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3851 bytes 537853 (537.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1440
inet 10.12.3.126 netmask 255.255.255.255 destination 10.12.3.125
inet6 fe80::e3d5:3754:3490:3496 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 184 bytes 15714 (15.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 485 bytes 43655 (43.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
|
Habe die folgende Regel angelegt: | sudo iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 4444 -j DNAT --to 192.168.1.1
|
Jetzt versuche ich von extern über den Browser die Sophos zu erreichen: http://testuser0815.fest-ip.net:45454 : Ich sehe die Pakete im tun0 Interface ankommen: | sudo tcpdump -nvei tun0 port 4444
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
23:25:37.856303 ip: (tos 0x0, ttl 247, id 30237, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2880 > 10.12.3.126.4444: Flags [S], cksum 0x8de2 (correct), seq 1060732944, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425274826 ecr 0], length 0
23:25:37.864391 ip: (tos 0x0, ttl 247, id 30342, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2882 > 10.12.3.126.4444: Flags [S], cksum 0xf583 (correct), seq 3462433085, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425274834 ecr 0], length 0
|
auf der eth0 Schnittstelle des Raspberry: | sudo tcpdump -nvei eth0 port 4444
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:25:37.856335 0c:54:a5:2b:44:34 > 00:1a:8c:4c:3c:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 246, id 30237, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2880 > 192.168.1.1.4444: Flags [S], cksum 0xd9c2 (correct), seq 1060732944, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425274826 ecr 0], length 0
23:25:37.864424 0c:54:a5:2b:44:34 > 00:1a:8c:4c:3c:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 246, id 30342, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2882 > 192.168.1.1.4444: Flags [S], cksum 0x4164 (correct), seq 3462433085, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425274834 ecr 0], length 0
|
und auf der Sophos eth0 Schnittstelle: | tcpdump -nvei eth0 port 4444
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:25:50.041090 0c:54:a5:2b:44:34 > 00:1a:8c:4c:3c:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 246, id 30237, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2880 > 192.168.1.1.4444: Flags [S], cksum 0xd9c2 (correct), seq 1060732944, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425274826 ecr 0], length 0
23:25:50.049178 0c:54:a5:2b:44:34 > 00:1a:8c:4c:3c:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 246, id 30342, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2882 > 192.168.1.1.4444: Flags [S], cksum 0x4164 (correct), seq 3462433085, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425274834 ecr 0], length 0
23:25:53.095335 0c:54:a5:2b:44:34 > 00:1a:8c:4c:3c:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 246, id 29328, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2880 > 192.168.1.1.4444: Flags [S], cksum 0xce0a (correct), seq 1060732944, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425277826 ecr 0], length 0
23:25:53.095338 0c:54:a5:2b:44:34 > 00:1a:8c:4c:3c:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 246, id 29556, offset 0, flags [DF], proto TCP (6), length 60)
10.12.0.1.2882 > 192.168.1.1.4444: Flags [S], cksum 0x35ac (correct), seq 3462433085, win 28480, options [mss 1314,nop,wscale 6,sackOK,TS val 3425277834 ecr 0], length 0
|
https://forum.ubuntuusers.de/post/9104486/edit/#
Das Problem ist jetzt, dass die Sophos das Netz 10.12.0.0 nicht kennt und die Antwortpakete an das Standart GW sendet, wo sie dann verworfen werden. Frage:
Wie kann ich das Ganze anpassen, dass die Antwortpakete korrekt zurückgehen? An Stelle der Sophos wird später die Alarmanlage stehen, auf dieser ist Netzwerk-technisch (außer IP Adresse, DNS, Standart GW usw.) nichts konfigurierbar D.h. alle Konfigurationen müssten auf dem Raspberry vorgenommen werden. Ist das überhaupt umsetzbar? gruß sangul
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
sangul schrieb: An Stelle der Sophos wird später die Alarmanlage stehen, auf dieser ist Netzwerk-technisch (außer IP Adresse, DNS, Standart GW usw.) nichts konfigurierbar
Braucht die Alarmanlage denn das reguläre Standard-Gateway? Wenn nicht, kannst du sie ja so konfigurieren, dass sie den RPi als GW verwendet.
D.h. alle Konfigurationen müssten auf dem Raspberry vorgenommen werden.
Du könntest noch versuchen, auf deinem regulären Gateway (der FritzBox, oder?) eine statische Route einzutragen, sodass diese die Pakete der Alarmanlage an den RPi weitergibt.
Ist das überhaupt umsetzbar?
Wo die Pakete jetzt schonmal an der Sophos "Alarmanlage" ankommen, sollte das mit einem der beiden Vorschläge oben zu erledigen sein.
|