Я создал виртуальную машину внутри хоста xen. Следуя этому руководство, Мне удалось пинговать www.google.com, но он только дважды выполнил пинг-понг, прежде чем получить Destination Host Unreachable. Если я перезапущу виртуальную машину, я снова могу дважды выполнить эхо-запрос, прежде чем сбой.
$ - ping www.google.com
PING www.google.com (216.58.208.228) 56(84) bytes of data.
64 bytes from par10s22-in-f4.1e100.net (216.58.208.228): icmp_seq=1 ttl=51 time=17.3 ms
64 bytes from par10s22-in-f4.1e100.net (216.58.208.228): icmp_seq=2 ttl=51 time=17.4 ms
From static.12.166.76.144.clients.your-server.de (144.76.166.12): icmp_seq=3 Redirect Host(New nexthop: 144.76.166.1)
64 bytes from 216.58.208.228: icmp_seq=3 ttl=51 time=17.3 ms
From wservervm (144.76.166.25) icmp_seq=4 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=5 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=6 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=7 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=8 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=9 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=10 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=11 Destination Host Unreachable
From wservervm (144.76.166.25) icmp_seq=12 Destination Host Unreachable
IP-адрес хоста (внешний, который используется для доступа к серверу извне) используется в качестве шлюза по умолчанию для виртуальной машины. Я не знаю, какую еще информацию дать. Что могло быть причиной этого?
Выход arp -n для гость является:
Address HWtype HWaddress Flags Mask Iface
144.76.166.12 ether d4:3d:7e:ec:ef:f8 C eth0
144.76.166.1 (incomplete) eth0
и для хозяин:
Address HWtype HWaddress Flags Mask Iface
144.76.166.27 (incomplete) xenbr0
144.76.166.1 ether cc:e1:7f:ac:52:96 C xenbr0
144.76.166.25 ether 00:16:3e:b0:23:21 C xenbr0
144.76.166.28 (incomplete) xenbr0
144.76.166.29 (incomplete) xenbr0
/ и т.д. / сеть / интерфейсы хозяина
# loopback
auto lo
iface lo inet loopback
# physical network interface
auto eth0
iface eth0 inet manual
# bridge public
auto xenbr0
iface xenbr0 inet static
address 144.76.166.12
netmask 255.255.255.224
gateway 144.76.166.1
bridge_ports eth0
bridge_stp off # disable Spanning Tree Protocol
bridge_waitport 0 # no delay unless port available
bridge_fd 0 # no forwarding delay
# up route add -net 188.40.103.64 netmask 255.255.255.192 gw 188.40.103.65 eth0
# bridge internal
auto xenbr1
iface xenbr1 inet static
address 10.0.10.1
broadcast 10.0.10.255
netmask 255.255.255.0
pre-up brctl addbr xenbr1
# ipv6
iface eth0 inet6 static
address 2a01:4f8:200:420b::2
netmask 64
gateway fe80::1
brctl показать:
bridge name bridge id STP enabled interfaces
xenbr0 8000.d43d7eeceff8 no eth0
vif6.0
xenbr1 8000.000000000000 no
Я думаю, что главное, на что нужно обратить внимание, это то, что он дважды успешно выполнил настольный теннис, прежде чем потерпел неудачу.
Вы либо выполняете маршрутизацию, либо используете мост при предоставлении доступа к домену. Похоже, вы пытаетесь сделать и то, и другое одновременно, и есть вероятность, что это вызывает перенаправление и косвенно нарушает подключение из-за правил вашего брандмауэра.
Рассмотрим следующие случаи:
Вы делаете мосты. Пакеты проходят через цепочку iptables FORWARD и доставляются напрямую от вашего хоста к гостю, без фактической маршрутизации. Важно знать, что цепочка FORWARD по умолчанию применяется даже для моста. Обычно провайдеры просят вас привязать конкретный виртуальный MAC-адрес, чтобы это работало по соображениям безопасности (спуфинг и др.).
Вы делаете маршрутизацию. Пакеты проходят через цепочку iptables FORWARD, а затем маршрутизируются с использованием таблицы маршрутизации ядра в правильное место назначения. Обычно это означает, что вы используете адреса из другой подсети или одноадресные / 32 с маршрутизацией, обрабатываемой конкретно поставщиком.
Здесь вы делаете и то, и другое:
Я не уверен, почему это не работает, учитывая, что перенаправление ICMP отключено почти во всех основных дистрибутивах Linux из коробки и должно работать, несмотря на проблемы, которые может вызвать асимметричная маршрутизация. Вероятно, это проблема из-за того, что шлюз провайдера слишком придирчив к изменениям ARP и MAC ...
В любом случае, поскольку ваши IP-адреса Dom0 и DomU находятся в одной и той же сетевой маске, в вашем случае вам необходимо выполнить полное мостовое соединение. Просто исправьте адрес шлюза DomU, чтобы он указывал на .1, шлюз провайдера. Не забудьте настроить правила брандмауэра по мере необходимости, так как даже пакеты, переданные по мосту, по умолчанию проходят через цепочку FORWARD.
Источник: я запускаю Xen на тестовом блоке, который обеспечивает доступ к разным доменам через NAT, мосты и маршрутизацию в зависимости от домена.
Похоже, ваш брандмауэр блокирует соединение.
Попробуйте выключить брандмауэр (временно), затем попробуйте снова выполнить эхо-запрос и посмотрите, повторяется ли он более двух раз.