Чуть-чуть о Proxy ARP

Итак, например, была такая дебильная топология:Proxy_ARP_1В ней в качестве граничного устройства для ЛВС работала ASA, которая напрямую смотрела в сеть провайдера и имела адрес внешнего интерфейса 198.51.100.2/30. Ну и была какая-то ЛВС, в которой был какой-то вебсервер с IP 10.200.0.100/24. Еще ASA транслировала весь трафик пользователей, вылетающий наружу в IP 198.51.100.2, т.к. это был единственный публичный IP, предоставленный провайдером.

И вдруг провайдер расщедрился и подарил нам целый блок публичных адресов, скажем 203.0.113.0/24, причем подарил так, что весь этот блок для провайдера висит на том же интерфейсе, на котором висит и маааленькая подсеть 198.51.100.0/30 — та же, куда воткнута и ASA.

Proxy_ARP_Cisco_ASA

И после этого нам захотелось предоставить доступ пользователям из интернета к нашему вебсерверу, да причем предоставить так, чтобы он был доступен для них по IP 203.0.113.100. Ну и мы не пытаясь найти более логичных решений просто прописываем на ASA такое правило NAT/PAT (ну и немного сопутствующей конфигурации):

Теперь, Source IP всех пакетов, которые идут от сервера и вылетают наружу через внешний интерфейс ASA заменяются с 10.200.0.100 на 203.0.113.100 и наоборот, пакеты прилетающие на внешний интерфейс ASA из Интернета с Destination IP 203.0.113.100, получают новый Destination IP 10.200.0.100. Ну и дальше по теме.

Proxy ARP

Посмотрим детальнее. Итак, некто в интернете открыл ввел в адресной строке адрес http://203.0.113.100. Пакет долетел до нашего ISP, который владеет этим адресом и попал на интерфейс, который смотрит в сторону ASA. Самому интерфейсу маршрутизатора провайдера в этой подсети присвоен адрес 203.0.113.1 с маской 24. Соответственно, ISP роутер знает, что для него эта подсеть является directly connected и маршрутизация для него закончилась. Ему нужно просто отправить пакет адресату, т.е. 203.0.113.100. Что он делает? Он просто отправляет в эту подсеть (т.е. через свой интерфейс, смотрящий на нашу ASA) ARP-запрос, спрашивая, кому принадлежит 203.0.113.100. Ну и тут за дело берется тот самый прокси-ARP. Внешнему интерфейсу ASA присвоен IP 198.51.100.2, но никак ни 203.0.113.100. Но, за счет того, что на ASA настроено приведенное выше правило трансляции адресов и proxy-ARP включен (что есть по умолчанию), она, видя этот ARP запрос от роутера ISP отвечает: «IP 203.0.113.100 — мой и вот мой mac-адрес: ed22:0031:3212. Давай шли сюда что там у тебя есть». После этого маршрутизатор ISP плагополучно отправляет пакет в свой линк, смотрящий на ASA, та выполняет обратную трансляцию адреса и пакет долетает до вебсервера. Все отлично.

Здесь пример может быть не самый практический, но суть передавать должен. Кстати, даже если внешнему интерфейсу присвоить IP из нового блока адресов, например 203.0.113.2, а все адреса внутренних клиентов транслировать в другой IP из этой же подсети, скажем 203.0.113.10, то при общении с роутером ISP также будет задействоваться proxy-arp, т.к. опять же, IP 203.0.113.10 интерфейсу не принадлежит, а на arp запросы по этому адресу ASA отвечает.

Как было сказно выше на ASA 8.3+ прокси ARP включен по умолчанию:

Соответственно, когда бывает необходимость его выключить (пока не сталкивался с такой необходимостью), достаточно ввести sysopt noproxyarp с указанием интерфейса. Но, перед этим, нужно обязательно смотреть на правила NAT, висящие на этих интерфейсах, дабы их не убить.

Чуть позже допишу, если не забуду.


Не забывайте оставлять комментарии, если пост был вам полезен!
Опубликовано в Сети Метки: , ,
Заодно посмотрите мои фоты в моем профиле вконтакте. Любые вопросы по существу статей можете задать там же.
Hostenko — лучший WordPress-хостинг