Есть следующая конфигурация на шлюзе:
Linux CentOS 7
WAN: enp1s0: 198.51.100.17/25 GW:198.51.100.19
LAN: enp2s0: 192.0.2.1/24
Кроме того, провайдером выделено ещё дополнительный адрес 198.51.100.201, Машина (назовём её WILS) с этим адресом размещена в локальной сети.
Для того, чтобы WILS работал нормально, на сервере нужно исполнить следующую команду:
ip neigh add proxy 198.51.100.201 dev enp1s0
Я эту команду добавил в /etc/rc.d/init.d/network и последствия не заставили себя долго ждать, так как очередное обновление системы перезаписало этот файл и уничтожило эту команду.
Подскажите, а где правильно прописать эту команду?
Можно, конечно, создать сервис, который поднимает эту команду, но, возможно, есть более правильное решение?
> Подскажите, а где правильно прописать эту команду?
> Можно, конечно, создать сервис, который поднимает эту команду, но, возможно, есть более
> правильное решение?/sbin/ifup-local
если NM_CONTROLLED=yes
/etc/NetworkManager/dispatcher.d/ifup-local
Это не уточнение к вашему вопросу, меня просто весьма заинтересовала ваша конфигурация.> Есть следующая конфигурация на шлюзе:
> Linux CentOS 7
> WAN: enp1s0: 198.51.100.17/25 GW:198.51.100.19
> LAN: enp2s0: 192.0.2.1/24
> Кроме того, провайдером выделено ещё дополнительный адрес 198.51.100.201, Машина (назовём
> её WILS) с этим адресом размещена в локальной сети.Скажите, у вас на шлюзе включён DNAT, и серверу WILS присвоен адрес в сети 192.0.2.1/24?
Или каким образом пакет с конечным адресом 198.51.100.201, полученный шлюзом (с помощью arp proxy который вы настраиваете), оказывается в LAN (куда подключён WILS)?
> Скажите, у вас на шлюзе включён DNAT, и серверу WILS присвоен адрес
> в сети 192.0.2.1/24?
> Или каким образом пакет с конечным адресом 198.51.100.201, полученный шлюзом (с помощью
> arp proxy который вы настраиваете), оказывается в LAN (куда подключён WILS)?arp proxy всего лишь пробрасывает мак-адрес WILSa ( "наружу" (конечно, провайдер должен был прописать, что пакеты предназначенные для адреса 198.51.100.201 отправлять на мой WAN, однако, он этого не сделал и договориться об этом невозможно. Разместить машину "во вне" так же нет возможности, так как WILS - виртуалка, работающая на сервере внутри LAN). Таким образом, все пакеты из-вне предназначенные для WILS попадают на WAN сервера. А далее, пакеты предназначенные для WILS и от WILSa во-вне, просто пересылаются на нужный интерфейс без [DS]NAT
> arp proxy всего лишь пробрасывает мак-адрес WILSa ( "наружу" (конечно, провайдер должен
> был прописать, что пакеты предназначенные для адреса 198.51.100.201 отправлять на мой
> WAN, однако, он этого не сделал и договориться об этом невозможно.Я примерно так и понял.
> Разместить машину "во вне" так же нет возможности, так как WILS
> - виртуалка, работающая на сервере внутри LAN). Таким образом, все пакеты
> из-вне предназначенные для WILS попадают на WAN сервера.Ах, так WILS это виртуалка на шлюзе... На каком гипервизоре?
> А далее, пакеты предназначенные для WILS ..., просто пересылаются на нужный
> интерфейс без [DS]NATА вот с этого места непонятно. Серверу WILS присвоен адрес 198.51.100.201, но он подключён (бриджем?) к LAN где сеть 192.0.2.1/24? И каким образом шлюз узнаёт, что пакеты надо слать на WILS, у вас его MAC где-то задан статически? (В таблице ARP? В /etc/ethers?)
Просто, чтобы понять, почему нет возможности разместить "во вне". Есть какая-то причина чтобы не создать, скажем, bridge-WAN, включить в него enp1s0 с 198.51.100.17 и виртуальный интерфейс машины WILS с 198.51.100.201? Провайдер будет видеть в сети WAN с вашей стороны два хоста, каждый со своим MACом и IP, и подумает что у вас там подключен свич. Или eму нельзя показывать незнакомые адреса MAC?
> Ах, так WILS это виртуалка на шлюзе... На каком гипервизоре?Не на шлюзе а на сервере (Proxmox) внутри LAN
> А вот с этого места непонятно. Серверу WILS присвоен адрес 198.51.100.201, но
> он подключён (бриджем?) к LAN где сеть 192.0.2.1/24? И каким образом
> шлюз узнаёт, что пакеты надо слать на WILS, у вас его
> MAC где-то задан статически? (В таблице ARP? В /etc/ethers?)Бриджем. Соответственно, пакеты arp летят свободно и WILS без особого напряга сообщает в LAN (а значит и шлюзу) свою пару mac-ip
> Просто, чтобы понять, почему нет возможности разместить "во вне". Есть какая-то причина
> чтобы не создать, скажем, bridge-WAN, включить в него enp1s0 с 198.51.100.17
> и виртуальный интерфейс машины WILS с 198.51.100.201? Провайдер будет видеть в
> сети WAN с вашей стороны два хоста, каждый со своим MACом
> и IP, и подумает что у вас там подключен свич. Или
> eму нельзя показывать незнакомые адреса MAC?Ещё раз напоминаю то, что писал выше: шлюз и сервер VM - физически разные машины.
>> Ах, так WILS это виртуалка на шлюзе... На каком гипервизоре?
> Не на шлюзе а на сервере (Proxmox) внутри LANПонятно, значит, я прочёл больше чем вы написали.
>> А вот с этого места непонятно. Серверу WILS присвоен адрес 198.51.100.201, но
>> он подключён (бриджем?) к LAN где сеть 192.0.2.1/24? И каким образом
>> шлюз узнаёт, что пакеты надо слать на WILS, у вас его
>> MAC где-то задан статически? (В таблице ARP? В /etc/ethers?)
> Бриджем. Соответственно, пакеты arp летят свободно и WILS без особого напряга сообщает
> в LAN (а значит и шлюзу) свою пару mac-ipIMHO, какого-то элемента не хватает, чтобы у шлюза была причина запрашивать ARP до 198.51.100.201 на интерфейсе LAN, который совсем в другой сети. Ну ладно...
Ваш случай похож на вещи с которыми мне приходится время от времени сталкиваться, но мне как-то не приходило в голову решать это с помощью arp proxy. В зависимости от деталей и доступной инфраструкуры, обычно я выбираю из двух шаблонов:
1. Самое простое топологически, это так или иначе подключить машину WILS напрямую с сети WAN. Например, если и WILS и шлюз это виртуалки на одном и том-же хосте, или WILS виртуалка, а роль шлюза исполняет сам физический хост, как я описал про bridge-WAN (не ваш случай, я уже понял).
Кроме того, если принимать физический линк WAN не прямо на шлюзе, а на свиче в определённой VLAN, то можно делать доступной сеть WAN на уровне ethernet для любого количества хостов.2. Если инфраструктуры по минимуму а на уровне ethernet от WILS до WAN не дотянуться, то я использую NAT, даже если это не стык публичной и приватной сетей. У шлюза есть свой собственный адрес в WAN, и алиас с внешним адресом WILS. У WILS есть внутренний адрес в LAN. Правило DNAT на шлюзе переписывает адрес назначения на WILS всем пакетам которые приходят на алиас, а правило SNAT переписывает адрес отправителя всем пакетам которые от WILS.
В обоих случаях, необходимый функционал достигается стандартными средствами. В смысле, распостранёнными и лёгкими для делегирования. Кроме того, он переносимыми с одного типа устройства на другой, например, если взбредёт в голову сменить CentOS на другой дистрибутив, или вообще на железное решение.
Удачи.
> В обоих случаях, необходимый функционал достигается стандартными средствами. В смысле,
> распостранёнными и лёгкими для делегирования. Кроме того, он переносимыми с одного
> типа устройства на другой, например, если взбредёт в голову сменить CentOS
> на другой дистрибутив, или вообще на железное решение.Вариантов решения одной задачи несколько больше, чем один и каждый имеет право на существование.
ARP Proxy был применён в этой схеме ещё до меня, а мне сейчас переделывать нет ни времени, ни желания.> Удачи.
Спасибо. Вам тоже.
> Вариантов решения одной задачи несколько больше, чем один и каждый имеет право
> на существование.Разумеется. Я не преследую цель поддержать традицию ответов в духе "у вас всё неправильно, переделывайте", а наоборот, пытаюсь понять, какие разные способы используют другие, чтобы при случае пересмотреть собственные привычки. Ну, и делюсь своими, в надежде что оно кому-то окажется полезно.
> ARP Proxy был применён в этой схеме ещё до меня, а мне
> сейчас переделывать нет ни времени, ни желания.Охотно верю, самому часто приходится заниматься увлекательным траблшутингом схем, сделанных до нас.
Я так и не понял одну важную деталь вашей конфигурации, но готов на этом остановиться и пометку "использовать arp-proxy чтобы спрятать собственную инфраструкуру от несотрудничающего админстратора сети" себе сделал.
Если вам покажется, что какой-то из методов которые я изложил, сделает вам жизнь проще, и ситуация с временем и желанием изменится, то я готов поделиться деталями.
> Я так и не понял одну важную деталь вашей конфигурации, но готов
> на этом остановиться и пометку "использовать arp-proxy чтобы спрятать собственную инфраструкуру
> от несотрудничающего админстратора сети" себе сделал.
> Если вам покажется, что какой-то из методов которые я изложил, сделает вам
> жизнь проще, и ситуация с временем и желанием изменится, то я
> готов поделиться деталями.На новогодних каникулах я планирую переделать существующую инфраструктуру. В частности, избавиться от arp-proxy - задача номер один.
Спасибо Вам за предложение.
>[оверквотинг удален]
> Кроме того, провайдером выделено ещё дополнительный адрес 198.51.100.201, Машина (назовём
> её WILS) с этим адресом размещена в локальной сети.
> Для того, чтобы WILS работал нормально, на сервере нужно исполнить следующую команду:
> ip neigh add proxy 198.51.100.201 dev enp1s0
> Я эту команду добавил в /etc/rc.d/init.d/network и последствия не заставили себя долго
> ждать, так как очередное обновление системы перезаписало этот файл и уничтожило
> эту команду.
> Подскажите, а где правильно прописать эту команду?
> Можно, конечно, создать сервис, который поднимает эту команду, но, возможно, есть более
> правильное решение?В анализаторе конфига есть такой параметр, как "OTHERSCRIPT", судя по всему популярностью не пользуется, но может попробовать?
Вдруг это именно то, что спасет Кису Воробьянинова?
> Вдруг это именно то, что спасет Кису Воробьянинова?А кто этот Киса Воробьянинов?
Не отец ли русской демократии и гигант мысли по совместительству?
/etc/rc.local