ubuntuusers.de

Hallo zusammen,

irgendwie steige ich bei den iptables noch nicht ganz durch, vielleicht kann mir jemand helfen bzw. den Stubbs in die richtige Richtung geben.

ZU meinem Netzwerk: 192.168.178.1 Router/Gateway zum ISP (Fritzbox 7490) 192.168.178.100 Linux-Server "hal9000" 192.168.178.201 mein VPN Gateway (raspbian, openvpn, eth0, tun0)

Hier meine rules.v4

 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

# Generated by iptables-save v1.4.21 on Sun Apr 10 19:07:44 2016
*mangle
:PREROUTING ACCEPT [35847612:30380313443]
:INPUT ACCEPT [13501877:11840691120]
:FORWARD ACCEPT [22335424:18539093747]
:OUTPUT ACCEPT [12401239:9837914998]
:POSTROUTING ACCEPT [34736673:28377010843]
COMMIT
# Completed on Sun Apr 10 19:07:44 2016
# Generated by iptables-save v1.4.21 on Sun Apr 10 19:07:44 2016
*nat
:PREROUTING ACCEPT [279572:25797811]
:INPUT ACCEPT [139209:14775662]
:OUTPUT ACCEPT [146578:19006186]
:POSTROUTING ACCEPT [281:17514]
-A PREROUTING -i tun0 -p tcp -m tcp --dport 25252 -j DNAT --to-destination 192.168.178.100
-A PREROUTING -i tun0 -p tcp -m tcp --dport 9851 -j DNAT --to-destination 192.168.178.100
-A PREROUTING -i tun0 -p tcp -m tcp --dport 3686 -j DNAT --to-destination 192.168.178.100
-A PREROUTING -i tun0 -p udp -m udp --dport 52525 -j DNAT --to-destination 192.168.178.100
-A PREROUTING -i tun0 -p tcp -m tcp --dport 52525 -j DNAT --to-destination 192.168.178.100
-A PREROUTING -i tun0 -p tcp -m tcp --dport 6969 -j DNAT --to-destination 192.168.178.100
-A POSTROUTING -o tun0 -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Apr 10 19:07:44 2016
# Generated by iptables-save v1.4.21 on Sun Apr 10 19:07:44 2016
*filter
:INPUT ACCEPT [13501877:11840691120]
:FORWARD ACCEPT [16842107:14836616328]
:OUTPUT ACCEPT [12401234:9837914461]
-A FORWARD -d 192.168.178.100/32 -i tun0 -o eth0 -p tcp -m tcp --dport 25252 -j ACCEPT
-A FORWARD -d 192.168.178.100/32 -i tun0 -p tcp -m tcp --dport 52525 -j ACCEPT
-A FORWARD -d 192.168.178.100/32 -i tun0 -p udp -m udp --dport 52525 -j ACCEPT
COMMIT
# Completed on Sun Apr 10 19:07:44 2016

Da sind zweri Portforwards die mich derzeit "fertig" machen: 25252 und 52525. 52525 ist für Bittorrent was in dieser konfiguration sagt das der Port geschlossen wäre, der 25252 der für eine andere Peer2Peer-Software ist, sagt das der Port offen sei, die Software verhält sich aber als sei er geschlossen/nicht ertreichbar. Nehme ich Änderungen an der POSTROUTING-Regel für 25252 vor, wird der Port wieder von der Software als geschlossen gemeldet weswegen ich vermute das der Fehler vielleicht in der FORWARD-Regel liegt (oder brauche ich eine INPUT-Regel?)

Ich hoffe jemand kann mir helfen die Sache "rund" zu machen. 😉

Danke im Vorraus.

Moppen72 schrieb:

ZU meinem Netzwerk: 192.168.178.1 Router/Gateway zum ISP (Fritzbox 7490) 192.168.178.100 Linux-Server "hal9000" 192.168.178.201 mein VPN Gateway (raspbian, openvpn, eth0, tun0) Hier meine rules.v4

Von welchem System ist die Konfigurationsdatei? Was hast du genau vor?

52525 ist für Bittorrent was in dieser konfiguration sagt das der Port geschlossen wäre , der 25252 der für eine andere Peer2Peer-Software ist, sagt das der Port offen sei, die Software verhält sich aber als sei er geschlossen/nicht ertreichbar.

Wer sagt das? Wie testest du das?

Nehme ich Änderungen an der POSTROUTING-Regel für 25252 vor, wird der Port wieder von der Software als geschlossen gemeldet weswegen ich vermute das der Fehler vielleicht in der FORWARD-Regel liegt (oder brauche ich eine INPUT-Regel?)

Welche Änderungen nimmst du denn vor?

Ich hoffe jemand kann mir helfen die Sache "rund" zu machen. 😉

Du solltest erstmal ganz klar sagen, wo und wann ein Fehler bzw. ein Verhalten auftritt, welches du so nicht erwartest. Meines Erachtens solltest du per nmap testen, welche Ports wirklich offen sind und per netcat, ob die Weiterleitung korrekt funktioniert.

Sorry das die Anfrage so wild und wirr war... ich mache mit dem Thema schon seit Wochen rum und dachte wohl jeder könne mir in den Kopf gucken 😉

misterunknown schrieb:

Moppen72 schrieb:

ZU meinem Netzwerk: 192.168.178.1 Router/Gateway zum ISP (Fritzbox 7490) 192.168.178.100 Linux-Server "hal9000" 192.168.178.201 mein VPN Gateway (raspbian, openvpn, eth0, tun0) Hier meine rules.v4

Von welchem System ist die Konfigurationsdatei? Was hast du genau vor?

Die Konfig-Datei rules.v4 (erstellt durch das Paket iptables-persistent) stammt vom System .201 welches als mein (Open)VPN-Gateway dient. Vor habe ich die Ports 25252 und 52525 für die beiden genannten Dienste zu öffnen. Quasi so als würde ich diese Port-Forwards an der Fritz-Box einrichten. Nur eben über den OpenVPN-Tunnel auf dem Rechner .201.

Dienst (Port 25252 oder 525252) ←> Rechner 192.168.178.100 ←> Gateway 192.168.178.201 ←> eth0 ←> tun0 ←> Internetz

52525 ist für Bittorrent was in dieser konfiguration sagt das der Port geschlossen wäre , der 25252 der für eine andere Peer2Peer-Software ist, sagt das der Port offen sei, die Software verhält sich aber als sei er geschlossen/nicht ertreichbar.

Wer sagt das? Wie testest du das?

Da Bittorrent als Transmission-Daemon auf dem Linux-Server (.100) läuft, teste ich dies über die Transmission-Remote-Gui welche dazu eine eingebaute Funktion hat. Port testen. Ausgabe: "eingehender Port ist geschlossen. Bitte überprüfen Sie Ihre Firewall." (52525) Die andere Software hat eine ähnliche Funktion eingebaut welche einen geschlossenen Port meldet. (25252)

Nehme ich Änderungen an der POSTROUTING-Regel für 25252 vor, wird der Port wieder von der Software als geschlossen gemeldet weswegen ich vermute das der Fehler vielleicht in der FORWARD-Regel liegt (oder brauche ich eine INPUT-Regel?)

Welche Änderungen nimmst du denn vor?

Egal. Dies ist offensichltich die Einstellung die zumindest für eine postive Meldung sorgt. Wenn eben auch nicht durch das "Verhalten".

Ich hoffe jemand kann mir helfen die Sache "rund" zu machen. 😉

Du solltest erstmal ganz klar sagen, wo und wann ein Fehler bzw. ein Verhalten auftritt, welches du so nicht erwartest. Meines Erachtens solltest du per nmap testen, welche Ports wirklich offen sind und per netcat, ob die Weiterleitung korrekt funktioniert.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

nmap -sT -e eth0 -p 25252,52525 localhost

Starting Nmap 6.47 ( http://nmap.org ) at 2016-04-25 11:57 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00026s latency).
Other addresses for localhost (not scanned): 127.0.0.1
PORT      STATE  SERVICE
25252/tcp closed unknown
52525/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Gleiches gilt für den tun0-Schnittstelle und würde sich ja mit meinen Beobachtungen decken.

Die Frage die sich stellt ist: Wie richte ich ein Port-Forward durch einen OpenVPN-Gateway mit iptables ein? Siehe Betreff.

Moppen72 schrieb:

Die Konfig-Datei rules.v4 (erstellt durch das Paket iptables-persistent) stammt vom System .201 welches als mein (Open)VPN-Gateway dient.

Also VPN-Gateway für Clients aus dem Internet? Oder wer greift darauf zu?

Dienst (Port 25252 oder 525252) ←> Rechner 192.168.178.100 ←> Gateway 192.168.178.201 ←> eth0 ←> tun0 ←> Internetz

Das ist wirr 😛 Ports, IPs und Interfaces in einer Reihe zu nennen ist nicht gerade übersichtlich.

Da Bittorrent als Transmission-Daemon auf dem Linux-Server (.100) läuft, teste ich dies über die Transmission-Remote-Gui welche dazu eine eingebaute Funktion hat. Port testen. Ausgabe: "eingehender Port ist geschlossen. Bitte überprüfen Sie Ihre Firewall." (52525)

Das würde ich nicht ungetestet glauben. Bevor du wirklich an die Anwendung gehst, würde ich erstmal ganz einfach per netcat testen, ob der Port offen ist und die Weiterleitung korrekt funktioniert.

1 2 3

PORT STATE SERVICE 25252/tcp closed unknown 52525/tcp closed unknown

Gleiches gilt für den tun0-Schnittstelle und würde sich ja mit meinen Beobachtungen decken.

Normalerweise wird ein Port als geschlossen angesehen, wenn die Firewall ihn zwar nicht blockiert, aber hinten kein Dienst lauscht.

Die Frage die sich stellt ist: Wie richte ich ein Port-Forward durch einen OpenVPN-Gateway mit iptables ein? Siehe Betreff.

Port-Forwarding ist nicht kompliziert. Die eigentliche Frage ist, was du noch falsch machst. Mir fällt da jetzt erstmal nichts konkretes auf. Daher würde ich mal auf dem .100-System einen netcat laufen lassen und von einem VPN-Client versuchen darauf zuzugreifen, nicht dass es etwas mit Bittorrent zu tun hat. Also:

1
2
3
4
5

# Port aufmachen (läuft endlos, also nicht wundern)
user@192.168.178.100$ echo "Das ist ein Test" | nc -l -p 52525

# Verbindung testen
user@vpn-client$ nc <VPN-Gateway> 52525

Kommt der Text auf dem Client an, funktioniert das Port-Forwarding korrekt, nur Bittorrent hat ein Problem. Wenn nicht, gibt es noch ein Problem. Dann müsste man per iptables ein Logging der Pakete andrehen.

misterunknown schrieb:

Also VPN-Gateway für Clients aus dem Internet? Oder wer greift darauf zu?

Achso, nein, das VPN-Gateway ist für die Rechner in meinem LAN. Diese greifen dann eben per definiertem Gateway darauf zu. Das VPN-Gateway hat den Zweck meine IP zu verschleiern. Frage ich hier lokal meine öffentliche IP ab, bekomme ich angezeigt das ich eine IP in England habe.

misterunknown schrieb:

Dienst (Port 25252 oder 525252) ←> Rechner 192.168.178.100 ←> Gateway 192.168.178.201 ←> eth0 ←> tun0 ←> Internetz

Das ist wirr 😛 Ports, IPs und Interfaces in einer Reihe zu nennen ist nicht gerade übersichtlich.

Ich wollte quasi nur "hin und zurück" ( ←> ) den Weg eines Paketes zur Verdeutlichung aufzeichnen.

misterunknown schrieb:

Port-Forwarding ist nicht kompliziert. Die eigentliche Frage ist, was du noch falsch machst.

Werde ich mir zu Gemüte führen. Da ist auch ein weiterführender Link der mal den Syntax von iptables beleuchtet. Kann mir ja nur helfen. 😉

Mir fällt da jetzt erstmal nichts konkretes auf. Daher würde ich mal auf dem .100-System einen netcat laufen lassen und von einem VPN-Client versuchen darauf zuzugreifen, nicht dass es etwas mit Bittorrent zu tun hat.

Werde ich gleich mal machen. Mal sehen was dabei rum kommt.

misterunknown schrieb:

Mir fällt da jetzt erstmal nichts konkretes auf. Daher würde ich mal auf dem .100-System einen netcat laufen lassen und von einem VPN-Client versuchen darauf zuzugreifen, nicht dass es etwas mit Bittorrent zu tun hat.

Werde ich gleich mal machen. Mal sehen was dabei rum kommt.

1
2
3
4

pi@io:~ $ nc -zv 192.168.178.100 25252 52525 6666
Connection to 192.168.178.100 25252 port [tcp/*] succeeded!
Connection to 192.168.178.100 52525 port [tcp/*] succeeded!
nc: connect to 192.168.178.100 port 6666 (tcp) failed: Connection refused

(6666 nur als Gegenprobe)

Bin ich jetzt aber auch nicht schlauer als vorher... (habe aber auch noch nur nmap und nc gearbeitet)

misterunknown schrieb:

# Verbindung testen user@vpn-client$ nc <VPN-Gateway> 52525 }}}

1
2
3
4

moppen@hal9000:~$ echo "Das ist ein Test" | nc -l -p 25252

pi@io:~ $ nc 192.168.178.100 25252
Das ist ein Test

Soweit so gut, heisst für mich das Daten von .100 nach .201 auf Port 25252 ankommen. Okay. Aber ich will ja Daten von der Schnittstelle tun0 quasi in mein LAN bekommen. Sind dazu zusätzliche Einstellungen nötig? Oder passiert das bereits weil ich ja das Gateway bereits erfolgreich als Gateway/Router eingerichtet habe? Aber sind dann nicht meine Angaben in der rules.v4-Datei inkorrekt weil ich ja da stellenweise expliziet tun0 angebe und der vorausgehenden Logik folgend ich ja dann eigentlich eth0 "abgreifen" muss?

BTW und ganz vergessen: An den Konfigurationen der Software hinter den Ports 25252 und 52525 kann es nicht liegen weil diese funktionieren wenn ich vom VPN-Gateway auf das normale Gateway (Fritzbox) "switche" und dort entsprechende Portfowards einrichte.

Moppen72 schrieb:

Soweit so gut, heisst für mich das Daten von .100 nach .201 auf Port 25252 ankommen.

Korrekt. Ist aber klar. Du solltest die VPN-IP testen und damit das Port-Forwarding... Sonst bringts ja nichts. Wenn das Port-Forwarding nicht funktioniert, musst du die Pakete mal loggen lassen. Siehe auch Logging mit iptables.

Moppen72 schrieb:

Nur zur Info, die Zeile unten war wohl das Problem. Die habe ich nun auskommentiert und kann nun offensichtlich die Pakete entsprechend durch die Firewall "manövrieren".

Hier meine rules.v4

1 2 3

# Generated by iptables-save v1.4.21 on Sun Apr 10 19:07:44 2016 -A POSTROUTING -o eth0 -j MASQUERADE # Completed on Sun Apr 10 19:07:44 2016