Путь к реализации Edge DNS и получению IP-адресов Anycast — route64.org
Привет, я Munou.
Я пытаюсь создать Edge DNS и CDN.
Текущая ситуация
Это псевдо-распределение.
Регистрация pool.soulminingrig.com в качестве CNAME для edge.soulminingrig.com была сделана для распределения... но на данный момент это бессмысленно.
$dig www.soulminingrig.com AAAA +short
edge.soulminingrig.com.
pool.soulminingrig.com.
2400:8500:2002:3317:163:44:113:145
2a11:6c7:f07:156::2$dig www.soulminingrig.com A +short
edge.soulminingrig.com.
pool.soulminingrig.com.
163.44.113.145
91.98.169.80Почему-то контент все равно доставляется с ближайшего сервера
В случае с HTTP это происходит благодаря стороне клиента, и что удивительно, HTTP-клиенты фактически настроены так, чтобы достигать ближайшего сервера. Я не знаю, распределяет ли это DNS-сервер должным образом. Я не уверен, заслуга ли это ConoHa DNS, так как нет информации о подробных спецификациях.
С сервера в Германии
IPv6:
# curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:36:56.631373 [0-x] == Info: [READ] client_reset, clear readers
01:36:57.350639 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:36:57.350725 [0-0] == Info: IPv6: 2a11:6c7:f07:156::2, 2400:8500:2002:3317:163:44:113:145
01:36:57.350801 [0-0] == Info: IPv4: (none)
01:36:57.350916 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:36:57.350949 [0-0] == Info: [HTTPS-CONNECT] added
01:36:57.350980 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:36:57.351107 [0-0] == Info: Trying [2a11:6c7:f07:156::2]:443...
01:36:57.351308 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:36:57.351344 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0IPv4:
# curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:38:31.901521 [0-x] == Info: [READ] client_reset, clear readers
01:38:32.847878 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:38:32.847999 [0-0] == Info: IPv6: (none)
01:38:32.848050 [0-0] == Info: IPv4: 91.98.169.80, 163.44.113.145
01:38:32.848139 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:38:32.848251 [0-0] == Info: [HTTPS-CONNECT] added
01:38:32.848315 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:38:32.848440 [0-0] == Info: Trying 91.98.169.80:443...
01:38:32.848657 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:38:32.848723 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0Из домашней сети
IPv6:
$curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:39:23.182757 [0-x] * [READ] client_reset, clear readers
01:39:23.227731 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:39:23.227855 [0-0] * IPv6: 2400:8500:2002:3317:163:44:113:145, 2a11:6c7:f07:156::2
01:39:23.227996 [0-0] * IPv4: (none)
01:39:23.228072 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:39:23.228171 [0-0] * [HTTPS-CONNECT] added
01:39:23.228253 [0-0] * [HTTPS-CONNECT] connect, init
01:39:23.228369 [0-0] * Trying [2400:8500:2002:3317:163:44:113:145]:443...
01:39:23.228605 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:39:23.228711 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0IPv4:
$curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head
01:40:52.285758 [0-x] * [READ] client_reset, clear readers
01:40:52.316059 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:40:52.316177 [0-0] * IPv6: (none)
01:40:52.316239 [0-0] * IPv4: 163.44.113.145, 91.98.169.80
01:40:52.316340 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:40:52.316440 [0-0] * [HTTPS-CONNECT] added
01:40:52.316522 [0-0] * [HTTPS-CONNECT] connect, init
01:40:52.316638 [0-0] * Trying 163.44.113.145:443...
01:40:52.316822 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:40:52.316929 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0Сколько бы раз я ни пробовал, я всегда попадаю на один и тот же ближайший IP. Потрясающе.
Возможно, сама ConoHa DNS устроена так, что она доставляет контент с ближайшего IP-адреса, иначе система бы не работала.
$dig a.conoha-dns.com +short
157.7.32.89
$dig b.conoha-dns.org +short
157.7.33.89
Если настроены основной и вторичный DNS-серверы ConoHa, и a.conoha-dns.com выходит из строя, нет смысла, если запрос не перенаправляется на b.conoha-dns.org. Я как-то не задумывался об этом раньше, но, скорее всего, если на стороне клиента один DNS-сервер недоступен, он должен уметь переключаться на рабочий, иначе в основном и вторичном серверах нет смысла.
Хорошо продумано... Это означает, что даже если зарегистрировано несколько A-записей, это в некотором смысле работает.
Тем не менее, хочется еще большего распределения
На самом деле, этого уже достаточно, но если бы можно было распределить еще больше, можно было бы создать собственную распределенную DNS или CDN. В текущей ситуации, если кэш-серверы в двух точках выйдут из строя, связь прервется.
Наверное, это довольно жестко, если подумать о том, что крупные облачные провайдеры вложили огромные средства и инфраструктуру в создание таких распределенных систем.
Размышления о простом распределении
Если цель — избежать единой точки отказа, можно вещать из нескольких точек с помощью IP Anycast, используя один и тот же IP-адрес. Однако обязательным условием является настройка BGP, что для частного лица является высоким барьером:
Получение ASN
Получение значений подсети, необходимых для настройки BGP
Не думаю, что частному лицу легко справиться с расходами и процедурами для обоих пунктов.
То есть, если пропустить это и просто получить IP Anycast или сам IP-адрес, проблем не будет.
Однако использование IP-адресов, принадлежащих третьим лицам, в плане манер считается неприемлемым.
route64.org
Я нашел это.
Похоже, это некоммерческая организация, занимающаяся популяризацией IPv6.
Хотя я не изучил всё до конца, бесплатно доступен, по сути, только IPv6 Tunnel, а остальное работает по системе баллов, которые можно получить за пожертвования. С помощью этих баллов можно использовать BGP или полностью управляемые сервисы IP Anycast.
Даже если это стоит денег, удивительно, что можно получить Anycast-адрес всего за несколько долларов. Кстати, похоже, есть ограничения по пропускной способности, так что на это стоит обратить внимание.
Поскольку это всего лишь туннель, владеть им нельзя.
Было трудно, так как в русскоязычном сегменте об этом никто не писал.
Я как раз хотел добавить IPv6 к серверу Hetzner с IPv4, поэтому решил попробовать. Кстати, добавление IPv6-адреса к серверу Hetzner с IPv4 стоит дополнительно 1 доллар в месяц. Я подумал: «Брать деньги за IPv6-адрес?..» и рад, что не стал его подключать там.
На самом деле, это IPv6 Tunnel, поэтому здесь нужно быть внимательным.
Что удобно, так это использование в качестве ретранслятора для VPS с ужасными задержками. Если выпустить этот IPv6-адрес и использовать его как промежуточное звено между SSH-клиентом и SSH-сервером через route64, становится довольно комфортно.
Пробуем использовать IPv6 Tunnel
Ниже выберите «add tunnelbroker»
Затем выберите метод туннелирования
Я выбрал WireGuard, так как это просто и он уже был установлен на сервере.
Теперь добавьте IPv4-адрес сервера, которому вы хотите присвоить IPv6.
То есть это настройка на стороне клиента WireGuard.
В моем случае это 91.98.169.80.
После этого будет выдан файл конфигурации WireGuard, и останется только выполнить wg-quick up conf-file.
Да, как некоторые могли заметить, второй IPv6-адрес в записи AAAA этого блога — это адрес, полученный таким способом.
Сервис Anycast возможен и для IPv4
Я думал, судя по названию сервиса, что он только для IPv6, но, оказывается, Anycast-адреса поддерживают и IPv4. Потрясающе.
В общем, в ближайшее время я попробую получить Anycast-адрес.
Кроме того, я не оставил надежд на получение подсети IPv4, так что мне понадобится время на исследование способов поддержания её с минимально возможными затратами.