Comments 27
Очень не хватает какой-то базы знаний по вашем продуктам, какая например есть у широко известного в узких кругах.
Пытался настроить v6 на облачном сервере — адрес из диапазона на интерфейс повесить смог, входящие пакеты полетели. А прописать маршрут наружу — нет, выскакивала какая-то непонятная ошибка. Быстрое гугление не помогло, забил. Здесь бы пригодился какой-то howto/faq.
Пытался настроить v6 на облачном сервере — адрес из диапазона на интерфейс повесить смог, входящие пакеты полетели. А прописать маршрут наружу — нет, выскакивала какая-то непонятная ошибка. Быстрое гугление не помогло, забил. Здесь бы пригодился какой-то howto/faq.
+4
Итого — в postgres полностью сломан механизм управления IPv6 сетями
Я бы не сказал, что это в postgres что-то «сломано». Более правильно было бы сказать, что в Postgres не хватает функционала для решения Вашей конкретной задачи.
+2
Ну, это вопрос трактовки. С моей точки зрения — некий код работает с ipv4, но не может (из-за БД) работать с ipv6. Это явно ошибка проектирования postgres, в которой не предусмотрели суммирование мелких (/64) сетей.
-1
Это к вопросу что называть багом, а что не называть. :) Механизм управления IPv6 сетями может быть сломан, если было где-то заявлено что он работает. Т.е. написано, что должно работать одним образом, а работает совсем не так. Пока вроде никто и не обещал что к inet/cidr можно прибавить inet/сidr или хотябы numeric.
BTW postgresql отлично работает с большими числами, надо лишь только попросить.
BTW postgresql отлично работает с большими числами, надо лишь только попросить.
select pow(2::numeric, 80::numeric) + 1208925819614629174706176::numeric;
+5
А теперь добавьте это к inet. В доке сказано, можно bigint'ы прибавлять, а не numeric'и. Потому я и говорю, что это ошибка проектировки. Разрешили бы numeric'и добавлять, вопросов бы не было. Хотя я бы предпочёл inet+inet.
0
ак напишите :)
PostgreSQL User-defined operators
PostgreSQL User-defined operators
0
Небольшой аппроксимацией этого подхода мы переходим к «патчи в апстрим»/«своя БД».
0
Не надо патчей в апстрим. Свои динамически подгружаемые функции для Postgresql пишутся на коленке. Нам было надо — мы писали.
Если кратко вам будет достаточно конвертировать inet и cidr в numeric там с ним работать и потом конвертировать обратно. Для этого достаточно будет взять bytea представление у inet/cidr его записать в строку и строку отдать конструктору numeric-a. Который и вернуть как результат. То же самое, но в обратном порядке для конверсии numeric в inet/cidr. Вложитесь в 100 строк кода.
Если кратко вам будет достаточно конвертировать inet и cidr в numeric там с ним работать и потом конвертировать обратно. Для этого достаточно будет взять bytea представление у inet/cidr его записать в строку и строку отдать конструктору numeric-a. Который и вернуть как результат. То же самое, но в обратном порядке для конверсии numeric в inet/cidr. Вложитесь в 100 строк кода.
+1
можно проще :) дважды прибавить 2^40 :)
select '2a01:4f8:130:1065::2'::inet + pow(2, 40)::bigint + pow(2, 40)::bigint
0
2^40 + 2^40 = 2^41 :)
+1
хорошо, вот еще особоизвращённый способ :) 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;
0
Ок, спасибо за информацию.
0
Вот и я говорю, что всё работает по доке. А вы говорите — поломано. :)
0
А зачем Вы вообще храните и считаете что-то меньше /64?
0
У меня на VPS есть ipv6 подсеть /64, и с адресов, с самого сервера хорошо пингуются v6 адреса. Я бы хотел прокинуть часть подсети в openvpn, чтобы можно было ходить по ipv6 адресам сквозь vpn. Как настроить в таком случае маршрутизацию?
Максимум, что у меня получилось сделать — через VPN пингуется сервер по ipv6, но не дальше.
В интернете очень мало материала для понимания таких вещей (или я плохо искал), что посоветуете почитать?
Максимум, что у меня получилось сделать — через VPN пингуется сервер по ipv6, но не дальше.
В интернете очень мало материала для понимания таких вещей (или я плохо искал), что посоветуете почитать?
0
В ipv6 не должно быть сетей шире (больше) /64. Особенно сбивает тот факт, что на интерфейс вы можете повесить сеть любого размера. Однако при попытке ее использования, если она больше /64, вы ступаете на поле с плотно уложенными граблями.
Вот тут хорошо описано.
Вот тут хорошо описано.
+1
По ссылке глупость. RIPE NCC на своих тренингах по ipv6 allocation говорит, что размер allocation должен определяться задачей. Если предусматривается наличие дальнейшего деления — то сеть должна быть большего размера.
На упражнениях в зависимости от задачи на одного клиента LIR'ам предлагалось выделять от /56-/48 до /32.
Посмотрите внимательно видео с тренингов NCC, которое мы публиковали.
Например, если у нас по numbering plan полагается /48 на проект, то должны ли мы в СУБД хранить пачку /64, или таки несколько /48?
На упражнениях в зависимости от задачи на одного клиента LIR'ам предлагалось выделять от /56-/48 до /32.
Посмотрите внимательно видео с тренингов NCC, которое мы публиковали.
Например, если у нас по numbering plan полагается /48 на проект, то должны ли мы в СУБД хранить пачку /64, или таки несколько /48?
0
Приношу извинения, думал, комментарий мне адресуется (и подумал, что «больше, чем /64 — это /48 и т.д.»).
0
С точки зрения маршрутизации ситуация ничем не отличается от ipv4. Для того, чтобы иметь возможность «утащить» маршрут в туннель вам нужно, чтобы сеть, которую вы утаскиваете, была бы не locally connected. Условно говоря, если схема вот такая:
router: ::1 — client ::/64
то клиент не может маршрутизировать меньшие кусочки сетей через туннель.
Правильная схема:
На VDS вам врят ли дадут маршрутизируемую сеть, так что максимум, что вы можете сделать, это unnumbered tunnel или бридж.
Я бы в этой ситуации просто через туннель утащил кусок бриджа и юзал нужный поддиапазон (не подсеть!) на удалённом узле.
router: ::1 — client ::/64
то клиент не может маршрутизировать меньшие кусочки сетей через туннель.
Правильная схема:
router: ---------------- client 1::2 ~~~~ tunnel 99::/64 1::1 99::/64 via 1::2
На VDS вам врят ли дадут маршрутизируемую сеть, так что максимум, что вы можете сделать, это unnumbered tunnel или бридж.
Я бы в этой ситуации просто через туннель утащил кусок бриджа и юзал нужный поддиапазон (не подсеть!) на удалённом узле.
0
Sign up to leave a comment.
Практика IPv6