Недавно у меня появилась необходимость в маршрутизации между офисной сетью и лабой.

Лаба представляет из себя XenServer с двумя реальными сетевыми адаптерами. Один интерфейс смотрит в локальную сеть, а второй интерфейс соединен с внутренними лабораторными ресурсами, там есть своя Microsoft инфраструктура  XenMobile Solution Bundle и т.д. Для исключения конфликта с DHCP, для исключения сетевых проблем, наподобие броадкаст шторма и BPDU guard необходимо лабораторную сеть на уровне ip отделить от офисного сегмента.

Обычно для этого используют Vyatta роутер. Это достаточно функциональный маршрутизатор в виде виртуальной машины с дружественным для сетевого специалиста интерфейсом похожим на смесь Cisco и Juniper. Те, кто с технологиями Microsoft дружит больше, чем с сетевыми вещами, поднимают роутинг на Wndows Server. Мне оба этих варианта не подходили. Сделать отдельную виртуальную машину для роутинга я не мог, потому что был очень ограничен в Hardware ресурсах. Говоря по правде, XenServer располагался на обычной рабочей станции. Поднимать маршрутизацию на Windows Server’е тоже было проблемой, потому что по вышеописанным причинам выделить виртуалку для этого нельзя, а все существующие виртуальные машины используются по максимуму в экспериментах и иногда не выдерживают, глючат и так далее.

Поэтому было принято волевое решение поднять роутинг на самом Linux-ядре DOM-0 XenServer’а. Это тоже не очень правильно, загружать DOM-0 подобной не специфической нагрузкой, но с другой стороны это не противоречит концепции Software Defined Network, работает же Virtual Swith и ни чего…

Разрешить роутинг в ядре не проблема – ищется в google менее чем за одну минуту:

To enable these options edit the file /etc/sysctl.conf and add or uncomment the following lines:

net.ipv4.ip_forward = 1

Как только опция была включена, ping’и сразу заработали. Но подключиться по RDP к Widows Server’ам стенда не получалось. Первое, на что пало подозрение – это не отключенный Windows Firewall. Отключил – картина не поменялась. Второе на что пало подозрение – это просто на Windows. Я решил на уровне сетевой карты посмотреть, доходит ли вообще TCP SYN на порт 3389. Можно было это сделать на контроллере Distributed Virtual Swith, но мне показалось проще поставить на Windows сниффер Microsoft Network Monitor. В итоге пинги приходящие на Windows я увидел, TCP на порты 22, 80 и 443 тоже увидел. После этого стало понятно, что где-то по пути на сетевом уровне стоит firewall. Варианта оставалось два

1. Distributed Virtual Switch – его я посмотрел – запрещающих правил нет. Для уверенности на каждом уровне добавил в явном виде “permit any any“.

2. XenServer iptable на ядре linux. Тут действительно была проблема:

/etc/sysconfig/iptables:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT – [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp –icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp –dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp –dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp –dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp –dport 67 –in-interface xenapi -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m udp -p udp –dport 694 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited
COMMIT
У меня не стояло задач тонкой настройки firewall’а, поэтому самым простым решением мне показалось разрешить все. Для уверенности, что я не забуду отредактировать все необходимые файлы, перезапустить все демоны и т.д., я решил воспользоваться встроенной утилитой c графическим интерфейсов в стиле accept->next->next->next->finish.
system-config-securitylevel-tui 
После этого связность локальной сети и сети лабы была по всем портам и по всем протоколам.
В дополнение я поставил на автозапуск ключевые виртуальные машины, в т.ч. DOM-0. Но это так, на всякий случай и для удобства. Подробнее написано здесь.
Используемые источники: