iptables: internet -> Firewall -> PC -> per ISDN auf PC:5900
Hallo, ich habe mit iptables bisher wenig gemacht und das Ding PC -> internet -> Firewall:3333 -> meinPC -> per ISDN auf fremdPC:5900 also der VNC-Zugriff auf den Desktop eines fremden PC, der nur über ISDN erreichbar ist, kurzzeitig aus dem Internet erreichbar zu machen, überfordert meine Kenntnisse, wie ich da ran gehe. Wer kann mit sagen, was für iptables-Regeln ich da grundsätzlich brauche, wo ich anfange? Ich meine wo brauche ich ein forward, ein prerouting, ... firewall: dyndns-Adresse, port z.B. 3333 meinPC: 192.168.0.52 fremdPC: 192.168.10.16 Port 5900 (vnc) danke schon mal Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo. * Sonntag, 09. März 2008 um 16:49 (+0100) schrieb Ekkard Gerlach:
ich habe mit iptables bisher wenig gemacht und das Ding
PC -> internet -> Firewall:3333 -> meinPC -> per ISDN auf fremdPC:5900
also der VNC-Zugriff auf den Desktop eines fremden PC, der nur über ISDN erreichbar ist, kurzzeitig aus dem Internet erreichbar zu machen, überfordert meine Kenntnisse, wie ich da ran gehe.
[ ... ]
firewall: dyndns-Adresse, port z.B. 3333 meinPC: 192.168.0.52 fremdPC: 192.168.10.16 Port 5900 (vnc)
Wie lauten die IPs der (ISDN-)PPP-Verbindung auf "meinPC" und "fremdPC"? Angenommen die IPs sind 192.168.40.1 ("meinPC") und 192.168.40.2 ("fremdPC"), dann geht z.B. einfaches NAT: Auf "firewall": 'iptables -t nat -A PREROUTING --dport 3333 -j DNAT --to-destination 192.168.40.2:5900' und 'iptables -A FORWARD -d 192.168.40.2 --dport 5900 -j ACCEPT' Dazu ein Routing-Eintrag (auf "firewall") 'route add -net 192.168.40.0 netmask 255.255.255.0 gw 192.168.0.52'. Auf "meinPC" muss "IP-Forwarding" aktiviert sein und in der FORWARD-Chain sollte nicht gefiltert werden (sonst ebenfalls obige 'iptables -A FORWARD ...' einfügen. Gruß Andreas -- XMMS spielt gerade nichts... GPG-ID/Fingerprint: 6F28CF96/0B3B C287 30CE 21DF F37A AF63 A46C D899 6F28 CF96 GPG-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Andreas Koenecke schrieb:
* Sonntag, 09. März 2008 um 16:49 (+0100) schrieb Ekkard Gerlach:
ich habe mit iptables bisher wenig gemacht und das Ding
PC -> internet -> Firewall:3333 -> meinPC -> per ISDN auf fremdPC:5900
also der VNC-Zugriff auf den Desktop eines fremden PC, der nur über ISDN erreichbar ist, kurzzeitig aus dem Internet erreichbar zu machen, überfordert meine Kenntnisse, wie ich da ran gehe.
[ ... ]
firewall: dyndns-Adresse, port z.B. 3333 meinPC: 192.168.0.52 fremdPC: 192.168.10.16 Port 5900 (vnc)
Wie lauten die IPs der (ISDN-)PPP-Verbindung auf "meinPC" und "fremdPC"? Angenommen die IPs sind 192.168.40.1 ("meinPC") und 192.168.40.2 ("fremdPC"), dann geht z.B. einfaches NAT: ... wäre klasse ...
Auf "firewall":
'iptables -t nat -A PREROUTING --dport 3333 -j DNAT --to-destination 192.168.40.2:5900'
-p tcp habe ich mal eingefügt, sonst Fehlermeldung "unknown .. dport option" Muss es nicht --sport 3333 heissen? und zusätzlich --dport 5900 dastehen? also: iptables -A FORWARD -d 192.168.10.220 -p tcp --sport 3333 --dport 5900 -j ACCEPT
und
'iptables -A FORWARD -d 192.168.40.2 --dport 5900 -j ACCEPT'
auch hier -p tcp. Muss hier nicht auch --sport 3333 dazu? also: iptables -A PREROUTING -t nat -p tcp --sport 3333 --dport 5900 -j DNAT --to-destination 192.168.10.220:5900 so gemacht: iptables -L auf der Firewall: ACCEPT tcp -- anywhere 192.168.10.220 tcp spt:3333 dpt:5900 Port 333 auf "firewall" ist offen: von einem PC im Web aus: telnet myfirewall.dyndns.org 3333 -> trying ... -> connected to ....-> exit
Dazu ein Routing-Eintrag (auf "firewall")
'route add -net 192.168.40.0 netmask 255.255.255.0 gw 192.168.0.52'.
ok. route add -net 192.168.10.0/24 gw 192.168.0.52 aber ein vnc-Zugriff mit krdc myfirewall.dyndns.org 3333 meldet, dass der Zielrechner keine Verb. mehr akzeptiert (es gibt keine andere (zweite!) Verb.!) Ich stelle gerade fest, dass von "firewall" aus kein ping auf 192.168.10.220 möglich ist obwohl cat /proc/sys/net/ipv4/ip_forward die 1 ausgibt und das routing auf myPC stimmt und iptables -L auf myPc leer ist (alles frei!). firewall: fli4l 3.0.1 # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 213.191.89.17 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.254.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.0 192.168.0.52 255.255.255.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 myPC: rex3:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.10.220 0.0.0.0 255.255.255.255 UH 0 0 0 ippp2 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 ippp2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 Weiss der Geier warum! Es ist derzeit wohl noch ein Routing-Problem, leider habe ich heute und morgen keine Zeit dafür .... ich melde mich wieder. besten Dank Andreas! Gruss Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Ekkard. * Mittwoch, 12. März 2008 um 09:09 (+0100) schrieb Ekkard Gerlach:
* Andreas Koenecke schrieb:
* Sonntag, 09. März 2008 um 16:49 (+0100) schrieb Ekkard Gerlach:
PC -> internet -> Firewall:3333 -> meinPC -> per ISDN auf fremdPC:5900
Angenommen die IPs sind 192.168.40.1 ("meinPC") und 192.168.40.2 ("fremdPC"), dann geht z.B. einfaches NAT: ... wäre klasse ...
Auf "firewall":
'iptables -t nat -A PREROUTING --dport 3333 -j DNAT --to-destination 192.168.40.2:5900'
-p tcp habe ich mal eingefügt, sonst Fehlermeldung "unknown .. dport option"
Ja, das vergesse ich immmer wieder...
Muss es nicht --sport 3333 heissen? und zusätzlich --dport 5900 dastehen? also: iptables -A FORWARD -d 192.168.10.220 -p tcp --sport 3333 --dport 5900 -j ACCEPT
Nein, der Source-Port wird bei der Destination-NAT nicht umgeschrieben, wird vom Client generiert und ist mehr oder weniger beliebig, ist zum Matchen also nicht geeignet.
'iptables -A FORWARD -d 192.168.40.2 --dport 5900 -j ACCEPT' auch hier -p tcp. Muss hier nicht auch --sport 3333 dazu? also: iptables -A PREROUTING -t nat -p tcp --sport 3333 --dport 5900 -j DNAT --to-destination 192.168.10.220:5900
Du hast jetzt die Bezüge FORWARD-/PREROUTING-Chain vertauscht, so dass sich das etwas verwirrend liest. Deshalb nochmal zusammenfassend: 'iptables -t nat -A PREROUTING -p tcp --dport 3333 -j DNAT --to-destination 192.168.10.220:5900' Hier kannst du ebenfalls nicht auf den Source-Port matchen, da er i.A. nicht bekannt ist. 'iptables -A FORWARD -p tcp -d 192.168.10.220 --dport 5900 -j ACCEPT' s.o.
so gemacht: iptables -L auf der Firewall: ACCEPT tcp -- anywhere 192.168.10.220 tcp spt:3333 dpt:5900
Diese Regel wird -- wenn überhaupt -- wegen des Source-Ports so gut wie nie passen.
Port 333 auf "firewall" ist offen: von einem PC im Web aus: telnet myfirewall.dyndns.org 3333 -> trying ... -> connected to ....-> exit
D.h. es funktioniert? Dann muss es noch eine andere Regel in der FORWARD-Chain geben, die die Pakete durchlässt (oder Policy ACCEPT, aber dann sollte der Rechner nicht "firewall" heißen ;-))
aber ein vnc-Zugriff mit krdc myfirewall.dyndns.org 3333 meldet, dass der Zielrechner keine Verb. mehr akzeptiert (es gibt keine andere (zweite!) Verb.!)
Ich stelle gerade fest, dass von "firewall" aus kein ping auf 192.168.10.220 möglich ist obwohl cat /proc/sys/net/ipv4/ip_forward die 1 ausgibt und das routing auf myPC stimmt und iptables -L auf myPc leer ist (alles frei!).
Gibt das 'ping' eine Fehlermeldung aus oder wartet es einfach auf das Antwort-Paket? (Die Routing-Tabellen passen IMO.)
Weiss der Geier warum! Es ist derzeit wohl noch ein Routing-Problem, leider habe ich heute und morgen keine Zeit dafür .... ich melde mich wieder.
Eventuell stimmt die Route auf "fremdPC" nicht. Entweder muss die Default-Route wieder zurück auf "meinPC" zeigen (das macht der '(i)pppd' "normalerweise") oder er braucht eine Route für "firewall"/"firewall"-Netz mit Gateway "meinPC". Gruß Andreas -- XMMS spielt gerade nichts... GPG-ID/Fingerprint: 6F28CF96/0B3B C287 30CE 21DF F37A AF63 A46C D899 6F28 CF96 GPG-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Andreas Koenecke schrieb:
'iptables -t nat -A PREROUTING -p tcp --dport 3333 -j DNAT --to-destination 192.168.10.220:5900' Hier kannst du ebenfalls nicht auf den Source-Port matchen, da er i.A. nicht bekannt ist. 'iptables -A FORWARD -p tcp -d 192.168.10.220 --dport 5900 -j ACCEPT' ok. Habe jetzt mehr verstanden. Dann noch das: route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.0.52
Ich stelle gerade fest, dass von "firewall" aus kein ping auf 192.168.10.220 möglich ist obwohl cat /proc/sys/net/ipv4/ip_forward die 1 ausgibt und Habe nach Deinem Hinweis ein route add -net 192.168.0.0/24 ippp1 auf dem "fremdPC" gemacht, für den "Rückweg". Jetzt geht ping von der Firewall! Für Pakete aus dem Internet ist dann natürlich eine default-route erforderlich: route add default ippp1.
Nach wie vor komme ich aber nicht zum Ziel. Gehe ich von einem anderen PC im Internet (Laptop mit UMTS-Verbindng über Handy) auf myfirewall.dyndns.org:3333, dann bekomme ich bei # telnet myfirewall.dyndns.org 3333 einen offenen Port: amilo:/home/gerlach # telnet <myfirewall>.dyndns.org 3333 Trying 85.180.67.181... Connected to xxxxxxxxxxxx.dyndns.org. Escape character is '^]'. Ein krdc auf die firewall meldet: entfernter Host akzeptiert keine Verbindung. Wandle ich den FORWARD von --dport 5900 auf --dport 22 ab, einfach mal um zu sehen ob ich per ssh auf "firewallPC", also gerlach@amilo:/home/linuxburg/inf> ssh -p 3333 root@XXXXXXXXXX.dyndns.org -v OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to XXXXXXXXXXXXXX.dyndns.org [85.180.68.64] port 3333. debug1: Connection established. debug1: identity file /home/gerlach/.ssh/identity type -1 debug1: identity file /home/gerlach/.ssh/id_rsa type -1 debug1: identity file /home/gerlach/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host Das dauert ca. 5 Minuten. Vorher hatte ich die firewall neu gebootet, damit das Forwarding auf 5900 nicht in die Quere kommt. Also geht noch nichts durch. Das Forward auf der firewall scheint nicht zu funktionieren. Warum? Ein tcpdump seitens des fremdPC auf ippp1 (Einwahl-device) zeigt währenddessen nichts an! Ein tcpdump auf meinPC zeigt ständig was an, ich vermute nichts von dem ssh-Aufruf bis auch etwas wie das: 21:25:40.450532 arp who-has fli4l tell rex3.site 21:25:40.450809 arp reply fli4l is-at 00:00:f4:b2:42:e7 kommt zu meinPC durch. Ideen? Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Ekkard. * Freitag, 14. März 2008 um 21:48 (+0100) schrieb Ekkard Gerlach:
[ DNAT vnc ]
Nach wie vor komme ich aber nicht zum Ziel. Gehe ich von einem anderen PC im Internet (Laptop mit UMTS-Verbindng über Handy) auf myfirewall.dyndns.org:3333, dann bekomme ich bei
# telnet myfirewall.dyndns.org 3333 einen offenen Port: amilo:/home/gerlach # telnet <myfirewall>.dyndns.org 3333 Trying 85.180.67.181... Connected to xxxxxxxxxxxx.dyndns.org. Escape character is '^]'.
Hm, seltsam... Da fehlt -- sofern es sich um den vncserver handelt -- noch eine Zeile wie z.B. "RFB 003.008".
Ein krdc auf die firewall meldet: entfernter Host akzeptiert keine Verbindung.
Wandle ich den FORWARD von --dport 5900 auf --dport 22 ab, einfach mal um zu sehen ob ich per ssh auf "firewallPC", also gerlach@amilo:/home/linuxburg/inf> ssh -p 3333 root@XXXXXXXXXX.dyndns.org -v OpenSSH_4.4p1, OpenSSL 0.9.8d 28 Sep 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to XXXXXXXXXXXXXX.dyndns.org [85.180.68.64] port 3333. debug1: Connection established. debug1: identity file /home/gerlach/.ssh/identity type -1 debug1: identity file /home/gerlach/.ssh/id_rsa type -1 debug1: identity file /home/gerlach/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host
Das dauert ca. 5 Minuten.
Mich wundert, dass überhaupt eine Art Verbindung hergestellt wird. Die beiden 'iptables'-Zeilen gehen nur zusammen, das IP:Port beim "--to-destination" der PREROUTING-Zeile muss mit den "-d <IP>" und "--dport <Port>" der FORWARD-Zeile übereinstimmen. (BTW: Die PREROUTING-Zeile ist für das Forwarding zuständig und die FORWARD-Zeile lässt die "geforwardeten" Pakete passieren.)
Also geht noch nichts durch. Das Forward auf der firewall scheint nicht zu funktionieren. Warum?
Ein tcpdump seitens des fremdPC auf ippp1 (Einwahl-device) zeigt währenddessen nichts an! Ein tcpdump auf meinPC zeigt ständig was an, ich vermute nichts von dem ssh-Aufruf bis auch etwas wie das:
21:25:40.450532 arp who-has fli4l tell rex3.site 21:25:40.450809 arp reply fli4l is-at 00:00:f4:b2:42:e7
Das ist ein normaler arp-Request/-Reply und hat nichts mit dem Problem zu tun.
Ideen?
Mehrere: - Es kann sein, dass die Antwortpakete nicht zurückkommen. Obwohl ich meine gelesen zu haben, dass Antwortpakete von "geNATteten" Pakten nicht mehr durch die FORWARD-Chain zurück müssen, bin ich mir jetzt nicht mehr sicher. Gib doch noch bitte zusätzlich zu den geposteten Befehlen ein 'iptables -A FORWARD -p tcp -s 192.168.10.220 --sport 5900 -j ACCEPT' ein. - Poste doch bitte die Ausgaben von 'iptables -t nat -L -n -v' und 'iptables -L FORWARD -n -v'. Danach sehen wir dann weiter... Gruß Andreas -- XMMS spielt gerade "Blue Oyster Cult - Harvester of Eyes (Bonus track)"... GPG-ID/Fingerprint: 6F28CF96/0B3B C287 30CE 21DF F37A AF63 A46C D899 6F28 CF96 GPG-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ich habe den Versuch mal vereinfacht: nur auf port 5900 von "meinPC" zugreifen, nicht gleich den "großen Wurf" noch über ISDN. Und auch das geht nicht mit: iptables -t nat -A PREROUTING -p tcp --dport 3333 -j DNAT --to-destination 192.168.0.52:5900 iptables -A FORWARD -p tcp -d 192.168.0.52 --dport 5900 -j ACCEPT (route add .... unnötig, weil firewall 192.168.0.1 im gleichen Subnet) Dazu dann auch noch damit getestet: iptables -A FORWARD -p tcp -s 192.168.0.52 --sport 5900 -j ACCEPT Und immer noch nicht! Lasse ich das Laptop dann über mein LAN auf meinPC 192.168.0.52 zugreifen, gehts! Also ist 5900 von meinPC offen. Übrigens: eröffne ich einen Tunnel vom Laptop mit ssh -L 1123:192.168.0.52:5900 <myfirewall>.dyndns.org dann funktioniert krdc localhost:1123 sehr gut. Es will einfach das Forwarding nicht! * Andreas Koenecke schrieb:
Ideen?
Mehrere:
- Es kann sein, dass die Antwortpakete nicht zurückkommen. Obwohl ich meine gelesen zu haben, dass Antwortpakete von "geNATteten" Pakten nicht mehr durch die FORWARD-Chain zurück müssen, bin ich mir jetzt nicht mehr sicher. Gib doch noch bitte zusätzlich zu den geposteten Befehlen ein 'iptables -A FORWARD -p tcp -s 192.168.10.220 --sport 5900 -j ACCEPT' ein.
- Poste doch bitte die Ausgaben von 'iptables -t nat -L -n -v' und
'iptables -L FORWARD -n -v'. fli4l 3.0.1 # iptables -L FORWARD -n -v Chain FORWARD (policy DROP 0 packets, 0 bytes)
jetzt für den einfach Fall wie oben beschrieben: fli4l 3.0.1 # iptables -t nat -L -n -v Chain PREROUTING (policy ACCEPT 631 packets, 56482 bytes) pkts bytes target prot opt in out source destination 0 0 pre-in-ovpn all -- tun+ * 0.0.0.0/0 0.0.0.0/0 /* if:tun+:any pre-in-ovpn */ 0 0 DNAT tcp -- * * 0.0.0.0/0 85.180.66.205 tcp dpt:2222 to:192.168.0.52:22 11 704 DNAT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3333 to:192.168.0.52:5900 Chain POSTROUTING (policy ACCEPT 263 packets, 10826 bytes) pkts bytes target prot opt in out source destination 0 0 post-out-ovpn all -- * tun+ 0.0.0.0/0 0.0.0.0/0 /* if:any:tun+ post-out-ovpn */ 46 2760 MASQUERADE all -- * * 192.168.0.0/24 0.0.0.0/0 /* POSTROUTING_LIST_1='IP_NET_1 MASQUERADE' */ 0 0 MASQUERADE all -- * * 192.168.1.0/24 0.0.0.0/0 /* POSTROUTING_LIST_2='IP_NET_2 MASQUERADE' */ Chain OUTPUT (policy ACCEPT 17 packets, 986 bytes) pkts bytes target prot opt in out source destination Chain post-out-ovpn (1 references) pkts bytes target prot opt in out source destination 0 0 post-out-ovpn-testuser all -- * tun0 0.0.0.0/0 0.0.0.0/0 /* if:any:tun0 post-out-ovpn-testuser */ 0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0 /* if:any:tun+ ACCEPT */ Chain post-out-ovpn-testuser (1 references) pkts bytes target prot opt in out source destination Chain pre-in-ovpn (1 references) pkts bytes target prot opt in out source destination 0 0 pre-in-ovpn-testuser all -- tun0 * 0.0.0.0/0 0.0.0.0/0 /* if:tun0:any pre-in-ovpn-testuser */ Chain pre-in-ovpn-testuser (1 references) pkts bytes target prot opt in out source destination pkts bytes target prot opt in out source destination 55 3300 TCPMSS tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 2003 740K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED /* FORWARD_ACCEPT_DEF */ 0 0 DROP all -- * * 127.0.0.1 0.0.0.0/0 state NEW /* FORWARD_ACCEPT_DEF */ 0 0 DROP all -- * * 0.0.0.0/0 127.0.0.1 state NEW /* FORWARD_ACCEPT_DEF */ 97 5988 PORTFWACCESS all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW /* state:NEW PORTFWACCESS */ 0 0 fw-ovpn all -- * tun+ 0.0.0.0/0 0.0.0.0/0 /* ovpn VPN traffic */ 0 0 fw-ovpn all -- tun+ * 0.0.0.0/0 0.0.0.0/0 /* ovpn VPN traffic */ 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 /* FORWARD_LIST_1='tmpl:samba DROP' */ 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445 /* FORWARD_LIST_1='tmpl:samba DROP' */ 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:138 /* FORWARD_LIST_1='tmpl:samba DROP' */ 55 3300 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0 /* FORWARD_LIST_2='IP_NET_1 ACCEPT' */ 0 0 ACCEPT all -- * * 192.168.1.0/24 0.0.0.0/0 /* FORWARD_LIST_3='IP_NET_2 ACCEPT' */ 42 2688 fw-rej all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.52 tcp dpt:5900 0 0 ACCEPT tcp -- * * 192.168.0.52 0.0.0.0/0 tcp spt:5900
Danach sehen wir dann weiter...
Gruß
Andreas
Danke Dir, Gruss Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Ekkard. * Samstag, 15. März 2008 um 00:39 (+0100) schrieb Ekkard Gerlach:
Ich habe den Versuch mal vereinfacht: nur auf port 5900 von "meinPC" zugreifen, nicht gleich den "großen Wurf" noch über ISDN. Und auch das geht nicht mit:
iptables -t nat -A PREROUTING -p tcp --dport 3333 -j DNAT --to-destination 192.168.0.52:5900 iptables -A FORWARD -p tcp -d 192.168.0.52 --dport 5900 -j ACCEPT (route add .... unnötig, weil firewall 192.168.0.1 im gleichen Subnet)
Dazu dann auch noch damit getestet: iptables -A FORWARD -p tcp -s 192.168.0.52 --sport 5900 -j ACCEPT Und immer noch nicht! Lasse ich das Laptop dann über mein LAN auf meinPC 192.168.0.52 zugreifen, gehts! Also ist 5900 von meinPC offen. Übrigens: eröffne ich einen Tunnel vom Laptop mit ssh -L 1123:192.168.0.52:5900 <myfirewall>.dyndns.org dann funktioniert krdc localhost:1123 sehr gut. Es will einfach das Forwarding nicht!
* Andreas Koenecke schrieb:
- Poste doch bitte die Ausgaben von 'iptables -t nat -L -n -v' und
jetzt für den einfach Fall wie oben beschrieben: fli4l 3.0.1 # iptables -t nat -L -n -v Chain PREROUTING (policy ACCEPT 631 packets, 56482 bytes) pkts bytes target prot opt in out source destination 0 0 pre-in-ovpn all -- tun+ * 0.0.0.0/0 0.0.0.0/0 /* if:tun+:any pre-in-ovpn */ 0 0 DNAT tcp -- * * 0.0.0.0/0 85.180.66.205 tcp dpt:2222 to:192.168.0.52:22
Funktioniert denn die ssh-Weiterleitung?
11 704 DNAT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3333 to:192.168.0.52:5900
OK, 11 Pakete sind durch, das funktioniert (zumindest prinzipiell...).
'iptables -L FORWARD -n -v'.
fli4l 3.0.1 # iptables -L FORWARD -n -v Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 55 3300 TCPMSS tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 2003 740K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED /* FORWARD_ACCEPT_DEF */
Die vorhin gepostete Regel für die Antwortpakete kannst du dir sparen, obige Regel deckt das ab.
0 0 DROP all -- * * 127.0.0.1 0.0.0.0/0 state NEW /* FORWARD_ACCEPT_DEF */ 0 0 DROP all -- * * 0.0.0.0/0 127.0.0.1 state NEW /* FORWARD_ACCEPT_DEF */ 97 5988 PORTFWACCESS all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW /* state:NEW PORTFWACCESS */
Anscheinend hat fli4l einen "Mechanismus" für Portforwarding aka DNAT. Aber erst einmal egal...
0 0 fw-ovpn all -- * tun+ 0.0.0.0/0 0.0.0.0/0 /* ovpn VPN traffic */ 0 0 fw-ovpn all -- tun+ * 0.0.0.0/0 0.0.0.0/0 /* ovpn VPN traffic */ 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 /* FORWARD_LIST_1='tmpl:samba DROP' */ 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445 /* FORWARD_LIST_1='tmpl:samba DROP' */ 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:138 /* FORWARD_LIST_1='tmpl:samba DROP' */ 55 3300 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0 /* FORWARD_LIST_2='IP_NET_1 ACCEPT' */ 0 0 ACCEPT all -- * * 192.168.1.0/24 0.0.0.0/0 /* FORWARD_LIST_3='IP_NET_2 ACCEPT' */
42 2688 fw-rej all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.52 tcp dpt:5900
Aha, höchstwahrscheinlich werden die Pakete in der Chain "fw-rej" zurückgewiesen. "Unsere" 'iptables -A FORWARD...'-Regel wird dann gar nicht mehr erreicht. Gib statt 'iptables -A FORWARD -p tcp -d 192.168.10.220 --dport 5900 -j ACCEPT' mal 'iptables -I FORWARD 1 -p tcp -d 192.168.10.220 --dport 5900 -j ACCEPT' (bzw. "-d 192.168.0.52") ein. Gruß Andreas -- XMMS spielt gerade nichts... GPG-ID/Fingerprint: 6F28CF96/0B3B C287 30CE 21DF F37A AF63 A46C D899 6F28 CF96 GPG-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Andreas Koenecke schrieb: [...] ja portforwarding von 2222 auf 22 geht einwandfrei, wollte ich aber schon längst rausgeworfen haben, brauche ich nicht mehr, es ist nur eine Sicherheitslücke mehr.
42 2688 fw-rej all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.52 tcp dpt:5900
Aha, höchstwahrscheinlich werden die Pakete in der Chain "fw-rej" zurückgewiesen. "Unsere" 'iptables -A FORWARD...'-Regel wird dann gar nicht mehr erreicht.
Gib statt 'iptables -A FORWARD -p tcp -d 192.168.10.220 --dport 5900 -j ACCEPT' mal 'iptables -I FORWARD 1 -p tcp -d 192.168.10.220 --dport 5900 -j ACCEPT' (bzw. "-d 192.168.0.52") ein.
Funktioniert BEIDES, krdc auf meinPC und fremdPC! Super! Vielen Dank! Werde mir mal morgen Dein Kunstwerk mal genauer ansehen. Gruss und gute Nacht Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (2)
-
Andreas Koenecke -
Ekkard Gerlach