Комментарии 26
Рабочая схема. Я по такой схеме организовываю логику с разными облачными провайдерами, когда нужно быстро развернуть инфраструктуру для небольшого бизнеса с возможностью переезда офиса в любое время и в любое место и которым нужно всего пару серверов. Только, помнится, без лицензии Клод хостед имеет ограничение в 1Mbps на интерфейс, а не 100. Также, иногда, некоторые провайдеры блочат трафик в туннелях, если не шифровать, и иногда приходится просить открыть gre. Не знаю, почему хостеры жёсткие такие бывают. :)
Так. Два замечания. Первое. Выше коллега отписался. Ограничение бесплатного Chr не 100мбит, а всего лишь 1 мбит.
Второе. Чего с отказоустойчивость шлюза? Ну, ляжет AZ с микротом. Дальше что?
Первое поправил, по второму можно доп. развернуть ВМ в зоне доступности b или c, настроить правила и если ляжет зона a переключить на b или c, правда внешние ip изменятся и это самое неприятное, т.е. нужно будет переписывать все внешние сервисы которые должны к нам ходить, еще проблема в самом хостинге, внешний ip выдается для каждой зоны доступности свой и к тому-же они не повторяются, т.е. если случайно удалили внешний статический ip, а потом снова добавили, то он уже будет другим. Так что отказоустойчивость под вопросом.
При данных правилах маскарада, у вас и внутренний трафик между подсетями будет маскарадиться, а это часто приводит к нежелаемым эффектам.
Каких-то особых проблем нет, только в статье забыл добавить в route rules первый маршрут по умолчанию, что-бы не было принудительного перенаправления, поправил.
Проблему будут если у вас в одной подсети сервис, а в другой клиент, который к нему обращается и при этом вам нужно будет знать его локальный ип. Вместо этого вы будете видеть всегда ип роутера.
да как бы нет с этим проблем
ping rc1a-XXX.mdb.yandexcloud.net
Pinging rc1a-XXX.mdb.yandexcloud.net [172.16.0.32] with 32 bytes of data:
Reply from 172.16.0.32: bytes=32 time=5ms TTL=61
..........
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
.........винда в одной VPC, зоне доступности и подсети, а managment pgsql в другой зоне, подсети и VPC
Что-бы все подсети видели друг друга, было добавлено вот это правило
/ip route rule
add src-address=10.1.0.0/16 dst-address=10.1.0.0/16 action=lookup-only-in-table table=mainесли его не сделать первым в таблице, то да все рухнет ...
И еще один момент, чтобы хосты внутренних подсетей не определялись как ip роутера ставим первым правилом snat подсетей которые мы связываем
Знаете, для человека, который знает сети от А до Я, Ваше решение не выглядит сложным и даже выглядит скорее логичным. Но объяснить обычному разработчику… Сложновато будет ) Ну, и я все-таки еще раз повторюсь, что с nginx было бы лучше ))))
маршруты между подсетями (разграничить prod и stage)
а это вообще должно решаться на уровне сетей самого Яндекса и их политик
Я так понял — выход в интернет с фиксированного айпи, а не с внешнего адреса виртуалки. Нужно для всяких поставщиков АПИ, у которых есть «белый список» по айпи
Double_W
Бесплатная идея. Если действительно нужна эта история с фильтром адресов, то проще настроить nginx на одном из серверов, в качестве бекендов указать сервер поставщика АПИ и тупо прокси пасс, а у себя в качестве сервера назначения указать свой nginx. Profit!!!
Теоретически такую схему можно отмасштабировать не только на http, но и на udp/tcp стримы. И что самое приятное — никаких побочных эффектов вроде наличия микротика
В вашем случае достаточно dstnat.
В вашем случае достаточно dstnat.
add chain=dstnat ...
без netmap порты на хост не перекидываются
Там написано чем отличается:
Port Forwarding(ваш случай): chain=dstnat… action=dst-nat
Network Mapping(совершенно не ваш случай): натится сеть в сеть
ЗЫ с netmap можно поиметь незабываемое в последствии «веселье»
Вы абсолютно правы, но мне казалось, что на практике netmap как правило позволяет попросту сэкономить на количестве правил dst-nat. Возможно, Вы знаете какие-то еще отличия (может netmap меньше грузит процессор?)
И дает лишний оверхед по ресурсам в отличии от dst-nat, плюс при неумелом обращении может дать весёленький доступ в сеть за натом.
Network Maping применяется в случае когда вам нужно получить доступ в сеть удаленного офиса, у которого такая же сеть как у вашего например:
Офис1: 192.168.88.0/24
Офис2: 192.168.88.0/24
Согласен
chain=dstnat… action=dst-natэта схема тоже рабочая
Очень долго мучился с доступностью хостов за CHR в сети YandexCloud. Добавление всего одного маршрута в Virtual Private Cloud решило двухдневную головную боль!
Поправьте только
«Virtual Private Cloud -> Облачные сети -> в каждой Подсети выключаем NAT в интернет -> Таблицы маршрутизации -> Создать, если создано изменить -> добавляем маршрут Префикс назначения: 0.0.0.0/0, Next hop:
в вашем случае 10.1.0.254/10.1.1.254
Яндекс облако и MikroTik MultiWAN