sitelogo

By

Боремся с NAT с помощью Teredo и CloudFlare

Как известно, адреса в глобальной сети IPv4 закончились еще в далёком 2012-м. И не смотря ни на что, старый стандарт еще никуда не делся и продолжает повсеместно использоваться. Не многих этот вопрос интересует: провайдеры интернета не спешат тратиться на новое железо и перекрывать себе поток выручки с продажи белых IP адресов, пользователи исправно платят и имеют доступ к контактикам, ютубу и почте. Тем не менее, не у всех пользование интернетом сводится к посиделкам вконтакте и чтению почты. Иногда необходимо, например, контролировать какую-либо машину извне, например, по SSH. Так как теперь уже повсеместно используется технология NAT, а услуга выделения белого адреса иногда даже не предоставляется, приходится находить всякие ухищрения, чтобы обойти систему. Прошло то время, когда провайдеры выдавали динамический белый адрес при очередной интернет-сессии, и было достаточно зарегистрироваться где-нибудь на no-ip.org.

Стоит рассказать, как дела идут у разработчиков программного обеспечения. Хороший пример — VoIP телефония, в частности SIP, H.323 протоколы. Особенностями работы таких приложений (VoIP софт-клиенты) является не слишком чёткое соответствие клиент-серверной модели. Наличие сервера-координатора для регистрации SIP сессий недостаточно для функционирования данного типа программ. Кроме регистрации на сервере сессий, необходима также и прямая передача голосового и видеотраффика между клиентами. Каким же образом клиенты будут находить и адресовать друг друга, когда все они теперь находятся за стеной NAT’ов?

Оба протокола (SIP & H.323) разрабатывались еще в те времена, когда адресов было много, и о проблеме NAT’ов еще не сильно задумывались (умные дяди из мегакорпораций что-нибудь придумают?). Теперь же, когда софт написан, деньги заплачены, оказывается, что SIP с его установлением потоков по SDP, фундаментально не слишком приспособлен к работе в современном интернете. Были написаны кипы бумаг RFC, разработаны соответствующие протоколы STUN и т.д., но софт что-то продолжает работать из рук вон плохо. SIP\H.323 создают большое количество интернет-соединений, но не факт, что все они успешно пройдут через стены фаерволов\NAT и не будут блокированы. Контроль ошибок в SDP не слишком хорошо организован (а есть ли вообще?), поэтому пользователь в случае блокировки просто не будет слышать своего собеседника и лишь строить догадки о причинах. Такие ситуации встречаются сплошь и рядом. Я сам на данный момент работаю в компании, занимающейся поддержкой VoIP клиентов, мне всё это знакомо. В гораздо лучшей ситуации оказался Skype, так как он имеет другую, децентрализованную архитектуру с одним единственным соединением, о которой в своё время писали серьезные люди, вроде Криса Касперски.

А еще появился новый модный термин «Интернет вещей». Какой же от него толк, если вещи не могут найти друг друга в этом самом интернете? В общем, нужна интернет-революция, создание транспортного протокола и системы адресации, которая смогла бы работать поверх уже существующей сети. А пока имеется лишь IPv6, и различные способы адаптации к нему, используя старые каналы IPv4 провайдера. Например, Teredo и туннельные брокеры. Первый хорош тем, что абсолютно бесплатен, не требует регистрации, не пропускает весь трафик через какие-либо серверы (только маршрутизирует), и в Linux устанавливается одной командой. Второй — тем, что предоставляет постоянный IPv6 адрес, не требуя написания никаких скриптов для обновления адреса домена по аналогии с no-ip.org, а также может работать и через симметричные NAT’ы.

Если про второй вариант уже написана хорошая статья http://habrahabr.ru/post/185886/, то здесь я хочу прояснить, как можно провернуть подобную технику с Teredo. Разница только в том, что необходимо написать скрипт, который будет обновлять адрес на сервисе CloudFlare для записи DNS. Teredo работает через большинство типов NAT’ов. Различные restricted и симметричные NAT’ы специально предназначены для недопускания попадания внешнего траффика во внутреннюю сеть подобно фаерволу, поэтому используются в основном для защиты корпоративных сетей, а не крупными интернет-провайдерами (я надеюсь). Если требуется провернуть туннель через корпоративную сеть с симметричным NAT, зарегистрируйтесь и используйте брокера.

Итак, устанавливаем поддержку Teredo на оба компа:

1
:~$ apt-get install miredo

Всё. Теперь смотрим, появился ли новый интерфейс teredo командой ifconfig. Пробуем друг друга пропинговать:

1
2
3
4
5
6
:~$ ping6 2001:0:53aa:64c:4a2:cf51:2aa8:7926
PING 2001:0:53aa:64c:4a2:cf51:2aa8:7926(2001:0:53aa:64c:4a2:cf51:2aa8:7926) 56 data bytes
64 bytes from 2001:0:53aa:64c:4a2:cf51:2aa8:7926: icmp_seq=1 ttl=64 time=0.103 ms
64 bytes from 2001:0:53aa:64c:4a2:cf51:2aa8:7926: icmp_seq=2 ttl=64 time=0.159 ms
64 bytes from 2001:0:53aa:64c:4a2:cf51:2aa8:7926: icmp_seq=3 ttl=64 time=0.172 ms
^C

Для того, чтобы побороть динамический IPv6 сервиса Teredo, нужно использовать динамический DNS. У сервиса CloudFlare эта опция работает, правда, необходимо делегировать самостоятельно купленный домен второго уровня. Делегируем его, указывая NS серверы CloudFlare у своего хостера, добавляем сайт в аккаунте CloudFlare. После того, как всё прошло успешно, нужно создать записи типа AAAA. Да простит меня автор, но я пожалуй сопру его скриншот, вместо того, чтобы делать новый:

ec98ce3ad5bd081163e15df43b09ed85

Вообще, для наших целей хватит добавления лишь одной строчки:

1
somehost AAAA 2001:0:53aa:64c:30b6:c232:2aa8:76bb

Такая строчка в итоге будет преобразована в somehost.v1ron.ru, если бы я добавил её для своего сайта.

После выжидания суток, когда DNS обновятся (либо прописав в /etc/hosts), можно заняться автоматическим обновлением NS серверов для нашего субдомена. У меня есть скриптик на Perl для этого:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#!/usr/bin/perl
 
my $ip;
my $nip;
 
sub getmyipv6 {
	my $ifconfig = `ifconfig teredo 2>/dev/null`;
	$ifconfig =~ m/inet6 addr: (.*)\/\d\d Scope:Global/;
	return $1;
}
 
$ip = "";
for(;;) {
	$nip = getmyipv6();
	if (($nip ne $ip) && ($nip ne "")) {
 		my $date = `date`;
 		chomp $date;
		print "$date: New Teredo IPV6 is $nip, updating CloudFlare...\n";
 		$ip = $nip;
    		!system "curl https://www.cloudflare.com/api_json.html " .
			"-d 'a=rec_edit' " .
			"-d 'tkn=...' " .
			"-d 'email=...' " .
			"-d 'id=...' " .
			"-d 'z=v1ron.ru' " .
			"-d 'type=AAAA' " .
			"-d 'name=nnpc' " .
			"-d 'content=$nip' " .
			"-d 'service_mode=1' " .
			"-d 'ttl=1' " .
			">/dev/null 2>/dev/null"
			or print STDERR "Unable to exec CURL\n";
	}
  	sleep 1;
}

https://www.cloudflare.com/docs/client-api.html

Параметры для запроса к API выше:
1. a: Команда. rec_edit значит редактировать запись.
2. tkn: API ключ, который можно получить на странице аккаунта CloudFlare.
3. e-mail: имейл, которым логинимся на CloudFlare.
4. id: Идентификатор записи, который нужно получить другим запросом к API (см. ниже).
5. z: основной домен для сайта, который добавлен в CloudFlare.
6. type: тип DNS записи. AAAA это IPv6 адрес хоста.
7. name: имя хоста, в данном случае имя субдомена.
8. content: значение для поля, в данном случае текстовый IPv6 адрес.
9. service_mode: если 1, траффик идет через прокси CloudFlare, если 0, то трафик идет минуя их прокси. Внимание, если трафик идет через прокси, то по SSH законнектиться мы не сможем, только HTTP.
10. ttl: как часто кеширующие DNS серверы должны обновлять информацию этой записи, 1 означает автоматическое определение.

Делаем запрос для определения ID записи:

1
2
3
4
5
:~$ curl https://www.cloudflare.com/api_json.html \
  -d 'a=rec_load_all' \
  -d 'tkn=8afbe6dea02407989af4dd4c97bb6e25' \
  -d 'email=sample@example.com' \
  -d 'z=example.com'

В куче текста придется найти этот ID.

В общем-то всё, после того, как поместили скрипт в автозагрузку в /etc/rc.local и убедились, что хост пингуется, можно коннектиться на комп напрямую через ssh:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
:~$ rsync --compress --recursive --partial --progress --rsh=ssh "root@murompc.v1ron.ru:/usr/src" .
root@murompc.v1ron.ru's password: 
receiving incremental file list
src/DS_WM8505_071.pdf.gz
      1,527,615 100%   28.57MB/s    0:00:00 (xfr#1, ir-chk=1010/1012)
src/vorbis-tools-1.4.0-ignorelength.tar.xz
        899,380 100%   11.75MB/s    0:00:00 (xfr#2, ir-chk=1009/1012)
src/vorbis-tools_1.4.0_ignorelength_fix.patch
            577 100%    7.51kB/s    0:00:00 (xfr#3, ir-chk=1008/1012)
src/linux-headers-3.10.1/.config
        131,560 100%   20.91MB/s    0:00:00 (xfr#4, ir-chk=1037/1050)
src/linux-headers-3.10.1/.config.old
        131,193 100%    9.62MB/s    0:00:00 (xfr#5, ir-chk=1036/1050)
src/linux-headers-3.10.1/Kconfig
            252 100%   15.38kB/s    0:00:00 (xfr#6, ir-chk=1035/1050)
...

Задача выполнена, каждый раз, когда комп выйдет в интернет через Teredo, DNS записи обновятся и мы тут же сможем соединяться, используя домен третьего уровня. После переподключения интернета всё восстановится автоматически. Командой выше я копирую тестовый файл со своей машины далеко от меня, используя шифрованный канал SSH. Обе машины выходят с помощью 3G модемов, без выделенных IP адресов.

Чтобы захостить сайт, потребуется интересная бесплатная услуга от CloudFlare, которая маршрутизирует запросы из IPv4 сети в сеть IPv6, на которой у нас настроен хостинг. К сожалению, в случае с CloudFlare будет возможна лишь маршрутизация HTTP протокола.

Не забудьте, что для того, чтобы зайти на IPv6 сайт по его адресу, адрес указывается в квадратных скобках: http://[2001:0:53aa:64c:4a2:cf51:2aa8:7926]:80



3 Responses to Боремся с NAT с помощью Teredo и CloudFlare

  1. Максим пишет:

    А самый прикол в том что большинство проблем с поддержкой протокола IPv6 на «серьезном» оборудовании решается с помощью обновления ПО/Firmware (кому как нравится) но сми производители не спешат с этим, а то и вовсе не шевелятся — куда проще еще за пару килобаксов впарить новый маршрутизатор…

  2. Валерий пишет:

    Интересная статья. Хочу воспользоваться ей. Спасибо!

  3. GarenaPlus пишет:

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

Добавить комментарий

Ваш e-mail не будет опубликован.