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