[РЕШЕНО] Интернет-шлюз + виртуальный сервер

[Glaf]

Бьюсь над проблемой уже третий день. До этого поднимал с полдюжины шлюзов по разным мануалам, а вот этот ну никак не хочет работать. Может, слишком сложная схема или просто сказывается усталость, чего не замечаю? Ткните носом, пожалуйста, уж сроки сильно поджимают.

Исходные данные:
Сети:
10.58.0.0/24 - провайдер интернет
10.18.125.0/24 - локальная сеть организации
10.18.2.0/24 - локальная сеть удалённого офиса

PC1 - сервер организации на ubuntu 10.04, на нём же крутится в KVM виртуальный Windows Server 2003 (далее VPC2)
задействовано 3 физических сетевых интерфейса:
eth0: без адреса, т.к. на нём поднят br0 для VPC2
eth1: 10.58.0.63 смотрит в шлюз провайдера интернет (10.58.0.254)
eth2: 10.18.125.13 смотрит в локальную сеть
виртуальные интерфейсы:
br0: 10.18.125.63 мост на eth0 для VPC2, смотрит в локальную сеть
vnet0:  без адреса, создан KVM автоматически
Подняты службы:
dnsmask (шлюз DNS + DHCP) - для раздачи адресов компьютерам локальной сети и обслуживания их запросов к DNS.

VPC2 - виртуальный сервер Windows Server 2003 в KVM на PC1
сетевой интерфейс: 10.18.125.11 шлюз 10.18.125.13

PC3 - сервер DNS офиса
внутренний ip: 10.18.125.30
Подняты службы:
DNS

GW4 - шлюз VPN связи с удалённым офисом
ip: 10.18.125.1

Нужно, чтобы запросы VPC2 на адреса сети удалённого офиса уходили через шлюз PC3, а на адреса интернет - через шлюз провайдера 10.58.0.254.
Вроде, не сложная задачка.
DNS работает корректно, здесь не описываю.
Проблемы со шлюзом PC1.

На PC1:
interfaces

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# cat /etc/network/interfaces

auto lo
iface lo inet loopback

manual eth0

# intertnet
auto eth1
iface eth1 inet static
address 10.58.0.63
netmask 255.255.255.0
gateway 10.58.0.254
broadcast 10.58.0.255
pre-up iptables-restore < /etc/iptables.up.rules

# local
auto eth2
iface eth2 inet static
address 10.18.125.13
netmask 255.255.255.0
hwaddress ether 1c:c1:de:e6:93:e7
up route add -net 10.18.125.0 netmask 255.255.255.0 gw 10.18.125.13 eth2
up route add -net 10.18.2.0 netmask 255.255.255.0 gw 10.18.125.1 eth2

auto br0
iface br0 inet static
address 10.18.125.63
netmask 255.255.255.0
hwaddress ether 1c:c1:de:e6:93:e5
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
up route add -net 10.18.125.0 netmask 255.255.255.0 gw 10.18.125.13 br0
up route add -net 10.18.2.0 netmask 255.255.255.0 gw 10.18.125.1 br0


маршрут в локальной сети, всё в порядке

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# tracepath 10.18.125.10
 1:  server.local (10.18.125.13)                          0.099ms pmtu 1500
 1:  10.18.125.10 (10.18.125.10)                           13.533ms reached


маршрут в сеть удалённого офиса, идёт через GW4, как надо

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# tracepath 10.18.2.1
 1:  server.local (10.18.125.13)                          0.093ms pmtu 1500
 1:  10.18.125.1 (10.18.125.1)                              2.919ms
...
 6:  10.18.2.1 (10.18.2.1)                        159.215ms asymm 10


маршрут в интернет, идёт через 10.58.0.254, как надо

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# tracepath 8.8.8.8
 1:  server.local (10.58.0.63)                            0.093ms pmtu 1500
 1:  10.58.0.254 (10.58.0.254)                              2.555ms
...
 7:  8.8.8.8 (8.8.8.8)                           35.152ms asymm  8


На виртуальном сервере VPC2:
настройка сети

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

>ipconfig /all

Настройка протокола IP для Windows

   Имя компьютера  . . . . . . . . . : server-v
   Основной DNS-суффикс  . . . . . . :
   Тип узла. . . . . . . . . . . . . : неизвестный
   IP-маршрутизация включена . . . . : нет
   WINS-прокси включен . . . . . . . : нет

Подключение по локальной сети - Ethernet адаптер:

   DNS-суффикс этого подключения . . :
   Описание  . . . . . . . . . . . . : Realtek RTL8139 Family PCI Fast Ethernet
NIC
   DHCP включен. . . . . . . . . . . : да
   Автонастройка включена  . . . . . : да
   IP-адрес  . . . . . . . . . . . . : 10.18.125.11
   Маска подсети . . . . . . . . . . : 255.255.255.0
   Основной шлюз . . . . . . . . . . : 10.18.125.13
   DHCP-сервер . . . . . . . . . . . : 10.18.125.13
   DNS-серверы . . . . . . . . . . . : 10.18.125.13


маршрут в локальной сети, всё в порядке

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

>tracert 10.18.125.10

Трассировка маршрута к BSERVER [10.18.125.10]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  BSERVER [10.18.125.10]

Трассировка завершена.


маршрут в сеть удалённого офиса, идёт через GW4, как надо

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

>tracert 10.18.2.1

Трассировка маршрута к 10.18.2.1 с максимальным числом прыжков 30

  1    <1 мс    <1 мс    <1 мс  10.18.125.1
...
  3    72 ms    74 ms    74 ms  10.18.2.1


маршрут в интернет, затыкается на шлюзе PC1

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

>tracert 8.8.8.8

Трассировка маршрута к google-public-dns-a.google.com [8.8.8.8]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  SERVER[10.18.125.13]
  2     *        *        *     Превышен интервал ожидания для запроса.
...


Проверяем настройки шлюза PC1.
iptables

(Нажмите, чтобы показать/скрыть)

# iptables -t nat -L -vn
Chain PREROUTING (policy ACCEPT 729 packets, 65586 bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain POSTROUTING (policy ACCEPT 746 packets, 417K bytes)
 pkts bytes target     prot opt in     out     source               destination        
  537  202K SNAT       all  --  *      eth1    0.0.0.0/0            0.0.0.0/0           to:10.58.0.63

Chain OUTPUT (policy ACCEPT 816 packets, 590K bytes)
 pkts bytes target     prot opt in     out     source               destination    

# iptables-save
# Generated by iptables-save v1.4.4 on Sun Dec 19 12:24:36 2010
*filter
:INPUT ACCEPT [57459:8871550]
:FORWARD ACCEPT [12714:5100918]
:OUTPUT ACCEPT [51707:18448736]
COMMIT
# Completed on Sun Dec 19 12:24:36 2010
# Generated by iptables-save v1.4.4 on Sun Dec 19 12:24:36 2010
*nat
:PREROUTING ACCEPT [733:66164]
:POSTROUTING ACCEPT [757:417463]
:OUTPUT ACCEPT [825:590520]
-A POSTROUTING -o eth1 -j SNAT --to-source 10.58.0.63
COMMIT
# Completed on Sun Dec 19 12:24:36 2010

ip_forward

(Нажмите, чтобы показать/скрыть)

# cat /proc/sys/net/ipv4/ip_forward
1

# sudo sysctl -a |grep forward | grep ipv4
error: "Invalid argument" reading key "fs.binfmt_misc.register"
error: permission denied on key 'net.ipv4.route.flush'
error: permission denied on key 'net.ipv6.route.flush'
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth1.forwarding = 1
net.ipv4.conf.eth1.mc_forwarding = 0
net.ipv4.conf.eth2.forwarding = 1
net.ipv4.conf.eth2.mc_forwarding = 0
net.ipv4.conf.eth3.forwarding = 1
net.ipv4.conf.eth3.mc_forwarding = 0
net.ipv4.conf.br0.forwarding = 1
net.ipv4.conf.br0.mc_forwarding = 0
net.ipv4.conf.vnet0.forwarding = 1
net.ipv4.conf.vnet0.mc_forwarding = 0
net.ipv4.ip_forward = 1

Проверил, форвардинг срабатывает.

(Нажмите, чтобы показать/скрыть)

На PC1 включил логи

# iptables -A FORWARD -j LOG --log-level info --log-prefix "iptables-forward"

На VPC2 стучусь на 8.8.8.8, результат отрицательный

Код: [Выделить]

>tracert 8.8.8.8

Трассировка маршрута к google-public-dns-a.google.com [8.8.8.8]
с максимальным числом прыжков 30:

  1    <1 мс    <1 мс    <1 мс  SERVER[10.18.125.13]
  2     *        *        *     Превышен интервал ожидания для запроса.
...
В логах PC1 форвардинг работает:

# cat /var/log/syslog | grep iptables-forward
...
Dec 19 12:36:11 server-p kernel: [55512.918124] iptables-forwardIN=br0 OUT=br0 PHYSIN=vnet0 PHYSOUT=eth0 SRC=10.18.125.11 DST=8.8.8.8 LEN=92 TOS=0x00 PREC=0x00 TTL=2 ID=4479 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=7424
Dec 19 12:36:11 server-p kernel: [55512.918185] iptables-forwardIN=eth2 OUT=eth1 SRC=10.18.125.11 DST=8.8.8.8 LEN=92 TOS=0x00 PREC=0x00 TTL=1 ID=4479 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=7424

Что ещё посмотреть? Где может быть ошибка?

[Mam(O)n]

Ересь:

   up route add -net 10.18.125.0 netmask 255.255.255.0 gw 10.18.125.13 eth2
   up route add -net 10.18.125.0 netmask 255.255.255.0 gw 10.18.125.13 br0
   up route add -net 10.18.2.0 netmask 255.255.255.0 gw 10.18.125.1 br0

Единственное, что нужно:

   up route add -net 10.18.2.0 netmask 255.255.255.0 gw 10.18.125.1 eth2

Покажи вывод

Код: [Выделить]

ip r с PC1

[Glaf]

Код: [Выделить]

# ip r
10.18.2.0/24 via 10.18.125.1 dev eth2
10.58.0.0/24 dev eth1  proto kernel  scope link  src 10.58.0.63
10.18.125.0/24 via 10.18.125.13 dev eth2  scope link
10.18.125.0/24 dev eth2  proto kernel  scope link  src 10.18.125.13
10.18.125.0/24 dev br0  proto kernel  scope link  src 10.18.125.63
10.112.0.0/16 via 10.18.125.1 dev eth2
169.254.0.0/16 dev eth2  scope link  metric 1000
default via 10.58.0.254 dev eth1  metric 100
10.18.125.0/24 - добавил ещё одну удалённую подсеть

ересь на br0 полностью прибил, перегружаю сервер для чистоты эксперимента.
Перегрузил. результат не изменился.

[Mam(O)n]

И я чего-то не понял участия eth0 в данной схеме. Если eth2 это локалка, а eth1 это интернет, то что такое eth0? Почему в брижд заводится не eth2?

[Glaf]

На сервере 4 сетевые карты, вот и решил выделить одну из них (eth0) чисто для виртуального сервера. Хост-машина пусть общается через eth2. Не жалко
Думаешь, с этим проблемы? Как можно проверить?

[Mam(O)n]

Ну убери из конфигурации eth0 вообще и заведи в бридж вместо неё eth2. И маршруты поправь.

[Glaf]

Ожило!
Волшебная команда:

Код: [Выделить]

sysctl "net.bridge.bridge-nf-call-iptables=0"
Вот здесь ещё материал по этой проблеме.