Xen und serverloft die 2.

O

omnivagus

New Member
Xen und serverloft - kein Ping nach außen

Ich habe zu diesem Problem einen neuen Thread aufgemacht, weil sich meine Vorgehensweise hier von der vorherigen (thefreak) etwas unterscheidet. Wahrscheinlich habe ich zu diesem Thema mittlerweile alle Dokus gelesen und getestet - ohne Erfolg. Fällt irgendjemanden etwas auf/ein? Übrigens ist das Ubuntu 64 - dom0 und domU. Das wird langsam frustrierend... bin für jeden Hinweis dankbar!

edit: mit etch/etch gehts auch nicht.


meine IPs
Code: 
 IP: 85.25.120.10x 
    Gateway:: 85.25.120.65 
    Netmask: 255.255.255.192 
    Broadcast: 85.25.120.127 

    zusätzliche IP
 •  IP: 85.25.122.23y 
    Netmask: 255.255.255.128 
    Broadcast: 85.25.122.255


/etc/xen/xend-config.sxp
Code: 
(network-script network-route)
(vif-script     vif-route)


Code: 
vif = [ 'ip=85.25.122.23y' ]


/etc/xen/scripts/network-route
Code: 
echo 1 >/proc/sys/net/ipv4/ip_forward
echo 1 >/proc/sys/net/ipv4/conf/default/proxy_arp
echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 >/proc/sys/net/ipv4/conf/all/rp_filter


/etc/xen/scripts/vif-common.sh
Code: 
ip addr show "$1" | awk "/^.*inet.*$1\$/{print \$2}" | sed -n '1 s,/.*,,p'
in
Code: 
ip -4 -o addr show primary dev $1 | awk '$3 == "inet" {print $4; exit}' | sed 's!/.*!!'
geändert



dom0
Code: 
auto eth0
iface eth0 inet static
  address 85.25.120.10x
  netmask 255.255.255.255
  gateway 85.25.120.65
  pointopoint 85.25.120.65


  eth0    Link encap:Ethernet  HWaddr 00:40:d0:bf:e6:33  
          inet addr:85.25.120.10x  Bcast:85.255.255.255  Mask:255.255.255.255

  vif1.0  Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
          inet addr:85.25.120.10x  Bcast:85.255.255.255  Mask:255.255.255.255


route -n
  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  85.25.120.65    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
  85.25.122.23y   0.0.0.0         255.255.255.255 UH    0      0        0 vif1.0
  0.0.0.0         85.25.120.65    0.0.0.0         UG    100    0        0 eth0


iptables -L -n
  target     prot opt source               destination         
  ACCEPT     all  --  85.25.122.23y        0.0.0.0/0           PHYSDEV match --physdev-in vif1.0 
  ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vif1.0 udp spt:68 dpt:67


PING 85.25.122.23x (85.25.122.23x) 56(84) bytes of data.
64 bytes from 85.25.122.23x: icmp_seq=1 ttl=64 time=0.039 ms


domU
Code: 
eth0   Link encap:Ethernet  HWaddr 00:16:3e:38:f2:a5  
   inet addr:85.25.122.23y  Bcast:85.255.255.255  Mask:255.255.255.255
   inet6 addr: fe80::216:3eff:fe38:f2a5/64 Scope:Link

iface eth0 inet static
 address 85.25.122.23y
 gateway 85.25.120.10x
 netmask 255.255.255.255
 pointopoint 85.25.120.10x
 post-up  ethtool -K eth0 tx off


route -n
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   85.25.122.23x   0.0.0.0         255.255.255.255 UH    0      0        0 eth0
   0.0.0.0         85.25.122.23x   0.0.0.0         UG    100    0        0 eth0


PING 85.25.120.10x (85.25.120.10x) 56(84) bytes of data.
64 bytes from 85.25.120.10x: icmp_seq=1 ttl=64 time=0.316 ms

root@blub:~# ping 85.25.120.65
PING 85.25.120.65 (85.25.120.65) 56(84) bytes of data.
-->> nix
 
Last edited by a moderator:
Wenn ich das Problem nur kennen würde... :confused:

In einem anderen Forum habe ich aber einen interessanten Hinweis gefunden
Möglicherweise filtert ServerLoft auf Layer 2 - sprich, der Switchport ist an eine bestimmte MAC gebunden. Bei vif_route wird die MAC-Adresse der DomU verwendet, so dass Traffic der DomU möglicherweise am Switch/Router des Providers blockiert wird.
Click to expand...
 
Lösung über NAT

Auf einem Serverloft-Server hat man ja zwei Probleme:
1. Die zusätzlichen IPs sind auf die HauptIP des Servers gerouted.
2. Am Switchport wird nur die Mac-Adresse des Servers erlaubt.

Das erste Problem verhindert schon das Bridgen der virtuellen Maschinen. Hier muss der Server also routen. Leider verhindert ein routen der IP-Adressen, was bei Hetzner funktioniert, leider nicht dass die Mac-Adresse sichtbar ist. Deshalb sind die virtuellen Maschinen dann trotzdem nicht erreichbar.
Ich habe das bei mir dadurch gelöst, dass ich dem Server die Ips gegeben habe, alle VMs in einem privaten Netz betreibe und den Server per NAT die Ports der relevanten Dienste durchreichen lasse. Das lässt sich pro Port mit zwei Zeilen iptables lösen lässt.
Dieses Verfahren ist zwar etwas komplizierter, hat aber den Vorteil, dass man mher virtuelle Maschinen betreiben kann, als man IP-Adressen hat, solange sich die angebotenen Dienste auf den virtuellen Maschinen nicht überschneiden.

ciao
Beam
 
Puh, das würde meine Befürchtung bestätigen. Also bei 2 Problemen ist mir 1 zuviel. Sollte es wirklich nicht möglich sein Xen im routed Modus zu betreiben, ist das serverloft Angebot nichts für mich. Ich kann es noch nicht ganz glauben, dass ich deshalb 3 Tage und 3 Nächte damit verbracht habe. Das hätte mir von denen auch einfach jemand sagen können................

Es wundert mich allerdings, weil "thefreak" es ja anscheinend zum Laufen gebracht hat. Und bevor er mir den letzten Hinweis geben konnte hier gekickt wurde...

Eine offizielle Stellungnahme zu diesem Thema wäre sehr wünschenswert.
 
Das ist aber eine brauchbare Lösung mit dem Portforwarding per NAT.

Hier ist mal der erste Teil meines Scriptes. Das ist allerdings für vmware deshalb heißt das private Netz vmnet2. Der Server hat unter eth0:0 die zusätzliche IP 85.25.122.x die virtuelle Maschine hat die IP 192.168.44.2
Die ersten paar Zeilen ermöglichen das rausfunken der VMs. DIe folgenden ermöglichen den Zugriff auf http, https und smtp der VM unter der IP 85.25.122.x


Code: 
#!/bin/bash
# IP Masquerading
iptables -A FORWARD -i eth0 -o vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vmnet2 -o eth0 -j ACCEPT
iptables -A FORWARD -j LOG
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo "1" > /proc/sys/net/ipv4/ip_forward
# Portforwarding
iptables -A FORWARD -i eth0 -o vmnet2 -p tcp --dport 80 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp -d 85.25.122.x --dport 80 -j DNAT --to 192.168.44.2:80
iptables -A FORWARD -i eth0 -o vmnet2 -p tcp --dport 443 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp -d 85.25.122.x --dport 443 -j DNAT --to 192.168.44.2:443
iptables -A FORWARD -i eth0 -o vmnet2 -p tcp --dport 25 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp -d 85.25.122.x --dport 25 -j DNAT --to 192.168.44.2:25
iptables -A FORWARD -i eth0 -o vmnet2 -p tcp --dport 110 -j ACCEPT
 
Danke für deine Hilfe. Ich werde es versuchen, aber ich habe kein gutes Gefühl dabei muss ich gestehen. Ich durchschaue die möglichen Konsequenzen oder Einschränkungen der NAT-Geschichte nicht ganz... Das scheint alles logisch und funktioniert jetzt ja auch vielleicht aber... Ich meine, es wäre ärgerlich, wenn ich später im Betrieb plötzlich feststellen muss, dass es Probleme - welcher Art auch immer - gibt. Sei es Performance-Probleme oder vielleicht doch auch Netzwerkorobleme, weil es doch eine eher ungewöhnliche Lösung ist.

Hast du den Server denn schon richtig in Betrieb oder bist du noch am testen?
 
Ja ich betreibe Produktiv einen Exchange-Server in einer VM. Diese Maschine lief vorher auf einem Hetzner-Server. Dort konnte ich mich schon langsam an schlechtere Bedingungen mit den IPs rantasten, da der Server dort ursprünglich gebridged lief. dann hat Hetzner das Subnet auf die Haupt-IP geroutet und ich musste den Host routen lassen. Das ist jetzt halt nur eine Stufe schärfer...
Aber das hat viel Forschungsarbeit gekostet und ich hatte sehr viel Angst, ob das Konzept auch trägt. Ich hatte ähnliche Ängste, ob denn nicht irgendwann eine Anforderung kommt, die man damit nicht abbilden kann.
Mir ist da bis jetzt nur eine eingefallen: IP-Telefonie. SIP und Konsorten mögen kein NATen. Das muss dann halt auf den Host rauf. Oder ein Server der nicht bei der Intergenia-Famile steht muss wieder her.
Der einzige wirkliche Nachteil am NATen ist, dass es mehr aufwand als routen macht und man sehr genau nachdenken muss welche Dienste die VM tatsächlich anbietet. Das kann man aber auch als Vorteil sehen. ;-)

ciao
Beam
 
You must log in or register to reply here.
Back
Top