Как стать автором
Обновить

Комментарии 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)

а это вообще должно решаться на уровне сетей самого Яндекса и их политик

Зачем объяснять? СБ сказали мы сделали))


а это вообще должно решаться на уровне сетей самого Яндекса и их политик

на момент написания статьи группа безопасности VPC находилась в стадии Preview

СБ? Служба безопасности ?

да, она самая)

НЛО прилетело и опубликовало эту надпись здесь

Я так понял — выход в интернет с фиксированного айпи, а не с внешнего адреса виртуалки. Нужно для всяких поставщиков АПИ, у которых есть «белый список» по айпи

Double_W
Бесплатная идея. Если действительно нужна эта история с фильтром адресов, то проще настроить nginx на одном из серверов, в качестве бекендов указать сервер поставщика АПИ и тупо прокси пасс, а у себя в качестве сервера назначения указать свой nginx. Profit!!!


Теоретически такую схему можно отмасштабировать не только на http, но и на udp/tcp стримы. И что самое приятное — никаких побочных эффектов вроде наличия микротика

Думал про апстрим nginx, но нужно было централизованное управление входящим и исходящим трафиком всех подсетей + маршруты между подсетями (разграничить prod и stage)

Спасибо за замечание, добавил схематично как в данном облаке выглядит выход в интернет.
Почему вы так бездумно используете netmap, он совсем не для проброса портов, а сеть в сеть, прочитайте про netmap.
В вашем случае достаточно dstnat.
В вашем случае достаточно dstnat.

add chain=dstnat ...


без netmap порты на хост не перекидываются

Прочтите доку по приведенной мной ссылке, это офицальная wiki mikrotik.
Там написано чем отличается:
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
Отличная статья!
Очень долго мучился с доступностью хостов за CHR в сети YandexCloud. Добавление всего одного маршрута в Virtual Private Cloud решило двухдневную головную боль!

Поправьте только

«Virtual Private Cloud -> Облачные сети -> в каждой Подсети выключаем NAT в интернет -> Таблицы маршрутизации -> Создать, если создано изменить -> добавляем маршрут Префикс назначения: 0.0.0.0/0, Next hop: 10.1.0.1/10.1.1.1 внутренний адрес интерфейса Mikrotik CHR»
в вашем случае 10.1.0.254/10.1.1.254

Спасибо, мил человек) поправил опечатку.
Рад что помог мануалом.
Но это еще цветочки, буквально за считаные месяцы микротик обрастает огромным количеством правил))
Не забываем делать бэкапы)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории