aktuell versuche ich auf meiner Test-Kiste mein zukünftiges Root-Server Setup zu fahren und stoße hier auf ein Problem, wo ich nach vielen versuchen nicht mehr weiterkomme und deshalb hier Rat suche.
Folgende Konstellation liegt vor:
Host
OS: Debian 7.5
Hypervisor: KVM + libvirt
Interfaces
eth0: 123.123.123.123 --> Fiktive, public IP
virbr0: 192.168.122.1 / 24
vnet0...vnetN: VM-Adapter, in der Bridge virbr0
DNS
example.com IN MX 10 mail
mail IN A 123.123.123.123
VMs
VMMail: 192.168.199.2
VMTest: 192.168.199.3
Routing / IPTables
Vorab: Die standardmäßig von libvirt erzeugten NAT-Rules habe ich bewusst entfernt aufgrund des unten beschriebenen Problemes.
Code: Alles auswählen
# iptables -L -v -t nat
Chain PREROUTING (policy ACCEPT 259 packets, 24052 bytes)
pkts bytes target prot opt in out source destination
251 14988 DNAT tcp -- any any anywhere anywhere tcp dpt:smtp to:192.168.122.2:25
Chain INPUT (policy ACCEPT 165 packets, 18168 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 42 packets, 3274 bytes)
pkts bytes target prot opt in out source destination
17 1020 DNAT tcp -- any any anywhere anywhere tcp dpt:smtp to:192.168.122.2:25
Chain POSTROUTING (policy ACCEPT 54 packets, 3986 bytes)
pkts bytes target prot opt in out source destination
16 960 MASQUERADE all -- any any 192.168.122.0/24 !192.168.122.0/24
# iptables -L -v
Chain INPUT (policy ACCEPT 18184 packets, 2144K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 7662 packets, 6143K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 18753 packets, 3004K bytes)
pkts bytes target prot opt in out source destination
Auf VMMail ist ein Postfix-MTA, der eingehende und ausgehende Mails bearbeiten soll. Das funktioniert aufgrund der oben festgelegten IPTables-Rules von außerhalb sehr gut.
Versucht also z.B. GMX von außerhalb auf Port 25 des Hosts zu verbinden wird die Verbindung korrekt an die VM VMMail weitergeleitet und eine Mail kann abgesetzt werden.
Versucht nun aber Postfix eine Mail „an sich selbst“ auszuliefern (Mail To: mail@example.com) so versucht der MTA natürlich den für example.com zuständigen MX-Record aufzulösen und kommt zum Ergebnis, dass dieser auf mail.example.com, sprich die IP 123.123.123.123 zeigt und unternimmt den Veresuch, eine entsprechende Verbindung hierhin aufzubauen. Leider schlägt dies mit einem CONNECTION TIMEOUT fehl (mailq):
Code: Alles auswählen
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
730xxxxxxA8 2877 Wed Jun 18 08:00:03 mail@mail.example.com
(connect to mail.exmaple.com[123.123.123.123]:25: Connection timed out) mail@mail.exmaple.com
Externe IP --> 123.123.123.123:25 (Host-IP)
Code: Alles auswählen
zh-p-cl-wol:~# telnet mail.example.com 25
Trying 123.123.123.123...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Code: Alles auswählen
vmtest:~# telnet mail.example.com 25
Trying 123.123.123.123...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
Code: Alles auswählen
vmmail:~# telnet mail.example.com 25
Trying 123.123.123.123...
telnet: Unable to connect to remote host: [color=#FF0000]Connection timed out[/color]
VMMail --> 192.168.122.1:25 (VMMail)
Code: Alles auswählen
vmmail:~# telnet 192.168.122.2 25
Trying 192.168.122.2...
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Postfix (Debian/GNU)
QUIT
221 2.0.0 Bye
Connection closed by foreign host.
1. Wie kommt der Timeout zustande und
2. ist es überhaupt möglich, dass ein Paket den Weg vom POSTROUTING erneut in PREROUTING findet und quasi zurück zur VM geschickt wird oder muss hier ggf. ein Transfer-Netz dazwischen?
Eigentlich war ich der Auffassung, dass IP-Pakete mit den IPTables-Rules des Hosts wieder zurücktransportiert werden auf die VM VMMail. Hmm.. sieht wohl nicht danach aus.
Was ich erreichen möchte ist, dass möglichst keine iptables-Rules auf den VM’s gesetzt werden müssen, sondern alle TCP-Verbindungen zentral vom Host verwaltet werden.
Spontan fallen mir noch Möglichkeiten ein, wie z.B. eine Gateway-VM zu definieren, die zwischen dem VM-Netz 192.168.122.0 und dem Host vermittelt, oder den Einsatz von VLANs zur besseren Segmentierung. Aber ich bin (vorerst) der Meinung, dass es auch „Out-of-the-Box“ mit iptables funktionieren kann.
Was meint ihr? Liege ich falsch? Spielt mir IPTables oder irgendein Routing einen Streich, oder habe ich ein falsches Verständnis?
Oder ist mein Ansatz einfach… ehhmm.. „falsch“ ?
![Razz :-P](./images/smilies/icon_razz.gif)
Irgendwelche tcpdump’s, etc. habe ich vorerst mal rausgelassen, um den Rahmen einer Erst-Frage nicht zu sprengen, diese können aber gerne bei Bedarf geliefert werden.
Über weitere Ideen, Vorschläge und auch Kritik Eurerseits freue ich mich sehr
![Smile :-)](./images/smilies/icon_smile.gif)
Vielen Dank im Voraus und sonnige Grüße,
Wolfgang