Comments 39
Ну это как-то естественно, если на сервер маршрутизируются снаружи другие адреса, совсем не обязательно на этот сервер устанавливать все эти адреса. Только обычно это какая-то подсеть, например x.x.x.0/24 и для этого сервера устанавливается x.x.x.1, а остальным внутри раздаются адреса из этой сети и x.x.x.1 как default gateway.
В чем новизна или я что-то не понял?
В чем новизна или я что-то не понял?
Новизна как раз в том что маршрутизируется левый одиночный IP-адрес (не сеть), не имеющий ничего общего с адресом сервера-шлюза. И на внутреннем сервере никак не получится настроить маршрутизацию обычным образом через подсеть и шлюз пол умолчанию с IP из той же сети.
Поясняю на примере из практики по которому статья и написана:
Есть сервер с публичным адресом 1.1.1.1
Кроме этого на сервере добавлен отказоустойчивый IP 1.2.3.4, который может перекидываться между серверами через API дата-центра. Это одиночный IP-адрес (не сеть адресов), у него нет макси и шлюза по умолчанию со стороны дата-центра.
Нужно назначить этот адрес на виртуальную машину внутри сервера таким образом, чтобы можно было быстро и удобно поднять копию этой виртуальной машины на другом физическом сервере.
При этом на сетевом интерфейсе виртуальной машины должен быть IP-адрес 1.2.3.4, т.к. внутри установлен софт который привязывается к IP-адресу и проверяет его как запросами во внешнюю сеть, так и по наличию адреса на интерфейсе с которого эти запросы в сеть уходят.
Попробуйте поискать инструкции про проброс внешнего IP-адреса к серверу из локальной сети, я много раз искал такие инструкции и всегда находил только тот или иной вариант настройки перенаправлений через iptables. При этом трафик ходит, но внешний IP-адрес на внутреннем сервере отсутствует (это для меня было основным в данном случае) + как оказалось вариант с маршрутизацией еще и настраивается проще.
Поясняю на примере из практики по которому статья и написана:
Есть сервер с публичным адресом 1.1.1.1
Кроме этого на сервере добавлен отказоустойчивый IP 1.2.3.4, который может перекидываться между серверами через API дата-центра. Это одиночный IP-адрес (не сеть адресов), у него нет макси и шлюза по умолчанию со стороны дата-центра.
Нужно назначить этот адрес на виртуальную машину внутри сервера таким образом, чтобы можно было быстро и удобно поднять копию этой виртуальной машины на другом физическом сервере.
При этом на сетевом интерфейсе виртуальной машины должен быть IP-адрес 1.2.3.4, т.к. внутри установлен софт который привязывается к IP-адресу и проверяет его как запросами во внешнюю сеть, так и по наличию адреса на интерфейсе с которого эти запросы в сеть уходят.
Попробуйте поискать инструкции про проброс внешнего IP-адреса к серверу из локальной сети, я много раз искал такие инструкции и всегда находил только тот или иной вариант настройки перенаправлений через iptables. При этом трафик ходит, но внешний IP-адрес на внутреннем сервере отсутствует (это для меня было основным в данном случае) + как оказалось вариант с маршрутизацией еще и настраивается проще.
Вы, похоже, мыслите категориями домашних локалок, роутера с портом во «внутреннюю сеть» и в «интернет», потому и говорите нелепости про какой-то «проброс», называя им естественный механизм продвижения пакетов на роутерах. Статья про заурядный роутинг /32 префикса подаётся под соусом нового технологического решения.
Простите, для интереса, а какой публичный адрес вы назначили самому серверу S0?
(Если бы ему был назначен 1.2.3.4, ваша команда маршрутизации на нём ip route 1.2.3.4 255.255.255.255 куда-угодно была бы совершенно бесполезна, т.к. в его таблице local, которая обрабатывается всегда первой, уже была бы запись local 1.2.3.4 dev eth0 proto kernel scope host src 1.2.3.4)
(Если бы ему был назначен 1.2.3.4, ваша команда маршрутизации на нём ip route 1.2.3.4 255.255.255.255 куда-угодно была бы совершенно бесполезна, т.к. в его таблице local, которая обрабатывается всегда первой, уже была бы запись local 1.2.3.4 dev eth0 proto kernel scope host src 1.2.3.4)
Как я понял, у S0 свой адрес, никак не связанный с 1.2.3.4
Я тоже так предполагаю. Но это нужно было написать, а то вдруг автор изобрёл неведомое мне страшное колдунство в линуксе, про которое я до сих пор не знал.
Если так, то вообще непонятно, зачем эта статья. Это базовая маршрутизация IP, с этого начинается изучение собственно процесса маршрутизации. И непонятно, зачем тут вообще упомянут iptables и зачем маршрутизатор сравнивают с пакетным фильтром.
Если так, то вообще непонятно, зачем эта статья. Это базовая маршрутизация IP, с этого начинается изучение собственно процесса маршрутизации. И непонятно, зачем тут вообще упомянут iptables и зачем маршрутизатор сравнивают с пакетным фильтром.
Поправил входные данные, добавил что есть внешний адрес, который не используется в настройках.
Она возможно и базовая и те кто изучают маршрутизацию в вузах/курсах возможно это и изучают еще в начале. Однако по вопросу проброса IP-адреса я находил исключительно варианты с подменой адресов в iptables, поэтому с ним и сравниваю.
Посмотрите например yandex google
а статья как раз и призвана показать более правильный способ.
P.S. заголовок тоже поправил, чтобы по пробросу статья легко находилась.
Она возможно и базовая и те кто изучают маршрутизацию в вузах/курсах возможно это и изучают еще в начале. Однако по вопросу проброса IP-адреса я находил исключительно варианты с подменой адресов в iptables, поэтому с ним и сравниваю.
Посмотрите например yandex google
а статья как раз и призвана показать более правильный способ.
P.S. заголовок тоже поправил, чтобы по пробросу статья легко находилась.
«Проброс» — это вообще жаргон, который обозначает трансляцию (адреса и/или порта). То есть, совершенно нормально и правильно, что вы по запросу «как сделать трансляцию адреса» находили статьи про трансляцию адреса. Совет: завязывайте с жаргоном, он скрывает от вас смысл ваших действий. Называйте вещи своими именами.
Маршрутизация — это не «проброс». И запрос поисковый, соответственно, должен быть другой. Это настолько основы, что даже затрудняюсь подсказать, как это искать — это тупо описано в каждом учебнике по tcp/ip. Вкратце — для машршутизации нужно включить форвардинг пакетов и прописать необходимые маршруты.
Как в вашей статье образовался iptables я понимаю — вы всё изучали по статьям типа «хау ту», вместо последовательного чтения учебников и стандартов (RFC), что плохо. А ещё хуже то, что образовавшейся кашей в голове вы делитесь с окружающими. Не надо так.
Маршрутизация — это не «проброс». И запрос поисковый, соответственно, должен быть другой. Это настолько основы, что даже затрудняюсь подсказать, как это искать — это тупо описано в каждом учебнике по tcp/ip. Вкратце — для машршутизации нужно включить форвардинг пакетов и прописать необходимые маршруты.
Как в вашей статье образовался iptables я понимаю — вы всё изучали по статьям типа «хау ту», вместо последовательного чтения учебников и стандартов (RFC), что плохо. А ещё хуже то, что образовавшейся кашей в голове вы делитесь с окружающими. Не надо так.
«Проброс» — это вообще жаргон, который обозначает трансляцию (адреса и/или порта). То есть, совершенно нормально и правильно, что вы по запросу «как сделать трансляцию адреса» находили статьи про трансляцию адреса. Совет: завязывайте с жаргоном, он скрывает от вас смысл ваших действий. Называйте вещи своими именами.
К сожалению жаргон нигде не закреплен и каждый может понимать его немного по-своему, в частности я не нашел определения слова «проброс» в контекста нашего общения.
Впрочем по марштуризации внешнего IP во внутренюю сеть тоже.
Изучение RFC хорошо для понимания основ работы протокола, но к сожалению не дает представления об инструментах и практике применения.
Про учебники: к сожалению я не видел учебников, объясняющих подобные вещи. Подскажите мне — я с удовольствием почитаю.
А ещё хуже то, что образовавшейся кашей в голове вы делитесь с окружающими. Не надо так.
Подскажите мне более толковую статью и путь которым я мог бы её найти решая свою задачу. Если они действительно есть и я не увидел чего-то очевидного — я извинюсь и удалю свою кашу.
Подобные азы маршрутизации описаны в RFC 1180 (это туториал-учебник). Можно почитать перевод.
А по поводу каши в голове… Просто представьте себе свою статью без упоминания iptables, и она сократится до пятнадцати строк, вроде этого. А это непосредственно в RFC-учебнике конечно не написано, но следует напрямую. Это явно недостойно отдельной статьи.
А по поводу каши в голове… Просто представьте себе свою статью без упоминания iptables, и она сократится до пятнадцати строк, вроде этого. А это непосредственно в RFC-учебнике конечно не написано, но следует напрямую. Это явно недостойно отдельной статьи.
Я прочитал этот RFC и из него я бы понял теорию «я хочу отправить IP 1.2.3.4 в сеть brLAN, а с S1 отправить трафик через S0 во внешний мир», т.е. это фоновые знания о том как работает маршрутизация в принципе, к сожалению этот RFC не описывает и даже не намекает на то как достигнуть желаемого результата на практике.
Статья же призвана решить конкретную практическую задачу, т.е. это просто разные вещи.
К тому же примеры именно про то что каждому ethernet-фрагменту соответствует своя подсеть IP-адресов — точно так же как во всех руководствах, учебниках и статьях которые я видел по IPv4 (в отличие от IPv6 где шлюз в другой подсети это норма). Поскольку везде приведены именно такие примеры, то иное поведение (шлюз с IP из другой сети) совершенно неочевидно.
Сравнение с iptables включено в статью специально — как раз чтобы показать что это более правильная альтернатива популярному костылю.
Статья же призвана решить конкретную практическую задачу, т.е. это просто разные вещи.
К тому же примеры именно про то что каждому ethernet-фрагменту соответствует своя подсеть IP-адресов — точно так же как во всех руководствах, учебниках и статьях которые я видел по IPv4 (в отличие от IPv6 где шлюз в другой подсети это норма). Поскольку везде приведены именно такие примеры, то иное поведение (шлюз с IP из другой сети) совершенно неочевидно.
Сравнение с iptables включено в статью специально — как раз чтобы показать что это более правильная альтернатива популярному костылю.
Статья нужная, т.к. многие при задаче пробросить внешний IP внутрь начнут городить NAT на шлюзе.
Да, у S0 свой адрес, например 1.1.1.1, он никак в настройке не участвует поэтому в статье и не упоминается.
чет я не понял, а как вы собрались на S1 роутить трафик в сеть 192.168.0.0/24, если у вас на S1 нет ip-адреса из этой подсети?
Всё верно — внутренний IP на S1 не требуется. При отправке пакетов в качестве адреса источника указывается публичный IP 1.2.3.4.
192.168.0.1 это просто удобный маркер, чтобы внутри ethernet-сети brLAN найти MAC-адрес интерфейса на который отправлять пакеты, предназначенные публичной сети. В конце статьи описано как избавиться и от него тоже.
Работает это так:
При отправке пакета S1 смотрит свою таблицу маршрутизации и видит там указание:
— Весь внешний трафик отправлять через 192.168.0.1, смотрит как достучаться до 192.168.0.1
— пакеты на 192.168.0.1 слать через интерфейс eth0 (в сеть brLAN)
— S1 отправляет ARP-запрос вида: «У кого в этой сети IP 192.168.0.1» и получает ответ с интерфейса сервера S0
— S1 отправляет пакет с адресом источника 1.2.3.4 и адресом назначения на интерфейс S0 по его MAC-адресу, а S0 уже продвигает его дальше
При обратном процессе:
— S0 получает пакет для 1.2.3.4 и смотрит свою таблицу маршрутизации
— видит правило — пакеты для 1.2.3.4 отправлять в сеть brLAN
— S0 отправляет ARP-запрос «У кого в этой сети адрес 1.2.3.4?» и получает ответ с интерфейса S1
— отправляет трафик для 1.2.3.4 на интерфейс S1 по его MAC-адресу.
192.168.0.1 это просто удобный маркер, чтобы внутри ethernet-сети brLAN найти MAC-адрес интерфейса на который отправлять пакеты, предназначенные публичной сети. В конце статьи описано как избавиться и от него тоже.
Работает это так:
При отправке пакета S1 смотрит свою таблицу маршрутизации и видит там указание:
— Весь внешний трафик отправлять через 192.168.0.1, смотрит как достучаться до 192.168.0.1
— пакеты на 192.168.0.1 слать через интерфейс eth0 (в сеть brLAN)
— S1 отправляет ARP-запрос вида: «У кого в этой сети IP 192.168.0.1» и получает ответ с интерфейса сервера S0
— S1 отправляет пакет с адресом источника 1.2.3.4 и адресом назначения на интерфейс S0 по его MAC-адресу, а S0 уже продвигает его дальше
При обратном процессе:
— S0 получает пакет для 1.2.3.4 и смотрит свою таблицу маршрутизации
— видит правило — пакеты для 1.2.3.4 отправлять в сеть brLAN
— S0 отправляет ARP-запрос «У кого в этой сети адрес 1.2.3.4?» и получает ответ с интерфейса S1
— отправляет трафик для 1.2.3.4 на интерфейс S1 по его MAC-адресу.
То есть возможности доступа к S1 через приватные сети нет, как я понимаю? То есть, если вдруг S0 умрет, то на S1 никак, кроме как через консоль, не попадешь?
Если не назначать дополнительных внутренних адресов — да.
С другой стороны никто не мешает это сделать при необходимости.
В моем случае S1 это виртуальный сервер и если S0 сдохнет то к S1 я всё равно не попаду пока не подниму его на другом физическом сервере — а там он снова по публичному адресу будет доступен.
С другой стороны никто не мешает это сделать при необходимости.
В моем случае S1 это виртуальный сервер и если S0 сдохнет то к S1 я всё равно не попаду пока не подниму его на другом физическом сервере — а там он снова по публичному адресу будет доступен.
Через маршрутизатор. Перечитайте, на S1 добавляется прямой маршрут до системы 192.168.0.1, и потом весь трафик направляется через неё.
По сути, назначение адреса, например, 192.168.0.5/24 на интерфейс eth0 производит в системе следующее:
— Система запоминает адрес 192.168.0.5 как «свой», и будет передавать пакеты, назначенные этому адресу, соответствующим процессам;
— Добавляется маршрут local 192.168.0.5, чтобы с самой системы пакеты на этот адрес заворачивались на lo. То есть, наружу не уходили. Более того, маршрут добавляется в таблицу local (можете посмотреть его полностью командой ip route show table local), которая всегда обрабатывается первой (в правиле RPDB 0, можете проверить комадной ip rule show — правило 0 гласит lookup table local, правило 65534 — lookup table main, в которую маршруты попадают по умолчанию, 65535 — default, которая пуста).
— Добавляется маршрут 192.168.0.0/24 dev eth0, т.е. «все пакеты этой сети направлять непосредственно через интерфейс eth0». Он добавляется в таблицу main.
Маска подсети влияет только на вид последнего маршрута. Можно достичь абсолютно того же эффекта, если написать ip addr add 192.168.0.5/32 dev eth0; ip route add 192.168.0.0/24 dev eth0. Сравните эти два правила с тем, что написано в статье — разница только в том, что вместо маршрута для всей сети добавляется маршрут до одного адреса. А потом вся сеть маршрутизируется через этот адрес.
Если кто-то арендует сервере в Hetzner, то уже знает, что именно так у них всё и работает. И если вы запросите дополнительные адреса и назначаете их виртуалкам, вам придётся делать маршрутизацию абсолютно так, как написано в этой статье. То же самое, к слову, написано и в вики Хетцнера.
По сути, назначение адреса, например, 192.168.0.5/24 на интерфейс eth0 производит в системе следующее:
— Система запоминает адрес 192.168.0.5 как «свой», и будет передавать пакеты, назначенные этому адресу, соответствующим процессам;
— Добавляется маршрут local 192.168.0.5, чтобы с самой системы пакеты на этот адрес заворачивались на lo. То есть, наружу не уходили. Более того, маршрут добавляется в таблицу local (можете посмотреть его полностью командой ip route show table local), которая всегда обрабатывается первой (в правиле RPDB 0, можете проверить комадной ip rule show — правило 0 гласит lookup table local, правило 65534 — lookup table main, в которую маршруты попадают по умолчанию, 65535 — default, которая пуста).
— Добавляется маршрут 192.168.0.0/24 dev eth0, т.е. «все пакеты этой сети направлять непосредственно через интерфейс eth0». Он добавляется в таблицу main.
Маска подсети влияет только на вид последнего маршрута. Можно достичь абсолютно того же эффекта, если написать ip addr add 192.168.0.5/32 dev eth0; ip route add 192.168.0.0/24 dev eth0. Сравните эти два правила с тем, что написано в статье — разница только в том, что вместо маршрута для всей сети добавляется маршрут до одного адреса. А потом вся сеть маршрутизируется через этот адрес.
Если кто-то арендует сервере в Hetzner, то уже знает, что именно так у них всё и работает. И если вы запросите дополнительные адреса и назначаете их виртуалкам, вам придётся делать маршрутизацию абсолютно так, как написано в этой статье. То же самое, к слову, написано и в вики Хетцнера.
Если кто-то арендует сервере в Hetzner, то уже знает, что именно так у них всё и работает. И если вы запросите дополнительные адреса и назначаете их виртуалкам, вам придётся делать маршрутизацию абсолютно так, как написано в этой статье. То же самое, к слову, написано и в вики Хетцнера.
Да, действительно — нашел у них даже пример конфигов Centos Debian
Допишу в статью настройку для сервера через конфиги.
Почему у хостеров так делается это вполне понятно. Им не нужно, чтобы внутренний трафик мог ходить в обход ядра обсчитывающего трафик. Да и для удаленного сервера локальные приватные ip-адреса — лишняя сущность…
А зачем такое делать в локальной сети? Если S0 по каким либо причинам вдруг станет недоступен, то S1 будет доступен только через консоль. Это сложно называть удобным. А ради чего сыр-бор?..
А зачем такое делать в локальной сети? Если S0 по каким либо причинам вдруг станет недоступен, то S1 будет доступен только через консоль. Это сложно называть удобным. А ради чего сыр-бор?..
Ого, да тут уже пишут статью как маршрут прописать. Деградация ресурса идёт полным ходом.
Да вот и я страдаю :( И плюсуют, главное. Как же это, нет такого туториала и в интернете не находится…
Нет худа без добра. Мне захотелось написать статью про роутинг на OpenVZ-хостах с сетью venet, которые имеют внутреннюю и внешнюю сеть и дают виртуалкам внутренние и внешние адреса. Официальное руководство на этот счёт только даёт рекомендацию использовать veth.
А чем плохо?
Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?
А так есть хороший шанс, что кто-то вместо костыля с iptables настроит себе правильную маршрутизацию.
Что же делать если такой простой вопрос как маршрутизация внешнего IP на сервер во внутренней сети часто решается таким грубым и популярным костылем как iptables и подмена адресов через него.
Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?
А так есть хороший шанс, что кто-то вместо костыля с iptables настроит себе правильную маршрутизацию.
Что же делать если такой простой вопрос как маршрутизация внешнего IP на сервер во внутренней сети часто решается таким грубым и популярным костылем как iptables и подмена адресов через него.
Популярным среди кого?
Почему бы ещё не писать каждые полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.
Почему бы ещё не писать каждые полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.
Популярным среди тех кто пишет инструкции — подобная задача у меня возникала в разных вариантах в разные годы и ни разу я не нашел никакой инструкции о её решении через маршрутизацию. Т.е. на теоретическом уровне я знал что это возможно, но как сделать — было совершенно непонятно. В предыдущих задачах вопрос «как» был второстепенным — нужно было чтобы трафик доходил до места назначения и я тоже делал по тем инструкциям которые находил, тоже костылем через iptables, т.к. глубоко изучать тему маршрутизации для того чтобы условно получить http-запрос на виртуалке смысла не вижу. Если глубоко всесторонне изучать каждый вопрос который приходится решать — до решения можно так и не дойти, поэтому приходилось пользоваться инструкциями которые просто работали.
Потом моя задача усложнилась и стало нужно делать это:
1. Просто — для автоматизации
2. Надежно и понятно — без танцев вокруг iptables с разными вариантами того откуда пакет пришел
3. Сохранять IP для исходящего трафика, а не только принимать входящий
И пришло время изучить тему более подробно, применив тот объем фоновых знаний который уже накопился в процессе других экспериментов с маршрутизацией.
И найдя простое решение я решил упростить жизнь тем кто будет решать подобную задачу, но еще не имеет достаточного опыта для собственных экспериентов с маршрутами или не имеет времени на эти экспериенты.
Согласитель — когда задачу нужно решить «сейчас» никто не будет тратить несколько дней/недель на глубокое вникание в вопрос, а найдут инструкцию которая работает. В лучшем случае еще и «понятно работает». Инструкция с iptables хоть костыльна, но вполне понятна и на куче форумов рекомендуют именно её и почему-то не рекомендуют вариант правильной маршрутизации. Либо об этом мало кто знает, либо те кто знают уже не общаются на форумах, а просто знают и настраивают свои системы. Новичкам приходится использовать костыли.
Этой инструкцией в частности я предлагаю простой правильный путь массово предлагаемому костылю. Врядли это убивание ресурса.
По установке ubuntu инструкций много, но например если бы все поголовно инстркции сетевой установки рекомендовали скачать iso-образ по сети, нарезать на болванку и дальше ставить как обычно и называли бы это «сетевой» установкой потому что образ качается по сети то вполне имело бы смысл написать инструкцию про установку через pxe например для тех случаев, когда нарезание болванки неудобно.
Потом моя задача усложнилась и стало нужно делать это:
1. Просто — для автоматизации
2. Надежно и понятно — без танцев вокруг iptables с разными вариантами того откуда пакет пришел
3. Сохранять IP для исходящего трафика, а не только принимать входящий
И пришло время изучить тему более подробно, применив тот объем фоновых знаний который уже накопился в процессе других экспериментов с маршрутизацией.
И найдя простое решение я решил упростить жизнь тем кто будет решать подобную задачу, но еще не имеет достаточного опыта для собственных экспериентов с маршрутами или не имеет времени на эти экспериенты.
Согласитель — когда задачу нужно решить «сейчас» никто не будет тратить несколько дней/недель на глубокое вникание в вопрос, а найдут инструкцию которая работает. В лучшем случае еще и «понятно работает». Инструкция с iptables хоть костыльна, но вполне понятна и на куче форумов рекомендуют именно её и почему-то не рекомендуют вариант правильной маршрутизации. Либо об этом мало кто знает, либо те кто знают уже не общаются на форумах, а просто знают и настраивают свои системы. Новичкам приходится использовать костыли.
Этой инструкцией в частности я предлагаю простой правильный путь массово предлагаемому костылю. Врядли это убивание ресурса.
Почему бы ещё не писать каждый полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.
По установке ubuntu инструкций много, но например если бы все поголовно инстркции сетевой установки рекомендовали скачать iso-образ по сети, нарезать на болванку и дальше ставить как обычно и называли бы это «сетевой» установкой потому что образ качается по сети то вполне имело бы смысл написать инструкцию про установку через pxe например для тех случаев, когда нарезание болванки неудобно.
Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?
Всем. Очередная заблудшая душа, не найдя этот топик, наконец соизволила бы сесть, прочитать несчастный RFC-учебник и разобраться с основами, как же всё-таки маршрутизация работает, и сделать самостоятельно. Человек который «понял и смог сделать» гораздо ценнее человека, который «смог сделать». (А объясняете вы всё так отвратительно, что я даже не сразу понял, что именно вы сделали — несколько раз перечитал и задал вопрос. А я не вчера всякие сети настраивать стал.)
Возможно статья не идеальна, возвращаемся тому же, но другого я не нашел — покажите или изложите лучше.
Я почитал RFC о котором вы говорили, в нем описана общая теория, этот конкретный случай из неё не следует, к тому же практика настройки в нем не описывается вообще.
Что вы не вчера сети настраивать начали я в курсе, около месяца назад читал вашу статью о настройке mgre от 2009 года.
Я почитал RFC о котором вы говорили, в нем описана общая теория, этот конкретный случай из неё не следует, к тому же практика настройки в нем не описывается вообще.
Что вы не вчера сети настраивать начали я в курсе, около месяца назад читал вашу статью о настройке mgre от 2009 года.
А не проще ли было использовать bridge?
К сожалению в данном случае это невозможно: все пакеты наружу должны уходить с MAC-адреса интерфейса физического сервера, входящие тоже доставляются на MAC физического интерфейса.
Если рассматривать не конкретно этот случай, а случай локальной сети, то бридж откроет наружу всю локальную сеть, а не только один сервер который нужно открыть.
Если рассматривать не конкретно этот случай, а случай локальной сети, то бридж откроет наружу всю локальную сеть, а не только один сервер который нужно открыть.
Вы про безопасность решили вспомнить? Без нелюбимого вами iptables разницы особой нет, так к вам пакеты заходят или эдак.
Про mac адресам мне вообще не особо понятно что имеется ввиду. Вы боитесь, что вас хакнут на канальном уровне по MAC адресу?
PS. У вас очень неудачная терминология.
Про mac адресам мне вообще не особо понятно что имеется ввиду. Вы боитесь, что вас хакнут на канальном уровне по MAC адресу?
PS. У вас очень неудачная терминология.
Спасибо я умею пользоваться iptables.
А по мак-адресам имеется ввиду фильтрация трафика со стороны дата-центра: если я буду отправлять трафик через bridge, то в качестве mac-адреса источника будет стоять не тот mac который указан в ДЦ для сетевого интерфейса моего сервера, а mac-адрес виртуальной машины и весь трафик просто отбросится на стороне дата-центра.
А по мак-адресам имеется ввиду фильтрация трафика со стороны дата-центра: если я буду отправлять трафик через bridge, то в качестве mac-адреса источника будет стоять не тот mac который указан в ДЦ для сетевого интерфейса моего сервера, а mac-адрес виртуальной машины и весь трафик просто отбросится на стороне дата-центра.
Sign up to leave a comment.
Шпаргалка по пробросу IP во внутреннюю сеть без моста и iptables в 4 команды