Добрый день.
Сегодня расскажу об интересной, на мой взгляд, задаче и вариантах ее решения.
Заказчику необходимо было внести изменения в сетевую инфраструктуру таким образом, чтобы сохранилась текущая IP адресация хостов. Такое требование.
Ниже предоставлена примерная схема реализации проекта. Адреса и топология вымышленная, но отражает суть задачи.
Ping от 10.1230.14.1/24 à 192.168.10.133/29 проходит успешно.
Ping от 192.168.10.2/24 à 192.168.10.133/29 не проходит.
Давайте разбираться почему так.
Когда хост А -192.168.10.2/24 пингует хост Б 192.168.10.133/29, хост А думает, что адрес 192.168.10.133 находится в его подсети и шлет пакет напрямую хосту Б. Но хосту А необходимо узнать MAC адрес хоста Б. Для этого хост А шлет широковещательный ARP запрос, мол кто с адресом 192.168.10.133 скиньте мне свой МАС.
Далее этот ARP запрос попадает на фаерволл и все. Дальше ничего не происходит, фаервол не маршрутизирует пакет далее, хотя и имеет в таблице маршрутизации запись об искомой подсети. А все потому, что ARP запрос производится на канальном уровне.
! Канальный уровень, также уровень передачи данных — второй уровень сетевой модели OSI, предназначенный для передачи данных узлам, находящимся в том же сегменте локальной сети.
Таким образом хост А не может изучить МАС адресс хоста Б и инкапсулировать пакет ICMP для достижения цели. Нормальная ситуация.
Давайте дальше. Почему с подсети 10.230.14.1/24 мы пингуем хост Б с адресом 192.168.10.133?
Ту все просто. Хост Ц и хост Б в находятся в разных подсетях и хост Ц использует МАС адрес своего шлюза по умолчанию, а дальше пакет попадает на фаервол и уже маршрутизируется согласно своей таблице маршрутизации.
Так вот, какие варианты есть, чтобы решить проблему с доступностью хоста Б для хоста А?
Если хоста А не может получить МАС от хоста Б, то давайте ему сами скажем этот МАС. Т.е. пропишем mac-address static. Указав вручную МАС, мы избавляем хост А от необходимости слать ARP запрос на этот адрес. Соответственно, пакет инкапсулируется и отправляется на фаерволл, где, опять же, на третьем уровне распаковывается и маршрутизируется согласно таблице маршрутизации. Вариант не очень, т.к. для одного-двух хостов терпимо прописать статически(в виде исключения), но вот если будет хостов больше 5, то уже не гибко получается.
*static
Необходим вариант с автоматизацией.
И такой вариант есть. Называется - протокол ARP Proxy!
ARP Proxy протокол позволяет, в данном примере, нашему фаерволлу отвечать на ARP-запросы, предназначенные хосту Б, своим МАС адресом. Так, «подставив» свой МАС адрес, фаерволл берет на себя ответственноть о доставке пакета куда нужно. Протокол прокси-ARP описан в разделе RFC 1027.
Что присходит:
-Хост А шлет ARP запрос на адрес 192.168.10.133. На порту фаерволла настроен ARP-proxy, и получив этот запрос из подсети 192.168.10.0/24, фаерволл отвечает, по сути, выслав МАС адрес шлюза.
-На хосте А создается соответствие ip 192.168.10.133 à MAC-FW int0/1. Теперь хост А может пересылать пакеты.
*use ARP-proxy protocol
-Фаерволл может маршрутизировать данный пакет от хоста А хосту Б.
-Хост Б должен ответить на этот пинг. Хост Б получает пакет не из своей подсети, поэтому шлет пакет через шлюз, используя соответсвующий МАС адрес.
Таким образом получилось решить проблему со связностью двух не связанных на канальном уровне сетей в одну.
Спасибо за внимание.
