Спасибо я умею пользоваться iptables.
А по мак-адресам имеется ввиду фильтрация трафика со стороны дата-центра: если я буду отправлять трафик через bridge, то в качестве mac-адреса источника будет стоять не тот mac который указан в ДЦ для сетевого интерфейса моего сервера, а mac-адрес виртуальной машины и весь трафик просто отбросится на стороне дата-центра.
К сожалению в данном случае это невозможно: все пакеты наружу должны уходить с MAC-адреса интерфейса физического сервера, входящие тоже доставляются на MAC физического интерфейса.
Если рассматривать не конкретно этот случай, а случай локальной сети, то бридж откроет наружу всю локальную сеть, а не только один сервер который нужно открыть.
Популярным среди тех кто пишет инструкции — подобная задача у меня возникала в разных вариантах в разные годы и ни разу я не нашел никакой инструкции о её решении через маршрутизацию. Т.е. на теоретическом уровне я знал что это возможно, но как сделать — было совершенно непонятно. В предыдущих задачах вопрос «как» был второстепенным — нужно было чтобы трафик доходил до места назначения и я тоже делал по тем инструкциям которые находил, тоже костылем через iptables, т.к. глубоко изучать тему маршрутизации для того чтобы условно получить http-запрос на виртуалке смысла не вижу. Если глубоко всесторонне изучать каждый вопрос который приходится решать — до решения можно так и не дойти, поэтому приходилось пользоваться инструкциями которые просто работали.
Потом моя задача усложнилась и стало нужно делать это:
1. Просто — для автоматизации
2. Надежно и понятно — без танцев вокруг iptables с разными вариантами того откуда пакет пришел
3. Сохранять IP для исходящего трафика, а не только принимать входящий
И пришло время изучить тему более подробно, применив тот объем фоновых знаний который уже накопился в процессе других экспериментов с маршрутизацией.
И найдя простое решение я решил упростить жизнь тем кто будет решать подобную задачу, но еще не имеет достаточного опыта для собственных экспериентов с маршрутами или не имеет времени на эти экспериенты.
Согласитель — когда задачу нужно решить «сейчас» никто не будет тратить несколько дней/недель на глубокое вникание в вопрос, а найдут инструкцию которая работает. В лучшем случае еще и «понятно работает». Инструкция с iptables хоть костыльна, но вполне понятна и на куче форумов рекомендуют именно её и почему-то не рекомендуют вариант правильной маршрутизации. Либо об этом мало кто знает, либо те кто знают уже не общаются на форумах, а просто знают и настраивают свои системы. Новичкам приходится использовать костыли.
Этой инструкцией в частности я предлагаю простой правильный путь массово предлагаемому костылю. Врядли это убивание ресурса.
Почему бы ещё не писать каждый полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.
По установке ubuntu инструкций много, но например если бы все поголовно инстркции сетевой установки рекомендовали скачать iso-образ по сети, нарезать на болванку и дальше ставить как обычно и называли бы это «сетевой» установкой потому что образ качается по сети то вполне имело бы смысл написать инструкцию про установку через pxe например для тех случаев, когда нарезание болванки неудобно.
А чем плохо?
Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?
А так есть хороший шанс, что кто-то вместо костыля с iptables настроит себе правильную маршрутизацию.
Что же делать если такой простой вопрос как маршрутизация внешнего IP на сервер во внутренней сети часто решается таким грубым и популярным костылем как iptables и подмена адресов через него.
Это зависит от задачи. Опять же как я отвечал вам выше — никто не мешает добавить локальные адреса если они нужны.
При этом по внутреннему адресу сервер продолжит быть доступным, при этом настройки на шлюзе остаются простыми вместо лапши из переписываний IP в iptables на все случаи жизни.
А где вы видите «новое технологическое решение»? Я лично ничего такого ввиду не имел. Конкретная шпаргалка для решения конкретной задачи, ни больше ни меньше.
Если не назначать дополнительных внутренних адресов — да.
С другой стороны никто не мешает это сделать при необходимости.
В моем случае S1 это виртуальный сервер и если S0 сдохнет то к S1 я всё равно не попаду пока не подниму его на другом физическом сервере — а там он снова по публичному адресу будет доступен.
Если кто-то арендует сервере в Hetzner, то уже знает, что именно так у них всё и работает. И если вы запросите дополнительные адреса и назначаете их виртуалкам, вам придётся делать маршрутизацию абсолютно так, как написано в этой статье. То же самое, к слову, написано и в вики Хетцнера.
Да, действительно — нашел у них даже пример конфигов CentosDebian
Допишу в статью настройку для сервера через конфиги.
Я прочитал этот RFC и из него я бы понял теорию «я хочу отправить IP 1.2.3.4 в сеть brLAN, а с S1 отправить трафик через S0 во внешний мир», т.е. это фоновые знания о том как работает маршрутизация в принципе, к сожалению этот RFC не описывает и даже не намекает на то как достигнуть желаемого результата на практике.
Статья же призвана решить конкретную практическую задачу, т.е. это просто разные вещи.
К тому же примеры именно про то что каждому ethernet-фрагменту соответствует своя подсеть IP-адресов — точно так же как во всех руководствах, учебниках и статьях которые я видел по IPv4 (в отличие от IPv6 где шлюз в другой подсети это норма). Поскольку везде приведены именно такие примеры, то иное поведение (шлюз с IP из другой сети) совершенно неочевидно.
Сравнение с iptables включено в статью специально — как раз чтобы показать что это более правильная альтернатива популярному костылю.
Всё верно — внутренний 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-адресу.
«Проброс» — это вообще жаргон, который обозначает трансляцию (адреса и/или порта). То есть, совершенно нормально и правильно, что вы по запросу «как сделать трансляцию адреса» находили статьи про трансляцию адреса. Совет: завязывайте с жаргоном, он скрывает от вас смысл ваших действий. Называйте вещи своими именами.
К сожалению жаргон нигде не закреплен и каждый может понимать его немного по-своему, в частности я не нашел определения слова «проброс» в контекста нашего общения.
Впрочем по марштуризации внешнего IP во внутренюю сеть тоже.
Изучение RFC хорошо для понимания основ работы протокола, но к сожалению не дает представления об инструментах и практике применения.
Про учебники: к сожалению я не видел учебников, объясняющих подобные вещи. Подскажите мне — я с удовольствием почитаю.
А ещё хуже то, что образовавшейся кашей в голове вы делитесь с окружающими. Не надо так.
Подскажите мне более толковую статью и путь которым я мог бы её найти решая свою задачу. Если они действительно есть и я не увидел чего-то очевидного — я извинюсь и удалю свою кашу.
Поправил входные данные, добавил что есть внешний адрес, который не используется в настройках.
Она возможно и базовая и те кто изучают маршрутизацию в вузах/курсах возможно это и изучают еще в начале. Однако по вопросу проброса IP-адреса я находил исключительно варианты с подменой адресов в iptables, поэтому с ним и сравниваю.
Посмотрите например yandexgoogle
а статья как раз и призвана показать более правильный способ.
P.S. заголовок тоже поправил, чтобы по пробросу статья легко находилась.
Новизна как раз в том что маршрутизируется левый одиночный IP-адрес (не сеть), не имеющий ничего общего с адресом сервера-шлюза. И на внутреннем сервере никак не получится настроить маршрутизацию обычным образом через подсеть и шлюз пол умолчанию с IP из той же сети.
Поясняю на примере из практики по которому статья и написана:
Есть сервер с публичным адресом 1.1.1.1
Кроме этого на сервере добавлен отказоустойчивый IP 1.2.3.4, который может перекидываться между серверами через API дата-центра. Это одиночный IP-адрес (не сеть адресов), у него нет макси и шлюза по умолчанию со стороны дата-центра.
Нужно назначить этот адрес на виртуальную машину внутри сервера таким образом, чтобы можно было быстро и удобно поднять копию этой виртуальной машины на другом физическом сервере.
При этом на сетевом интерфейсе виртуальной машины должен быть IP-адрес 1.2.3.4, т.к. внутри установлен софт который привязывается к IP-адресу и проверяет его как запросами во внешнюю сеть, так и по наличию адреса на интерфейсе с которого эти запросы в сеть уходят.
Попробуйте поискать инструкции про проброс внешнего IP-адреса к серверу из локальной сети, я много раз искал такие инструкции и всегда находил только тот или иной вариант настройки перенаправлений через iptables. При этом трафик ходит, но внешний IP-адрес на внутреннем сервере отсутствует (это для меня было основным в данном случае) + как оказалось вариант с маршрутизацией еще и настраивается проще.
Я в своём сравнении отразил свою точку зрения — что его можно получить одним из двух способов — по подписке и за разовую оплату, указал обе стоимости.
Вписал в описание LR добавку по этому поводу, в таблице считаю должны присуствовать обе цены.
Да, можно. В данном контексте это цена за LR, т.к. это продвигаемый способ его оплаты и уверен что большинство будет покупать его именно так. Остальной Creative Cloud им может быть нафиг не нужен, но его оплатят потому что кнопка была на видном месте.
Там еще вверху есть «How to buy» — там предлагается ТОЛЬКО подписка. Так что с точки зрения adobe это именно штатный способ получения LR, а постоянная покупка для относительно небольшой группы лиц которые знают что есть другой способ оплаты и его искать.
Это для США. Если указывать Россию — получается 299 рублей, это несколько меньше чем $9.99 но порядок тот же. Стоит он столько при подписке на Photoshop+Lightroom, промахнуться сложно — это самый заметный вариант по кнопке How to buy. Вот просто покупку за $149 это надо еще вниз страницу прокрутить и внимательно кнопочки почитать.
Тоже поправил. Может и специальные поля для людей тоже есть? А то я просто ключевыми словами всех отмечаю. Пока людей еще не очень много — я бы с удовольствием их переделал на какой-то более стандартный вариант.
Спасибо. Нашёл, поправил.
Это как раз та часть программы, которая мне особо не нужна. О том чтобы выделять города как-то отдельно, а не просто ключевыми словами мне и мысль в голову не приходила пока не увидел такую функцию в MediaPro и даже тогда не особо понял зачем она нужна (карты там в отличие от Lightroom нету) т.к. особого разнообразия в этом плане у меня нет и систематизация не требуется.
А по мак-адресам имеется ввиду фильтрация трафика со стороны дата-центра: если я буду отправлять трафик через bridge, то в качестве mac-адреса источника будет стоять не тот mac который указан в ДЦ для сетевого интерфейса моего сервера, а mac-адрес виртуальной машины и весь трафик просто отбросится на стороне дата-центра.
Если рассматривать не конкретно этот случай, а случай локальной сети, то бридж откроет наружу всю локальную сеть, а не только один сервер который нужно открыть.
Потом моя задача усложнилась и стало нужно делать это:
1. Просто — для автоматизации
2. Надежно и понятно — без танцев вокруг iptables с разными вариантами того откуда пакет пришел
3. Сохранять IP для исходящего трафика, а не только принимать входящий
И пришло время изучить тему более подробно, применив тот объем фоновых знаний который уже накопился в процессе других экспериментов с маршрутизацией.
И найдя простое решение я решил упростить жизнь тем кто будет решать подобную задачу, но еще не имеет достаточного опыта для собственных экспериентов с маршрутами или не имеет времени на эти экспериенты.
Согласитель — когда задачу нужно решить «сейчас» никто не будет тратить несколько дней/недель на глубокое вникание в вопрос, а найдут инструкцию которая работает. В лучшем случае еще и «понятно работает». Инструкция с iptables хоть костыльна, но вполне понятна и на куче форумов рекомендуют именно её и почему-то не рекомендуют вариант правильной маршрутизации. Либо об этом мало кто знает, либо те кто знают уже не общаются на форумах, а просто знают и настраивают свои системы. Новичкам приходится использовать костыли.
Этой инструкцией в частности я предлагаю простой правильный путь массово предлагаемому костылю. Врядли это убивание ресурса.
По установке ubuntu инструкций много, но например если бы все поголовно инстркции сетевой установки рекомендовали скачать iso-образ по сети, нарезать на болванку и дальше ставить как обычно и называли бы это «сетевой» установкой потому что образ качается по сети то вполне имело бы смысл написать инструкцию про установку через pxe например для тех случаев, когда нарезание болванки неудобно.
Ну записал бы я себе это в локальный блокнот кому бы от этого лучше стало, кроме меня?
А так есть хороший шанс, что кто-то вместо костыля с iptables настроит себе правильную маршрутизацию.
Что же делать если такой простой вопрос как маршрутизация внешнего IP на сервер во внутренней сети часто решается таким грубым и популярным костылем как iptables и подмена адресов через него.
При этом по внутреннему адресу сервер продолжит быть доступным, при этом настройки на шлюзе остаются простыми вместо лапши из переписываний IP в iptables на все случаи жизни.
С другой стороны никто не мешает это сделать при необходимости.
В моем случае S1 это виртуальный сервер и если S0 сдохнет то к S1 я всё равно не попаду пока не подниму его на другом физическом сервере — а там он снова по публичному адресу будет доступен.
Да, действительно — нашел у них даже пример конфигов Centos Debian
Допишу в статью настройку для сервера через конфиги.
Статья же призвана решить конкретную практическую задачу, т.е. это просто разные вещи.
К тому же примеры именно про то что каждому ethernet-фрагменту соответствует своя подсеть IP-адресов — точно так же как во всех руководствах, учебниках и статьях которые я видел по IPv4 (в отличие от IPv6 где шлюз в другой подсети это норма). Поскольку везде приведены именно такие примеры, то иное поведение (шлюз с IP из другой сети) совершенно неочевидно.
Сравнение с iptables включено в статью специально — как раз чтобы показать что это более правильная альтернатива популярному костылю.
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-адресу.
К сожалению жаргон нигде не закреплен и каждый может понимать его немного по-своему, в частности я не нашел определения слова «проброс» в контекста нашего общения.
Впрочем по марштуризации внешнего IP во внутренюю сеть тоже.
Изучение RFC хорошо для понимания основ работы протокола, но к сожалению не дает представления об инструментах и практике применения.
Про учебники: к сожалению я не видел учебников, объясняющих подобные вещи. Подскажите мне — я с удовольствием почитаю.
Подскажите мне более толковую статью и путь которым я мог бы её найти решая свою задачу. Если они действительно есть и я не увидел чего-то очевидного — я извинюсь и удалю свою кашу.
Она возможно и базовая и те кто изучают маршрутизацию в вузах/курсах возможно это и изучают еще в начале. Однако по вопросу проброса IP-адреса я находил исключительно варианты с подменой адресов в iptables, поэтому с ним и сравниваю.
Посмотрите например yandex google
а статья как раз и призвана показать более правильный способ.
P.S. заголовок тоже поправил, чтобы по пробросу статья легко находилась.
Поясняю на примере из практики по которому статья и написана:
Есть сервер с публичным адресом 1.1.1.1
Кроме этого на сервере добавлен отказоустойчивый IP 1.2.3.4, который может перекидываться между серверами через API дата-центра. Это одиночный IP-адрес (не сеть адресов), у него нет макси и шлюза по умолчанию со стороны дата-центра.
Нужно назначить этот адрес на виртуальную машину внутри сервера таким образом, чтобы можно было быстро и удобно поднять копию этой виртуальной машины на другом физическом сервере.
При этом на сетевом интерфейсе виртуальной машины должен быть IP-адрес 1.2.3.4, т.к. внутри установлен софт который привязывается к IP-адресу и проверяет его как запросами во внешнюю сеть, так и по наличию адреса на интерфейсе с которого эти запросы в сеть уходят.
Попробуйте поискать инструкции про проброс внешнего IP-адреса к серверу из локальной сети, я много раз искал такие инструкции и всегда находил только тот или иной вариант настройки перенаправлений через iptables. При этом трафик ходит, но внешний IP-адрес на внутреннем сервере отсутствует (это для меня было основным в данном случае) + как оказалось вариант с маршрутизацией еще и настраивается проще.
Команда virt-install сразу не работает — она устанавливается из пакета python-virtinst
Вписал в описание LR добавку по этому поводу, в таблице считаю должны присуствовать обе цены.
Там еще вверху есть «How to buy» — там предлагается ТОЛЬКО подписка. Так что с точки зрения adobe это именно штатный способ получения LR, а постоянная покупка для относительно небольшой группы лиц которые знают что есть другой способ оплаты и его искать.
Это как раз та часть программы, которая мне особо не нужна. О том чтобы выделять города как-то отдельно, а не просто ключевыми словами мне и мысль в голову не приходила пока не увидел такую функцию в MediaPro и даже тогда не особо понял зачем она нужна (карты там в отличие от Lightroom нету) т.к. особого разнообразия в этом плане у меня нет и систематизация не требуется.