Как включить или отключить Proxy ARP в Linux
Посмотрим статус Proxy ARP (1 — включен, 0 — отключен):
cat /proc/sys/net/ipv4/conf/all/proxy_arp
Можно посмотреть на конкретном сетевом интерфейсе (где eth0 — имя сетевого интерфейса):
cat /proc/sys/net/ipv4/conf/eth0/proxy_arp
Включить Proxy ARP можно так:
sudo -i echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
sudo sysctl net.ipv4.conf.all.proxy_arp=1 sudo sysctl net.ipv4.conf.eth0.proxy_arp=1 sudo sysctl -p
Для выключения Proxy ARP команды аналогичны, нужно лишь указать 0 вместо 1.
Сделанные выше изменения сбросятся после перезапуска системы, чтобы этого не произошло, откроем файл /etc/sysctl.conf в любом текстовом редакторе:
net.ipv4.conf.all.proxy_arp=1 net.ipv4.conf.eth0.proxy_arp=1
При необходимости можно посмотреть приходящие ARP пакеты через tcpdump:
sudo tcpdump -n -i eth0 -e arp
Также есть другие параметры настройки arp, приведу пример их просмотра:
sysctl -a | grep net.ipv4.conf.*.arp
Если на коммутаторах настроена изоляция портов и вам необходимо чтобы клиенты в одном VLAN видели друг друга (в этом случае весь трафик будет ходить через сервер), то необходимо включить proxy_arp_pvlan, по умолчанию это отключено, то есть равно 0. Замечу, что на сервере с accel-ppp с включенным proxy-arp например, не нужно включать proxy_arp и proxy_arp_pvlan, так как accel-ppp сам это делает.
net.ipv4.conf.all.proxy_arp_pvlan = 0 net.ipv4.conf.default.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.proxy_arp_pvlan = 0 net.ipv4.conf.eth0.proxy_arp_pvlan = 0
Proxy ARP
Proxy ARP — техника использования ARP-протокола, позволяющая объединить две не связанные на канальном уровне сети в одну. Хосты, находящиеся в этих сетях, могут использовать адреса из одной IP-подсети и обмениваться трафиком между собой без использования маршрутизатора (как им кажется).
Например, на рисунке изображены два хоста A и B, которые находятся на канальном уровне в разных сегментах. На хостах не настроен шлюз по умолчанию. И маски подсетей на маршрутизаторе и на хостах отличаются.
Если на маршрутизаторе включен Proxy ARP на обоих интерфейсах, то происходит следующее:
- Хост A хочет отправить какие-то данные хосту B. Так как, на хосте A IP-адрес 10.0.1.10 с маской /8, то он считает, что хост B с IP-адресом 10.0.2.10/8, также находится с ним в одной сети (хосты считают, что они в сети 10.0.0.0/8). Хосту A необходимо узнать MAC-адрес хоста B. Он отправляет ARP-запрос в сеть.
- Маршрутизатор получает ARP-запрос, но не перенаправляет его, так как получатель в другой сети. Если на маршрутизаторе включен Proxy ARP, то маршрутизатор отправляет хосту A ARP-ответ, в котором подставляет свой MAC-адрес. То есть, для хоста A, создается соответствие 10.0.2.10 — MAC f0/0.
- Теперь хост A может отправить данные.
- Маршрутизатор получается пакет, смотрит на IP-адрес получателя и перенаправляет пакет на него (при условии, что в ARP кеше маршрутизатора уже есть запись для хоста B).
- Хост B аналогичным образом считает, что хост A с ним в одной сети. Хосту B необходимо узнать MAC-адрес хоста A. Он отправляет ARP-запрос в сеть.
- Маршрутизатор получает ARP-запрос, но не перенаправляет его, так как получатель в другой сети. Если на маршрутизаторе включен Proxy ARP, то маршрутизатор отправляет хосту B ARP-ответ, в котором подставляет свой MAC-адрес. То есть, для хоста B, создается соответствие 10.0.1.10 — MAC f0/1.
[править] Настройка в Linux
(Добавить бы сюда что есть что)
(Вот здесь есть переводная статья с подробным описанием процесса и разбором параметров: http://www.linuxcenter.ru/lib/articles/networking/Proxy-ARP-Subnet.phtml)
Публикация IP-адреса на интерфейсе:
%# arp -v -Ds eastasia.1984.lan eth0 pub arp: device `eth0' has HW address ether `00:0D:87:zz:yy:xx'. arp: SIOCSARP() %# arp -a room101.1984.lan (192.168.6.101) at 00:0A:E6:pp:qq:rr [ether] on eth0 telescreen.1984.lan (192.168.6.18) at 00:04:76:jj:kk:ll [ether] on eth0 crimethink.1984.lan (192.168.6.9) at 00:0F:66:aa:bb:cc [ether] on eth0 eastasia.1984.lan (192.168.6.12) at * PERM PUP on eth0
Включение Proxy ARP на интерфейсах:
%# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp %# echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
[править] Proxy ARP в debian Linux
Установим Proxy ARP IP bridging daemon:
# apt-get update # apt-get install parprouted
Запустим демон, в параметрах указываем через пробел имена интерфейсов между которыми необходим proxy ARP (у меня это между bonding’ом и VLAN’ом):
# parprouted bond0 eth1.3021
[править] Настройка в коммутаторах ProCurve
Включение Proxy ARP в VLAN 1:
sw(config)# vlan 1 sw(vlan-1)# ip proxy-arp
[править] Настройка в коммутаторах Cisco
Включение Proxy ARP в gi0/1:
R1(config)#int gi0/1 R1(config-if)#ip proxy-arp
[править] Дополнительная информация
- Proxy ARP with Linux (англ.)
- Monter un proxy-ARP (Debian) (фр.)
| Канальный уровень | ||
|---|---|---|
| Основные понятия | Коммутация • MAC-адрес • Сетевой интерфейс • CAM-таблица • VLAN • Broadcast • Multicast • Unicast • ifconfig • QinQ | |
| Петли коммутации и борьба с ними | ||
| Ключевые понятия | Широковещательный шторм • Петля коммутации • Остовное дерево | |
| Протоколы | STP • RSTP • MSTP • PVST • PVST+ | |
| Настройка STP на | коммутаторах Cisco • коммутаторах ProCurve | |
| Агрегирование каналов | ||
| Ключевые понятия | Агрегирование каналов • EtherChannel | |
| Протоколы | LACP • PAgP | |
| Настройка в | Linux • FreeBSD • NetBSD • OpenBSD • Mac OS X • Solaris • Windows • маршрутизаторах Cisco • коммутаторах Cisco • коммутаторах ProCurve | |
| Протокол ARP | ||
| Ключевые понятия | Протокол ARP • ARP-таблица • Статический ARP • Proxy ARP | |
| Программы | arp • arping • arp-sk • arpmap | |
| Виртуальные и программные коммутаторы, мосты и сетевые интерфейсы | ||
| Компоненты | tap-интерфейс • dummy-интерфейс • Мост в Linux • Мост в FreeBSD • vde • OpenVPN Bridge | |
| Программы | brctl (man) • ebtables | |
| Безопасность | ||
| Программы и библиотеки | Wireshark • Scapy | |
| MAC | MAC-spoofing • Port security • Поиск по MACу • MAC-spoofing в виртуальной машине | |
| ARP | ARP-spoofing • ettercap • arpwatch (man) • remarp • Dynamic ARP Protection | |
Ubuntu, KVM и proxy_arp — как обмануть злого провайдера
Одна фирма расположила на колокейшне серверочек для внутренних нужд и сразу купила /30 адреса для соих потребностей. Сконфигурено это было как алиасы (eth0:0, eth0:1 и т.п.). Все работало великолепно, пока по прошествии некоторого времени появилась здравая идея разнести разные сервисы на разные виртуальные машины. Поскольку в качестве хоста использовался Ubuntu Server, то выбор KVM в качестве виртуализатора произошел сам собой. И здесь, и в остальном нете уже немало умных слов было написано по установку и настройку KVM и сетевого окружения, не буду на этом останавливаться, расскажу лишь про маленькие детские грабельки, удобно подложенные со стороны провайдера.
Прежде всего надо отметить, что все происходило на живой активно используемой технологической машине, где перерывы в предоставлении сервиса были нежелательны, потому все переконфигурации производились по ночам с соответствующим состоянием мозгов;)
Итак, оставив eth0 нетронутым (дабы не прерывались важные производственные сервисы), гасим все алиасы, создаем бридж br0, втыкаем в него eth0 и запускаем виртуальные машины, точно так же, как во всех KVM-букварях написано, втыкая tapX в тот же бридж.
Вуаля — айпишники видны, машины друг друга пингают, время открывать шампань, когда обнаруживается, что из инета доступен только хост. Опуская тонкости поисков проблемы, сразу перехожу к сути — у провайдера, где стоял на колокейшне сервер, свич сконфигурирован с port security, т.е. выпускал наружу только прибитый гвоздями при установке MAC. Пропускать маки виртуальных машин провайдер отказался, за что я его не виню, и это его право устанавливать внутреннюю техническую политику. В ответ на растеряный вопрос: «А как же нам быть?» был дан ответ опять-таки из KVM-букваря: оставляйте на интерфейсе алиасы, на виртуалках указать десятую сетку и дальше «iptables -j DNAT bla-bla-bla»
Погрустив слегка по поводу некоторой корявости подобного решения и вдумчиво покурив гугль, был найден альтернативный вариант с ключевым словом proxy_arp.
Перво-наперво делаем apt-get install uml-utilities
В /etc/network/interfaces прописываем:
auto eth0
iface eth0 inet static
address 1.2.3.1
netmask 255.255.255.0
network 1.2.3.0
broadcast 1.2.3.255
gateway 1.2.3.254
post-up sysctl -w net.ipv4.ip_forward=1
post-up sysctl -w net.ipv4.conf.eth0.proxy_arp=1
pre-down sysctl -w net.ipv4.ip_forward=0
auto qtap1
iface qtap1 inet manual
tunctl_user root
uml_proxy_arp 1.2.3.2
uml_proxy_ether eth0
up ip link set qtap1 up
down ip link set qtap1 down
auto qtap2
iface qtap2 inet manual
tunctl_user root
uml_proxy_arp 1.2.3.3
uml_proxy_ether eth0
up ip link set qtap2 up
down ip link set qtap2 down
Стартуем виртуальные машины:
kvm -m 512 -hda image.img -net nic,macaddr=00:01:02:03:04:05 -net tap,ifname=qtap1,macaddr=00:01:02:03:04:05,script=no -daemonize -vnc :1 и т.д.
Далее в виртуальных машинах в качестве gw прописываем адрес хоста 1.2.3.1 и получаем работающую гроздь виртуалок, заныкавшуюся от провайдера за МАКом хост-машины.
Для тех, кто пока не относит себя к network guru, пару слов о proxy_arp и отличии его от bridge.
По-умолчанию, обычный мост просто передает пакеты с одного интерфейса на другой в неизменном виде. Он рассматривает только аппаратный адрес пакета, чтобы определить — в каком направлении нужно передать пакет. Это означает, что Linux может переправлять любой вид трафика, даже тот, который ему не известен, если пакеты имеют аппаратный адрес.
Псевдо-мост работает несколько иначе и скорее больше походит на скрытый маршрутизатор, чем на мост, но подобно мосту имеет некоторое влияние на архитектуру сети. Правда это не совсем мост, поскольку пакеты в действительности проходят через ядро и могут быть отфильтрованы, изменены, перенаправлены или направлены по другому маршруту.
Еще одно преимущество псевдо-моста состоит в том, что он не может передавать пакеты протоколов, которые «не понимает» — что предохраняет сеть от заполнения всяким «мусором».
В данной схеме когда провайдерский свич желает установить связь с виртуальной машиной, находящейся позади хоста, то он отсылает хосту пакет ARP-запроса, который, в переводе на человеческий язык, может звучать примерно так: «У кого установлен адрес 1.2.3.2? Сообщите по адресу 1.2.3.254». В ответ на запрос, 1.2.3.1 ответит коротким пакетом «Я здесь! Мой аппаратный адрес xx:xx:xx:xx:xx:xx».
Когда 1.2.3.254 получит ответ, он запомнит аппаратный адрес 1.2.3.2 и будет хранить его в кэше некоторое время.
При настройке proxy_arp мы указали интерфейсу eth0 на необходимость отвечать на ARP-запросы. Это вынудит роутер посылать пакеты мосту, который затем обработает их и передаст на соответствующую виртуальную машину.
Таким образом, всякий раз, когда провайдерский роутер по одну сторону моста запрашивает аппаратный адрес компьютера, находящегося по другую сторону, то на запрос отвечает мост, как бы говоря «передавай все через меня», вследствие чего весь трафик попадет на eth0 и будет передан в нужную виртуалку.
При подготовке статьи были использованы материалы «Linux Advanced Routing & Traffic Control HOWTO».