Помогите выбрать подход к организации доступа по имени вне зависимости от провайдера/ip.

Могу посоветовать посмотреть в сторону https://wiki.mikrotik.com/wiki/Manual:IP/Cloud.

Пропишите вместо A записей в DNS CNAME.

Как-то пугает «Currently running as public beta. Server availability could vary, and syntax could change»

Мне бы надо что-то устоявшееся и стабильное. Amazon с его AWS и т.п. вызывает доверие. Доступность сервисов для нас очень критична.

Amazon с его AWS и т.п. вызывает доверие.

Прочитал наискосок, но не увидел что бы они проксировали весь трафик.

Доступность сервисов для нас очень критична.

Тогда купите себе ASку и анонсируйтесь через работающий канал, как все нормальные люди, а не занимайтесь облакодрочерством.

А если не хотите делать по-людски, то значит доступность вам нифига не критична. пользуйте какой-нибудь dyndns и не компостируйте людям мозги.

Тут два варианта:
1. внешний балансировщик который будет перенаправлять в зависимости от доступности
Минус: единая точка отказа
Плюс: в независимости от dns кэша на конечном оборудовании пользователя, работать будет.
2. внешние dns с ttl 60 и в случае падения/подьема меняем записи (что скорее всего у амазона и сделано)
Минус: на конечном оборудовании пользователя может быть закешированна запись и плевать что TTL 60

PS Я конечно не знаю всех ваших задач, но в зависимости от того что это за vpn и задач, подключаться к нему по имени не всегда самая лучшая идея.

Тогда купите себе ASку и анонсируйтесь через работающий канал

Точно, вот это еще забыл :(

Зачем нам проксировать весь трафик? Нам нужно мониторить доступность по одному ip и если сервер становится недоступен, то менять его ip на второй, который соответствует нашему второму провайдеру и мониторить там. При появлении пинга на первом, переключать обратно.

Нам больше подходит вариант номер 2, а Амазоновский сервис это то, что нагуглилось и вызвало доверие, но опыта работы с ними нет. Может с чем-то другим связывались? Поделитесь.

На *.company.com крутится несколько web серверов и они должны быть доступны по имени (внутри всякие nginx и apache по url перенаправляют на соответствующий сервер).

Доступность критична, но покупать под это дело ещё один аппарат не вижу смысла, если просто нужно менять запись dns при пропадении пинга и т.п. и потом менять назад. Перебой в 60 секунд для нас всё же вполне приемлим.

Доступность критична, но покупать под это дело ещё один аппарат не вижу смысла

Какой ещё аппарат? Зачем аппарат? Микротик легко справится, ему ж не надо full-view держать. В гугль, читать что такое AS, анонсирование, BGP и т.д.

если просто нужно менять запись dns при пропадении пинга и т.п. и потом менять назад. Перебой в 60 секунд для нас всё же вполне приемлим.

Сменой dns никаких 60 секунд не получится. До суток, в зависимости от настроек кэшей провайдеров через которые ваши клиенты работают.

Какой ещё аппарат? Зачем аппарат? Микротик легко справится, ему ж не надо full-view держать. В гугль, читать что такое AS, анонсирование, BGP и т.д.

Можно подумать, AS — это так, копеешное дело.

Самый простой вариант — таки получить хоть какой-нибудь резерв с убогими и дорогими каналами до обоих провайдеров, а на сайте редиректить на www1/www2 уже на рабочий толстый канал, но dns таки тоже менять.

Можно подумать, AS — это так, копеешное дело.

Минимальный размер блока уже давно отменили почти все. Можно хоть /32 взять. Так что копеешное.

Ну и если доступность действительно критична, то не стоит экономить на ней. А если жалко потратить смешную для любой конторы сумму на AS, то значит нихрена ничего не критично, и ТСу более чем достаточно банального dyndns.

Сменой dns никаких 60 секунд не получится. До суток, в зависимости от настроек кэшей провайдеров через которые ваши клиенты работают.

Отвечу с конца.

в зависимости от настроек кэшей провайдеров через которые ваши клиенты работают

Пров который плюет на TTL идет лесом. Так что это скорее исключения из правил, но которые как не странно тоже бывают.

Сменой dns никаких 60 секунд не получится.

А вот это верно, сами клиентские ОС кэшируют. Причем не только ОС но и приложения в частности (либо ОС за них кэширует я хз), во всяком случае на винде это очень хорошо заметно.
Вспомнился совсем эпичный баг от винды, это была еще 2к (но не факт что он не унаследован следующими поколениями) внезапно через полгода после смены ip одного сервера, она откуда-то вспомнила старый адрес, с этим сервером я работал каждый день, и тут фигаг недоступен, после ребута больше не вспоминала.

Минимальный размер блока уже давно отменили почти все. Можно хоть /32 взять.

Это где AS с /32?

Пров который плюет на TTL идет лесом. Так что это скорее исключения из правил, но которые как не странно тоже бывают.

Ну ставить на домене TTL в 60 секунд это моветон, на самом деле, оно, собственно, препятствует кэшированию, ради которого и ставится DNS-кэш. Поэтому какой-нибудь min-cache-ttl легко могут поставить в полчаса или около. Работе обычных DNS-записей это не повредит.

Кроме того, кэшировать DNS-запросы даже локальный роутер может, если там какой-нибудь DNS-кэш поднят.

Это где AS с /32?

AS - вообще никак с блоком не связана. Можно иметь AS и не иметь блока. 100 евров за регистрацию платишь и всё, у тебя есть ASN навсегда.

А минимальный размер блока, как PI, так и PA большинство NIC'ов отменили ещё когда в первый раз IPv4 кончились. Чтобы владельцы блоков могли в аренду раздавать куски своих сеток и так частично решить проблему окончания IPv4.

Так что если договориться с арендатором, то можно и /32 выпросить (не знаю, правда, cумеет ли, например, конкретный bgpd из зебры анонсировать /32 или нет, но технически никаких проблем нету) - теперь административных препятствий к этому нет. :)

Ну так в том то и оно, не на стену же вешать ASN.

Есть стандарт который надо соблюдать, а так да, каждый волен менять настройки. Вообще говоря ведь основная нагрузка ляжет не на провов клиентов, а на сервер отвечающий за зону, это ведь его долбить будут.

Ну так в том то и оно, не на стену же вешать ASN.

Ну заводишь ASN и арендуешь PI /32. Административно - никаких проблем, технически, возможно придётся договариваться с арендатором насчёт агрегирования. Я давно в full-view не заглядывал, возможно там уже полно такого, /30 уже пару лет назад точно попадались.

Вообще говоря ведь основная нагрузка ляжет не на провов клиентов, а на сервер отвечающий за зону, это ведь его долбить будут.

И на кэш тоже. Это ведь ему придётся постоянно лазать на сервер отвечающий за зону, а не клиенту.

Я же написал «не на провов клиентов». Да им тоже лазить, но одно дело когда это один, два клиента с запросами и другое на самом сервере где прилетает тысячами со всего мира. Вообще говоря о чем мы спорим? емнип dyndns так и работает и вроде шума про нагрузку не особо слышно. Да и все равно похоже и вы и я уверены, что ttl не гарантирует тех 60, так что полагаться на это нельзя.

Вы точно с IPv6 для /32 не путаете? Покажите любой URL где проанонсят IPv4 /32.

Вы точно с IPv6 для /32 не путаете? Покажите любой URL где проанонсят IPv4 /32.

Какой ещё URL? При чём тут URL? Вебдваноль головного мозга, что-ли?

В full-view загляни. Наверняка там уже есть.

Какой ещё URL? При чём тут URL? Вебдваноль головного мозга, что-ли? Наверняка там уже есть.

Ну то есть сами не продаёте, указать кто продаёт/даёт в аренду /32 для анонса не можете, сами не видели. Зато как хамить — так завсегда пожалста...

Выдачу PI отменили в 2012. Размер сети для анонса IPv4 постепенно снизили до /24.

Ну то есть сами не продаёте, указать кто продаёт/даёт в аренду /32 для анонса не можете, сами не видели.

Ну продать - это вряд-ли. аренду PA /32 с анонсом через несколько линков технически могу организовать, если все испольуемые линки адекватные, но это такие копейки, что возиться с этим мне просто лень.

Зато как хамить — так завсегда пожалста...

Это интернет, детка.... На хамство получишь только хамство. Ибо пытаться развести меня на выполнение работ по поиску и переговорам с каким-нибудь LIR на предмет аренды и организации PI /32 или там анонсов PA /32 через несколько аплинков - натуральное неприкрытое хамство.

Выдачу PI отменили в 2012. Размер сети для анонса IPv4 постепенно снизили до /24.

То, что адреса в какой-то момент закончились, вовсе не значит, что их больше никогда не будет. В ~2014 получили /19 без проблем. Лимиты на размеры сетей остались вроде бы только у LAPNIC. Все остальные их давно отменили.

Размер сети для анонса IPv4 постепенно снизили до /24.

И чтобы ты выглядел совсем обосравшимся, на тебе, чисто для прикола поискал текущие мелкие PI:

whois 193.58.0.48
whois 193.188.134.128

Ничо, что по 8 айпишничков, а не по одному?

Так что вылезай из криокамеры и перестань гнать пургу про /24

И чо?

Тебе с ASкой надо? На тебе с ASкой, если ты настолько туп, что не способен сам найти: 193.188.134.120/29 AS28854

AS-ка понадобится только если провайдер изменится. Пока пров один - можно не заморачиваться и слать ему анонсы приватно, а он сагрегирует, например. Понадобится ASка - её за полчаса можно сделать. Блок-то всё равно твой.

Тебе с ASкой надо?

Мне лично не надо. Это вы тут срёте, пытаясь доказать, что сейчас, а не 10 лет назад для ваших примеров сетей можно при сегодняшнем размере fullview возмуться маршрутизировать мелкую сетку вашей AS, если она не принадлежит этому провайдеру.

Могу предположить, что может помочь связка триггер, ослеживающий, какой канал работает, если один из них упал, + DynDNS.

Мне лично не надо. Это вы тут срёте, пытаясь доказать, что сейчас, а не 10 лет назад для ваших примеров сетей можно при сегодняшнем размере fullview возмуться маршрутизировать мелкую сетку вашей AS, если она не принадлежит этому провайдеру.

Чисто для прикола сегодня пообщался на эту тему со своими. На самом деле дела обстоят таким образом: Получить PI меньше /24 - можно. Даже среди наших клиентов нашлась /25 Анонсировать через провов в европах там или ещё в каких нормальных местах - не проблема. Анонсировать в РФ через нормальных провов - тоже не проблема (через нас - можно, например). Проблема возникает если другой пров (даже транзитный, с которым нет прямых отношений) - урод, и свои древние сраные циски, которые не могут в нынешний full-view не заменил на что-то более приличное. Эти уроды тупо режут всё меньше /24. На М-IX/M-X таких засранцев полно, например. Формально, это аццкое нарушение, однако, с каким-нибудь ростелекомом никакой RIPE ничего сделать не может.

Размер full-view здесь только при том, что когда-то очень давно дебилоиды из циски решили, что «640кб хватит всем» и впарили свои игрушки лошкам из РФ, где даже такому говну были рады. И вот до сих пор, эти древние циски, которые невозможно проапгрейдить работают в точках обмена трафиком. Кстати, с IPv6 всё вообще плохо по той же причине. А на новое железо большие провы тратится не хотят - крымнаш, импортозамещение, дача на Канарах и всё такое.

В общем, те, кто режет маленькие сети IPv4 ссылаясь на размер full-view - банальные жадные ублюдки. Про IPv6 вообще молчу, оно растёт даже быстрее IPv4, а памяти побольше занимает.

Для нормальных людей размер full-view никакой проблемы не представляет, и в нормальное железо ещё сотня таких full-view влезет без особых проблем. И блок PI в несколько адресов вполне будет работать.

Скажу сразу, я не против того что вы написали! Но в продолжение, давайте посмотрим что происходит с v6, полная фигня в части меньше /64 ибо «считается» «хватит всем».

С IPv6 ещё вот какая жопа - большое количество оборудования как у конечных, так и у магистральных провов тупо не умеет / не хочет / аццки глючит при IPv6. А менять оборудование - всех жаба давит, по разным причинам, в том числе и из-за малой востребованности IPv6 т.к. чтобы оно взлетело, надо чтоб оно заработало у всех, а не только у тебя. И ещё всякие причины - вот мы, например, хотели купить всемогутную циску/джунипер/алкатель вместо старья, и наконец дать абонентам IPv6 хоть как-то, пусть оно даже на M-IX потеряется наполовину, но хоть европа будет, а теперь хер там - всё бабло уйдёт на новые яровые сормы и прочую дебильную россиянскую хероту, ещё и в долги залезем.