amarao Jun 24 2013 at 15:33

Практика IPv6

4 min

31K

Selectel corporate blog

+59

Comments 27

IIIEB4YK Jun 24 2013 at 17:26

позор Фейсбуку, у которого IPv6 нет!

Как это нет?

$ dig aaaa facebook.com +noall +answer

; <<>> DiG 9.9.2-P1 <<>> aaaa facebook.com +noall +answer
;; global options: +cmd
facebook.com.		474	IN	AAAA	2a03:2880:2110:df07:face:b00c:0:1

amarao Jun 24 2013 at 19:28

Хм. У меня не прошло, когда статью писал. Сейчас поправлю.

NoN Jun 24 2013 at 17:56

Очень не хватает какой-то базы знаний по вашем продуктам, какая например есть у широко известного в узких кругах.

Пытался настроить v6 на облачном сервере — адрес из диапазона на интерфейс повесить смог, входящие пакеты полетели. А прописать маршрут наружу — нет, выскакивала какая-то непонятная ошибка. Быстрое гугление не помогло, забил. Здесь бы пригодился какой-то howto/faq.

amarao Jun 24 2013 at 19:29

Угу. На самом деле я нашёл некоторые ошибки в планировании ipv6, мы будем переделывать allocation (на этот раз окончательно). Закончим — будет всё просто.

am83 Jun 24 2013 at 18:09

Итого — в postgres полностью сломан механизм управления IPv6 сетями

Я бы не сказал, что это в postgres что-то «сломано». Более правильно было бы сказать, что в Postgres не хватает функционала для решения Вашей конкретной задачи.

amarao Jun 24 2013 at 19:30

Ну, это вопрос трактовки. С моей точки зрения — некий код работает с ipv4, но не может (из-за БД) работать с ipv6. Это явно ошибка проектирования postgres, в которой не предусмотрели суммирование мелких (/64) сетей.

mOlind Jun 24 2013 at 20:18

Это к вопросу что называть багом, а что не называть. :) Механизм управления IPv6 сетями может быть сломан, если было где-то заявлено что он работает. Т.е. написано, что должно работать одним образом, а работает совсем не так. Пока вроде никто и не обещал что к inet/cidr можно прибавить inet/сidr или хотябы numeric.

BTW postgresql отлично работает с большими числами, надо лишь только попросить.

select pow(2::numeric, 80::numeric) + 1208925819614629174706176::numeric;

amarao Jun 25 2013 at 12:41

А теперь добавьте это к inet. В доке сказано, можно bigint'ы прибавлять, а не numeric'и. Потому я и говорю, что это ошибка проектировки. Разрешили бы numeric'и добавлять, вопросов бы не было. Хотя я бы предпочёл inet+inet.

Timosha Jun 25 2013 at 14:54

ак напишите :)
PostgreSQL User-defined operators

amarao Jun 25 2013 at 15:15

Небольшой аппроксимацией этого подхода мы переходим к «патчи в апстрим»/«своя БД».

mOlind Jun 25 2013 at 15:27

Не надо патчей в апстрим. Свои динамически подгружаемые функции для Postgresql пишутся на коленке. Нам было надо — мы писали.
Если кратко вам будет достаточно конвертировать inet и cidr в numeric там с ним работать и потом конвертировать обратно. Для этого достаточно будет взять bytea представление у inet/cidr его записать в строку и строку отдать конструктору numeric-a. Который и вернуть как результат. То же самое, но в обратном порядке для конверсии numeric в inet/cidr. Вложитесь в 100 строк кода.

Timosha Jun 25 2013 at 15:53

можно проще :) дважды прибавить 2^40 :)
select '2a01:4f8:130:1065::2'::inet + pow(2, 40)::bigint + pow(2, 40)::bigint

mOlind Jun 25 2013 at 15:54

2^40 + 2^40 = 2^41 :)

Timosha Jun 25 2013 at 17:13

хорошо, вот еще особоизвращённый способ :) 200мс выполняется

WITH RECURSIVE t(inet, n) AS (
    VALUES ('2a01:4f8:130:1065::2'::inet, 0)
  UNION ALL
    SELECT inet + pow(2,62)::bigint, n+1 FROM t WHERE n < pow(2,18)
)
SELECT inet, n FROM t order by n desc 
limit 1;

amarao Jun 25 2013 at 17:47

Я думаю, надо начать с аксиом Пеано, после того, как будет определено рекурсивное сложение через +1, можно будет складывать любые цифры.

По сути — не интересно, мы просто математику вытащили в нормальный код.

amarao Jun 25 2013 at 16:13

Ок, спасибо за информацию.

mOlind Jun 25 2013 at 15:28

Вот и я говорю, что всё работает по доке. А вы говорите — поломано. :)

amarao Jun 25 2013 at 16:17

Если документация не охватывает все случаи законного применения описанного, и в этих случаях наблюдается отклонение то ожидаемого — то это ошибка. Не кода, но проектирования.

Timosha Jun 25 2013 at 16:21

в документации написано что вы к inet можете прибавить bigint. более там ничего не написано

amarao Jun 25 2013 at 16:53

В тот момент, когда в документацию и код проектировалось inet+bigint, в этот момент была совершена ошибка. Именно такие ошибки и называются «ошибки проектирования».

equand Jun 24 2013 at 21:56

А зачем Вы вообще храните и считаете что-то меньше /64?

amarao Jun 25 2013 at 12:40

В ipv4 нормальным считается суммировать, например, + /29. В IPv6, да, меньше, чем /64 редко нужно.

MainNika Jun 24 2013 at 23:51

У меня на VPS есть ipv6 подсеть /64, и с адресов, с самого сервера хорошо пингуются v6 адреса. Я бы хотел прокинуть часть подсети в openvpn, чтобы можно было ходить по ipv6 адресам сквозь vpn. Как настроить в таком случае маршрутизацию?
Максимум, что у меня получилось сделать — через VPN пингуется сервер по ipv6, но не дальше.
В интернете очень мало материала для понимания таких вещей (или я плохо искал), что посоветуете почитать?

Semy Jun 25 2013 at 03:47

В ipv6 не должно быть сетей шире (больше) /64. Особенно сбивает тот факт, что на интерфейс вы можете повесить сеть любого размера. Однако при попытке ее использования, если она больше /64, вы ступаете на поле с плотно уложенными граблями.
Вот тут хорошо описано.

amarao Jun 25 2013 at 13:10

По ссылке глупость. RIPE NCC на своих тренингах по ipv6 allocation говорит, что размер allocation должен определяться задачей. Если предусматривается наличие дальнейшего деления — то сеть должна быть большего размера.

На упражнениях в зависимости от задачи на одного клиента LIR'ам предлагалось выделять от /56-/48 до /32.

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

Например, если у нас по numbering plan полагается /48 на проект, то должны ли мы в СУБД хранить пачку /64, или таки несколько /48?

amarao Jun 25 2013 at 13:17

Приношу извинения, думал, комментарий мне адресуется (и подумал, что «больше, чем /64 — это /48 и т.д.»).

amarao Jun 25 2013 at 13:16

С точки зрения маршрутизации ситуация ничем не отличается от ipv4. Для того, чтобы иметь возможность «утащить» маршрут в туннель вам нужно, чтобы сеть, которую вы утаскиваете, была бы не locally connected. Условно говоря, если схема вот такая:

router: ::1 — client ::/64

то клиент не может маршрутизировать меньшие кусочки сетей через туннель.
Правильная схема:

router: ----------------   client 1::2  ~~~~ tunnel 99::/64
1::1
99::/64 via 1::2

На VDS вам врят ли дадут маршрутизируемую сеть, так что максимум, что вы можете сделать, это unnumbered tunnel или бридж.

Я бы в этой ситуации просто через туннель утащил кусок бриджа и юзал нужный поддиапазон (не подсеть!) на удалённом узле.