Pull to refresh

Comments 27

позор Фейсбуку, у которого 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
Хм. У меня не прошло, когда статью писал. Сейчас поправлю.
Очень не хватает какой-то базы знаний по вашем продуктам, какая например есть у широко известного в узких кругах.

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

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

Я бы не сказал, что это в postgres что-то «сломано». Более правильно было бы сказать, что в Postgres не хватает функционала для решения Вашей конкретной задачи.
Ну, это вопрос трактовки. С моей точки зрения — некий код работает с ipv4, но не может (из-за БД) работать с ipv6. Это явно ошибка проектирования postgres, в которой не предусмотрели суммирование мелких (/64) сетей.
Это к вопросу что называть багом, а что не называть. :) Механизм управления IPv6 сетями может быть сломан, если было где-то заявлено что он работает. Т.е. написано, что должно работать одним образом, а работает совсем не так. Пока вроде никто и не обещал что к inet/cidr можно прибавить inet/сidr или хотябы numeric.

BTW postgresql отлично работает с большими числами, надо лишь только попросить.
select pow(2::numeric, 80::numeric) + 1208925819614629174706176::numeric;
А теперь добавьте это к inet. В доке сказано, можно bigint'ы прибавлять, а не numeric'и. Потому я и говорю, что это ошибка проектировки. Разрешили бы numeric'и добавлять, вопросов бы не было. Хотя я бы предпочёл inet+inet.
Небольшой аппроксимацией этого подхода мы переходим к «патчи в апстрим»/«своя БД».
Не надо патчей в апстрим. Свои динамически подгружаемые функции для Postgresql пишутся на коленке. Нам было надо — мы писали.
Если кратко вам будет достаточно конвертировать inet и cidr в numeric там с ним работать и потом конвертировать обратно. Для этого достаточно будет взять bytea представление у inet/cidr его записать в строку и строку отдать конструктору numeric-a. Который и вернуть как результат. То же самое, но в обратном порядке для конверсии numeric в inet/cidr. Вложитесь в 100 строк кода.
можно проще :) дважды прибавить 2^40 :)
select '2a01:4f8:130:1065::2'::inet + pow(2, 40)::bigint + pow(2, 40)::bigint
хорошо, вот еще особоизвращённый способ :) 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;
Я думаю, надо начать с аксиом Пеано, после того, как будет определено рекурсивное сложение через +1, можно будет складывать любые цифры.

По сути — не интересно, мы просто математику вытащили в нормальный код.
Ок, спасибо за информацию.
Вот и я говорю, что всё работает по доке. А вы говорите — поломано. :)
Если документация не охватывает все случаи законного применения описанного, и в этих случаях наблюдается отклонение то ожидаемого — то это ошибка. Не кода, но проектирования.
в документации написано что вы к inet можете прибавить bigint. более там ничего не написано
В тот момент, когда в документацию и код проектировалось inet+bigint, в этот момент была совершена ошибка. Именно такие ошибки и называются «ошибки проектирования».
А зачем Вы вообще храните и считаете что-то меньше /64?
В ipv4 нормальным считается суммировать, например, + /29. В IPv6, да, меньше, чем /64 редко нужно.
У меня на VPS есть ipv6 подсеть /64, и с адресов, с самого сервера хорошо пингуются v6 адреса. Я бы хотел прокинуть часть подсети в openvpn, чтобы можно было ходить по ipv6 адресам сквозь vpn. Как настроить в таком случае маршрутизацию?
Максимум, что у меня получилось сделать — через VPN пингуется сервер по ipv6, но не дальше.
В интернете очень мало материала для понимания таких вещей (или я плохо искал), что посоветуете почитать?
В ipv6 не должно быть сетей шире (больше) /64. Особенно сбивает тот факт, что на интерфейс вы можете повесить сеть любого размера. Однако при попытке ее использования, если она больше /64, вы ступаете на поле с плотно уложенными граблями.
Вот тут хорошо описано.
По ссылке глупость. RIPE NCC на своих тренингах по ipv6 allocation говорит, что размер allocation должен определяться задачей. Если предусматривается наличие дальнейшего деления — то сеть должна быть большего размера.

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

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

Например, если у нас по numbering plan полагается /48 на проект, то должны ли мы в СУБД хранить пачку /64, или таки несколько /48?
Приношу извинения, думал, комментарий мне адресуется (и подумал, что «больше, чем /64 — это /48 и т.д.»).
С точки зрения маршрутизации ситуация ничем не отличается от ipv4. Для того, чтобы иметь возможность «утащить» маршрут в туннель вам нужно, чтобы сеть, которую вы утаскиваете, была бы не locally connected. Условно говоря, если схема вот такая:

router: ::1 — client ::/64

то клиент не может маршрутизировать меньшие кусочки сетей через туннель.
Правильная схема:
router: ----------------   client 1::2  ~~~~ tunnel 99::/64
1::1
99::/64 via 1::2

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

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