link/ether 00:04:79:66:1b:70 brd ff:ff:ff:ff:ff:ff

    inet 192.168.0.9/24 brd 192.168.0.255 scope global eth0

    inet6 fe80::200:ff:fe00:0/64 scope link

       valid_lft forever preferred_lft forever

server:~ # ip addr del 192.168.0.9/24 dev eth0

server:~ # ip route sh

10.0.0.0/24 dev eth2  proto kernel  scope link  src 10.0.0.1

192.168.254.0/24 dev eth1  proto kernel  scope link  src 192.168.254.1

127.0.0.0/8 dev lo  scope link

Все! Теперь тот самый случай – никакая сеть, кроме виртуальной, хостовому серверу не доступна:

server:~ # ping -c 1 192.168.0.2

connect: Network is unreachable

А вот с других хостов сети «пинги» проходят вполне успешно. Адрес внутреннего виртуального UML-сервера присутствует в локальной сети и нормально работает. Если к данному мосту подключить следующую виртуальную систему с помощью соответствующего tun/tap устройства, на пользовательской стороне которого поднят иной адрес, то и он станет виден со стороны сети, подключенной к физическому интерфейсу сетевого моста. И так далее.

Получился безадресный сетевой мост, который работает как arp-прокси и транслирует трафик с виртуальных хостов. В чем его ценность? Такая схема позволяет защитить хостовую ОС от враждебного трафика сети, если вместо приватной сети используется, например Интернет. Еще один распространенный случай использования, когда безадресный хостер служит платформой для запуска виртуальных гостевых ОС, каждой со своим собственным адресом. Ну и, наконец, ничего не мешает применять на таком несущем сетевом мосте собственную сетевую разметку, не маршрутизируемую общим порядком, создавая скрытую служебную сеть. Есть, правда, и тут некоторые «подводные камни». Дело в том, что процедура взаимодействия сетевых узлов на уровне L2 является слабо защищенной. И в некоторых сетях используются самодельные службы и другие нестандартные настройки, контролирующие канальное взаимодействие. И хотя описанный выше прием с безадресным мостом прекрасно работает (не говоря уже, что такой классический способ настройки моста описан в документации), но бывали случаи, когда такая настройка действовала как DoS-атака. Точно так же стоит очень внимательно отнестись к множеству физических интерфейсов, объединенных в мост, – их неверное подключение может создать неконтролируемые пути доступа или утечки трафика и тоже стать источником проблем L2.

Предварительные итоги

Итак, подмена сетевых устройств виртуальными сетевыми мостами создает массу возможностей для манипуляции. В случае использования виртуальных серверов вообще такая настройка является единственно возможной. Но нельзя же каждый раз выполнять приведенные в статье команды, даже если их записать в отдельный скрипт. О том, как встроить предлагаемую схему разметки сетевых устройств в структуру реальных стартовых скриптов без каких-нибудь конфликтов для работы остальных подсистем, поговорим во второй части статьи.

Ссылки:

1. Сайт проект Open SUSE – http://en.opensuse.org/Welcome_to_openSUSE.org и область загрузки дистрибутива openSUSE 10.0 – http://ftp.opensuse.org/pub/opensuse/distribution/SL-10.0-OSS.