Re: Probleme mit iptables-fw

Oliver Schad schrieb:

Aktuell sieht das so aus:
## Port 80 auf SQUID umleiten
$IPTABLES -t nat -A PREROUTING -i $INTDEV -d 127.0.0.1 -p tcp --dport
80 -j REDIRECT --to-port 3128

Falsches Ziel, lass es weg.

habe ich, geht - danke!

# Zugriff auf das Intranet
$IPTABLES -t filter -A INPUT -i $INTDEV -d $INTIP -p tcp --dport 80 -j
ACCEPT

Läuft wirklich auf dem Paketfilter ein Webserver, der von außen
erreichbar sein soll?

Da läuft ein Webserver, der von innen erreichbar sein soll - hat sich
aber wahrscheinlich heute auch erledigt.

2. Problem: Der Gateway macht ein VPN mit einer Cisco, auf
Debian-Seite läuft racoon. Über dieses VPN
läuft einen MySQL-Replikation zwischen 2 DB-Server, die jeweils hinter
dem Linux-GW und der Cisco stehen.

Das VPN steht, wir können auch von beiden Seiten den jeweils anderen
DB-Server anpingen.

D.h. von DB-Server zu DB-Server?

Jawohl

Hier sehen die Regeln so aus:

$IPTABLES -A FORWARD -s 192.168.255.250 -d 192.168.100.214 -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.100.214 -d 192.168.255.250 -j ACCEPT

Das sollte schon reichen. Verwende besser Shell-Variablen für die
IP-Adressen, das ist leichter lesbar und leichter wartbar.

$IPTABLES -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d 192.168.100.214
--dport 3306 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -p tcp -s 192.168.100.214 --sport 3306 -d 0/0
--dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Wofür sind diese beiden Regeln gedacht?

für die Replikation

Laut TCPdump bricht der Handshake auf dem Master ab, der mysql-connect
kommt beim master an, geht aber nicht mehr zurück

Wo bleibt er denn hängen? Bei der Cisco- oder der Linux-Kiste?

Schwer zu sagen. Der Slave wartet darauf, dass der Handshake
zurückkommt. Also, wir vermuten, er bleibt an der Linux-Kiste hängen.


co
.

Loading