Re: OpenVPN antwortet nicht
Hallo Tobias,
Am Donnerstag, den 12.01.2006, 14:37 +0100 schrieb Tobias Krais:
...
> Server:~# iptables -L -v -n
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 216K 301M ACCEPT all -- lo * 0.0.0.0/0
> 0.0.0.0/0
> 15351 2651K ACCEPT all -- eth0 * 0.0.0.0/0
> 0.0.0.0/0
> 249K 288M inet-in all -- eth1 * 0.0.0.0/0
> 0.0.0.0/0
> 29628 3550K DROP all -- eth1 * 0.0.0.0/0
> 0.0.0.0/0 state INVALID,NEW
> 201K 283M ACCEPT all -- * * 0.0.0.0/0
> 0.0.0.0/0 state RELATED,ESTABLISHED
Die Zahlen sind ja ganz schön groß. Vermutlich läuft die Firewall schon
eine Weile. Ich pflege sie für solche Tests neu zu starten, dann fangen
sie alle wieder bei 0 an.
Aber es geht auch anders. Die Ausgabe des Befehls in eine Datei
umleiten. Verbindungsversuch machen. Den Befehl wiederholen aber in eine
andere Datei umleiten. diff über die Dateien machen.
...
> Chain inet-in (1 references)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT tcp -- eth0 eth0 0.0.0.0/0
> 0.0.0.0/0 tcp dpts:138:139
> 0 0 ACCEPT tcp -- eth0 eth0 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:22
> 18946 1585K ACCEPT tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:22
> 0 0 ACCEPT all -- * * 131.211.28.48
> 0.0.0.0/0
> 0 0 LOG tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:2049 LOG flags 0 level 4
> 0 0 LOG udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:2049 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:2049
> 0 0 DROP udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:2049
> 0 0 LOG tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:5432 LOG flags 0 level 4
> 0 0 LOG udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:5432 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:5432
> 0 0 DROP udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:5432
> 0 0 LOG tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpts:5999:6003 LOG flags 0 level 4
> 0 0 LOG udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpts:5999:6003 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpts:5999:6003
> 0 0 DROP udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpts:5999:6003
> 0 0 LOG tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:7100 LOG flags 0 level 4
> 0 0 LOG udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:7100 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:7100
> 0 0 DROP udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:7100
> 0 0 LOG tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:31337 LOG flags 0 level 4
> 0 0 LOG udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:31337 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:31337
> 0 0 DROP udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpt:31337
> 0 0 LOG tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpts:12345:12346 LOG flags 0 level 4
> 0 0 LOG udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpts:12345:12346 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0
> 0.0.0.0/0 tcp dpts:12345:12346
> 0 0 DROP udp -- * * 0.0.0.0/0
> 0.0.0.0/0 udp dpts:12345:12346
...
> Zumindest in der Chain inet-in hätte ich die 1194 erwartet. ssh steht ja
> auch drin.
Ganz genau so sehe ich das auch. Außerdem kann ich mich nicht an soo
viele Regeln in Deinem Script erinnern (ach ja es war ja gekürtzt).
Jedenfalls kann ich mich des leisen Verdachts nicht erwehren, dass die
laufende Firewall nicht von dem Script stammt. Bitte prüfe mal, ob
in /etc/rc*.d irgendwo ein anderes Firewallscript aufgerufen wird.
Oder ringe Dich dazu durch das Script doch noch einmal laufen zu lassen.
Wenn ich mich recht erinnere, löscht es ja erst mal alle chains (-F
option) und baut sie neu auf.
...
> Ich habe folgenden Befehl ausgeführt und dann mit dem Client einen
> Verbindungsversuch gestartet:
> -----%<-----
> iptables -A INPUT -j LOG --log-prefix "input-DROP"
> Server:/etc/openvpn# tail -f /var/log/kern.log
> Jan 12 14:09:37 Server kernel: device eth1 left promiscuous mode
> Jan 12 14:10:00 Server kernel: eth1: Promiscuous mode enabled.
> Jan 12 14:10:00 Server kernel: device eth1 entered promiscuous mode
> Jan 12 14:10:05 Server kernel: device eth1 left promiscuous mode
> Jan 12 14:10:13 Server kernel: eth1: Promiscuous mode enabled.
> Jan 12 14:10:13 Server kernel: device eth1 entered promiscuous mode
> Jan 12 14:10:29 Server kernel: device eth1 left promiscuous mode
> Jan 12 14:13:30 Server kernel: eth1: Promiscuous mode enabled.
> -----%<-----
>
> Hab allerdings keine Ahnung, was der mit dem promiscuous mode macht...
tcpdump macht sowas.
Bei der Position des LOG Befehls habe ich nicht aufgepaßt. In der INPUT
chain befindet sich ein DROP Befehl. Auch wenn er nur INVALID,NEW
abfängt, dürfte das für die Versuche mit OpenVPN reichen. Es bleibt also
nichts übrig, als den LOG Befehl davor zu setzen und das Script neu zu
starten. Oder Du versuchst, die Regel mit iptables -I INPUT 4 usw. vor
die DROP Regel zu bekommen.
>
> > Wenn alles darauf hin deutet, dass OpenVPN die Pakete bekommt, hilft
> > vielleicht 'strace' zu sehen, ob dem wirklich so ist.
>
> Ich schließe daraus, dass openvpn keine Pakete bekommt...
Ja. Es sieht so aus. Der LOG Eintrag an der richtigen Position sollte
das auch beweisen können.
>
> > Und dann sollten da noch OpenVPN-Logeinträge in /var/log/daemon.log
> > sein.
>
> Ne, den gibts bei mir nicht, die landen in der syslog. Aber selbst mit
> verb=9 kommt da nichts hilfreiches rein...
Naja. Wenn keine Pakete ankommen. Aber im Prinzip sind doch Einträge
dieser Art drin oder?
Jan 12 09:25:28 chilla ovpn-MySQLVPN--udp[4517]: OpenVPN 2.0.5
i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Nov 7 2005
Gruß,
Ingo
--
Ingo Strüwing, Senior Software Developer
MySQL AB, www.mysql.de
Reply to: