Hallo,
ich habe einen Rechner mit einem debian-wheezy als Host für ein paar virtuelle Machienen mit kvm. Dieser Rechner hat eine öffentliche Adresse und soll die Anfragen an die entsprechenden virtuellen Rechner weiterleiten.
Für den Teil, der die E-Mails bearbeitet ist folgendes im kvm-host eingetragen:
Der der kvm-host keine Dienste anbietet, ist in der "INPUT"-Kette nur ssh erlaubt, der Rest wird ins LOG geschrieben.
Ab und zu (ca. aller 4000 Pakete, dann aber meistens gleich 2 Stück zusammen) erhalte ich jedoch folgende Zeile im LOG:
wenn ich die Erklärung von http://64-bit.de/dokumentationen/netzwerk/e/002/DE-IPTABLES-HOWTO-3.html im Abschnitt 3.5 richtig verstanden habe, so dürften die Pakete nie bei "INPUT" ankommen ...
... wo ist hier der Fehler?
Kernel ist: 3.14.22.wheezymptcp #35 SMP Wed Nov 26 09:06:46 UTC 2014 x86_64 GNU/Linux
Hardy
ich habe einen Rechner mit einem debian-wheezy als Host für ein paar virtuelle Machienen mit kvm. Dieser Rechner hat eine öffentliche Adresse und soll die Anfragen an die entsprechenden virtuellen Rechner weiterleiten.
Für den Teil, der die E-Mails bearbeitet ist folgendes im kvm-host eingetragen:
Code:
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 993 -j DNAT --to-destination 192.168.154.33
iptables -A FORWARD -d 192.168.154.33 -o virbr0 -p tcp -m tcp --dport 993 -j ACCEPT
Der der kvm-host keine Dienste anbietet, ist in der "INPUT"-Kette nur ssh erlaubt, der Rest wird ins LOG geschrieben.
Ab und zu (ca. aller 4000 Pakete, dann aber meistens gleich 2 Stück zusammen) erhalte ich jedoch folgende Zeile im LOG:
Code:
Feb 12 11:39:33 xxx kernel: [1954817.097393] filter INPUT IN=eth0 OUT= MAC=zzz SRC=x1.x2.x3.x4 DST=y1.y2.y3.y4 LEN=40 TOS=0x00 PREC=0x00 TTL=54 ID=31235 DF PROTO=TCP SPT=55015 DPT=993 WINDOW=0 RES=0x00 RST URGP=0
wenn ich die Erklärung von http://64-bit.de/dokumentationen/netzwerk/e/002/DE-IPTABLES-HOWTO-3.html im Abschnitt 3.5 richtig verstanden habe, so dürften die Pakete nie bei "INPUT" ankommen ...
... wo ist hier der Fehler?
Kernel ist: 3.14.22.wheezymptcp #35 SMP Wed Nov 26 09:06:46 UTC 2014 x86_64 GNU/Linux
Hardy