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

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

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

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

Публикации

Истории