Внезапно (тм) я обнаружил, что пользователям, которые сидят за кинетиком, не достается ipv6. Хотя сам кинетик исправно получает ipv6 и отображает его в дашборде. Немного погуглив, я обнаружил, что одной подсетки /64 кинетику мало, ему надо еще отдать некий prefix description.
Итак, схема соединения простая router - keenetic - user.
Роутер совершенно честно получает 2001:db8:99:0:52ff:20ff:fe7d:5d71 и показывает этот же адрес у себя в дашборде. И вот тут у меня возник затык. Везде рецепты по получению этого самого PD приводили к каким-то шаманским пляскам с systemd-network и прочим вещам. Естественно, роутеру на это было совершенно монопенисуально. В итоге индеец зоркий глаз обнаружил, что ISC DHCPD умеет отдавать этот самый PD.
Я вырезал лишнее. Если кратко, то вся суть в последних трех строчках. DHCPD садится на интерфейс, содержащий адрес из подсети 2001:db8:99::/48 и говорит, что любой обратившийся может взять префикс /56 из диапазона 2001:db8:100:100-200
Перезапускаем и тут же получаем в логах следующее
Sep 04 14:36:19 router-wifi dhcpd[2060]: Rebind message from fe80::52ff:20ff:fe7d:5d71 port 546, transaction ID 0x4E15F400
Sep 04 14:36:19 router-wifi dhcpd[2060]: Reply PD: address 2001:db8:100:200::/56 to client with duid 00:03:00:01:50:ff:20:7d:5d:71 iaid = 1 valid for 150 seconds
Sep 04 14:36:19 router-wifi dhcpd[2060]: Sending Reply to fe80::52ff:20ff:fe7d:5d71 port 546
Идем в дашборд кинетика и видим появившуся строчку IPv6 prefix
И клиент тоже подтверждает, что он получил айпишник из этого префикса
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 68:3e:26:b0:b1:93 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.128/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3
valid_lft 215sec preferred_lft 215sec
inet6 2001:db8:100:200:fd6c:e8a9:6e3:7d75/64 scope global temporary dynamic
valid_lft 134sec preferred_lft 84sec
inet6 2001:db8:100:200:ae30:1497:47c9:c0e7/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 134sec preferred_lft 84sec
inet6 fe80::8e0b:e946:d9e4:9dfd/64 scope link noprefixroute
valid_lft forever preferred_lft forever
И теперь самое сложное: дать роутеру понять, куда надо роутить трафик для 2001:db8:100: . Вот тут я нормальных решений не нашел. Кинетик не умеет в динамические протоколы роутинга, а городить некий парсер логов и потом править роуты мне стало откровенно лень. Как делают большие пацаны из телекомов я тоже не нашел. Поэтому я взял и захардкодил это в роуты
routes:
- to: "2001:db8:100::/48"
via: "2001:db8:99:0:52ff:20ff:fe7d:5d71"
on-link: true
Да, криво. Да, может сломаться, если кто-то еще в этой сети попросит PD. Но, повторюсь, других вариантов я не нашел.
Ну а дальше наслаждаемся нормальным ipv6 и прочими положенными плюшками
Сделав очередной openvpn сервер, я задался вопросом: а нафига я его вообще делал? Нет, что бы добираться безопасно до своих ресурсов, это да. Но одна из главных задач – дать клиенту ipv6 в мире ipv4. И именно её он не выполняет. Значит сейчас починим.
Самый простой вариант “в лоб” – перевести сервер в бридж режим и пусть клиенты будут представляться хост-машине как еще одни виртуалки. Минус – замучаюсь с безопасностью. Плюс – тупо и надежно.
Вариант посложнее – выпилить кусочек ipv6 сети и давать её клиентам. Минус тут один – некоторые клиенты почему-то желают видеть у себя /64 и никак иначе. А у меня всего одна /64. Нет, можно получить еще через любого туннельного брокера, но не хочу.
Значит вариант остается один: взять приватную ipv6 подсеть и сделать раздачу из него. Для выбора сетки мы можем брать все что нам понравится, главное что бы первый байт адреса был fd. Вот тут можно даже побаловаться, просто обновляя страничку.
Я возьму для своих крамольных целей сеть fdab:cdef:1234:5678::/64
Почитав маны, добавляю следующие строчки в конфиг сервера
Переподключаю клиента и смотрю в логи. Вижу заветную строку.
Fri Jan 29 03:12:31 2016 /usr/sbin/ip addr add dev tun0 local 10.100.2.6 peer 10.100.2.5
Fri Jan 29 03:12:31 2016 /usr/sbin/ip -6 addr add fdab:cdef:1234:5678::1000/64 dev tun0
Fri Jan 29 03:12:31 2016 /usr/sbin/ip route add 10.100.0.0/24 via 10.100.2.5
Пробую с клиента пингануть сервер
$ ping6 fdab:cdef:1234:5678::1 -c 2
PING fdab:cdef:1234:5678::1(fdab:cdef:1234:5678::1) 56 data bytes
64 bytes from fdab:cdef:1234:5678::1: icmp_seq=1 ttl=64 time=48.1 ms
64 bytes from fdab:cdef:1234:5678::1: icmp_seq=2 ttl=64 time=48.2 ms
Работает! Теперь осталось самая мелочь – запушить правило роутинга, адрес ДНС и собственно роутинг сделать.
Строчка конфига
push "route-ipv6 2000::/3"
Заставит маршрутизировать весь ipv6 трафик через openvpn. Почти как redirect-gateway def1, но только для ipv6.
Но так как у нас приватная сеть, то я могу пинговать только openvpn. Другие хосты согласно правилам хорошего тона, такие поползновения обламывают.
К сожалению, тут опять на белый свет выползает firewalld, а вернее его хипстерские правила, которые не умеют ничего, кроме открытия и закрытия портов. Выносим его
Добавляем правила для SNAT и открываем 1194/udp на вход -A POSTROUTING -s 10.100.2.0/24 -o eth0 -j SNAT --to-source 10.100.0.133
-A POSTROUTING -s fdab:cdef:1234:5678::/64 -o eth0 -j SNAT --to-source 2a01:4f8:171:1a43:5054:ff:fe0d:da49
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT
И удаляем мешающееся
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
То, что надо перечитать – перечитываем, то, что надо перезагрузить – перезагружаем.
Если все сделано правильно, клиент VPN начнет пинговать внешние ipv6 ресурсы. traceroute у меня почему-то обламывался на первом же хопе. Посмотрел tcpdump – видимо, не до конца допилили модуль, отвечающий за NAT: адреса не переписываются. Но с другой стороны – ну и пофиг: если очень надо, то я смогу зайти прямо на хост.
Итак, надо виртуализироваться. Виртуализироваться будем через KVM потому что опять же продвигается редхатом, всеми поддерживается и так далее и тому подобное.
Для начала ставим кучку жутко “необходимого” софта: yum install qemu-kvm libvirt python-virtinst bridge-utils
Опять же, ничего такого вроде не появилось, за исключением пары интерфейсов с названиями virbr и адресом 192.168.122.1/24.
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 52:54:00:ba:d8:82 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 500
link/ether 52:54:00:ba:d8:82 brd ff:ff:ff:ff:ff:ff
Первым делом мне надо добавить ipv6 адрес. Только не вздумайте искать по совпадениям и править руками. Есть гораздо более приятные средства.
virsh net-destroy default
virsh net-edit default
И добавим еще одно определение сети.
virsh net-start default
а в логах должно быть что-то похожее на
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: DHCP, IP range 10.100.0.100 -- 10.100.0.200, lease time 1h
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: DHCPv6, IP range 2a01:4f8:171:1a43:8000::1000 -- 2a01:4f8:171:1a43:8000::2000, lease time 1h
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: router advertisement on 2a01:4f8:171:1a43::
Jan 16 13:28:36 tower dnsmasq-dhcp[3544]: IPv6 router advertisement enabled
Откуда появился 2a01:4f8:171:1a43:8000::2/96 ?
Дело в том, что hetzner выдал мне ipv6 адрес 2a01:4f8:171:1a43::2/64. Типа подсеть на хост и все такое. Я взял с серединки (:8000) кусочек в 32 бита (128-96) или 4 миллиарда адресов. Ну или столько, сколько сейчас адресов в интернете 🙂 Из этого диапазона я выделил малюсенький кусочек в тысячу адресов для виртуалок. Думаю, что мне этого хватит 🙂 Ну и заодно поменял адрес для ipv4 на более подходящий мне.
Теперь самое время проверить доступность с другого хоста.
[root@outpost ~]# ping6 2a01:4f8:171:1a43:8000::2 -c 2
PING 2a01:4f8:171:1a43:8000::2(2a01:4f8:171:1a43:8000::2) 56 data bytes
64 bytes from 2a01:4f8:171:1a43:8000::2: icmp_seq=1 ttl=59 time=0.864 ms
64 bytes from 2a01:4f8:171:1a43:8000::2: icmp_seq=2 ttl=59 time=0.490 ms
--- 2a01:4f8:171:1a43:8000::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.490/0.677/0.864/0.187 ms
[root@outpost ~]# ping6 2a01:4f8:171:1a43::2 -c 2
PING 2a01:4f8:171:1a43::2(2a01:4f8:171:1a43::2) 56 data bytes
64 bytes from 2a01:4f8:171:1a43::2: icmp_seq=1 ttl=59 time=0.341 ms
64 bytes from 2a01:4f8:171:1a43::2: icmp_seq=2 ttl=59 time=0.452 ms
--- 2a01:4f8:171:1a43::2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.341/0.396/0.452/0.058 ms
В общем, все как в ipv4, только маски дикие по размерам и не привычные.
Теперь надо поднять какую-нибудь виртуалку, что бы протестировать роутинг и прочие штуки.
Добавляем полезную утилиту для лентяев yum install virt-install virt-viewer
И останавливаемся. Потому что нам надо выделить немножко места для виртуалок.
lvcreate -L 100G -n vm vg0
mkfs.xfs /dev/vg0/vm
mkdir /vm
mcedit /etc/fstab
mount /vm
100Гб для начала хватит, а потом по необходимости растяну.
Так как я хардкорничаю, то добавляю необходимое для selinux
И выкачиваю дистрибутив CentOS (Тут немного бальзама: качается по ipv6. Мелочь, а приятно)
mkdir /vm/iso
cd /vm/iso
wget http://ftp.funet.fi/pub/mirrors/centos.org/7/isos/x86_64/CentOS-7-x86_64-DVD-1511.iso
Ну и теперь пора поставить тестовую машину. Пока без всяких ускорений, акселераций и прочего. Мне надо просто проверить сеть и все, что с ней связано.
virt-install --name test --ram 1024 --disk path=/vm/test.qcow2,size=8 --vcpus 1 --os-type linux --network bridge=virbr0 --location /vm/iso/CentOS-7-x86_64-DVD-1511.iso --extra-args='console=tty0 console=ttyS0,115200n8 serial' --nographics
Значение каждого параметра либо понятны сразу, либо описаны в документации или интернете. Если все сделали правильно (я каюсь, не сразу все сделал правильно, но это оставим за скобками), то вы должны увидеть текстовый интерфейс, очень похожий расположением элементов на графический. Инсталлятор понятен любому, кто хоть раз ставил центось. В общем, после указания всех шагов получим наглядную иллюстрацию процесса инсталляции.
После установки мы увидим консоль сервера и может туда залогиниться и даже попинговать ipv4 адреса. ipv6 не пингуется, потому что на интерфейсе сидит только локальный адрес.
Более того, можно даже немного поэстетствовать и использовать графический virt-manager. Правда, придется добавить немного пакетов, что бы графическая часть морды не ругалась.
Если virt-manager ругается на то, что консоль занята, значит вы не отцепились (Ctrl-]) от текстовой в другом терминале
Ну и затем с любого линукса ssh -X на машину и я получаю вот это.
В принципе, полный контроль над машинами. Иногда очень удобно, иногда нет.
Но я отвлекся. В виртуальной машине ipv4 есть, получен и даже работает, а ipv6 нет. И еще тормозит по диску уж больно жутко.
Диск лечится просто: тормозим машину, virsh edit test и где driver добавляем cache=’unsafe’ (для рабочих не надо так делать). После запускаем и видим вполне себе шустро бегающую машинку.
Теперь с сетью. Заходим на тестовую машину, запускаем dhclient -6 ens3 (ens3 это у меня сетевой интерфейс). И видим в логах
Jan 16 16:30:58 tower dnsmasq-dhcp[3544]: no address range available for DHCPv6 request via virbr0
Оппа! А почему? Вроде же определили все и выдали тоже все …
Прибиваем в тестовой машине адрес 2a01:4f8:171:1a43:8000::99 и пингуем – пингуется, но только с хоста. Это нормально.
Как прибить? В /etc/sysconfig/network-scripts/ifcfg-ens3
Так, раз пингуется, значит проблема не в адресе, а в настройках. Судя по аналогичным сообщениям, у меня проблемы с маской. Почитав еще немного интернетов, я дошел до такой конфигурации.
Как видите, разница только в маске. Как ни странно, но в этом отношении ipv6 (вернее, его роутинг в линуксе) ведет себя немного “странней”, чем для ipv4. Но в любом случае, прочитанное оказалось верным и машина получила свой адрес.
Jan 16 18:03:01 tower dnsmasq-dhcp[5491]: DHCPREQUEST(virbr0) 10.100.0.141 52:54:00:81:5b:8f
Jan 16 18:03:01 tower dnsmasq-dhcp[5491]: DHCPACK(virbr0) 10.100.0.141 52:54:00:81:5b:8f test
Jan 16 18:03:03 tower dnsmasq-dhcp[5491]: RTR-SOLICIT(virbr0)
Jan 16 18:03:03 tower dnsmasq-dhcp[5491]: RTR-ADVERT(virbr0) 2a01:4f8:171:1a43::
Jan 16 18:03:03 tower dnsmasq-dhcp[5491]: DHCPCONFIRM(virbr0) 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:04 tower dnsmasq-dhcp[5491]: DHCPSOLICIT(virbr0) 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:04 tower dnsmasq-dhcp[5491]: DHCPADVERTISE(virbr0) 2a01:4f8:171:1a43:8000::13c 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:05 tower dnsmasq-dhcp[5491]: DHCPREQUEST(virbr0) 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Jan 16 18:03:05 tower dnsmasq-dhcp[5491]: DHCPREPLY(virbr0) 2a01:4f8:171:1a43:8000::13c 00:01:00:01:1e:2d:1e:b1:52:54:00:81:5b:8f
Вывод ip addr
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:00:81:5b:8f brd ff:ff:ff:ff:ff:ff
inet 10.100.0.141/24 brd 10.100.0.255 scope global dynamic ens3
valid_lft 3590sec preferred_lft 3590sec
inet6 2a01:4f8:171:1a43:8000::13c/128 scope global dynamic
valid_lft 3595sec preferred_lft 3595sec
inet6 fe80::5054:ff:fe81:5b8f/64 scope link
valid_lft forever preferred_lft forever
Как видно, сервер получил свой персональный ipv6 адрес, но ничего, кроме хоста пинговать не может. Причина простая как грабли – ipv6 не имеет NAT в принципе. Только роутинг.
Косвенным подтверждением является попытка попинговать адрес тестовой машины снаружи
[root@outpost ~]# ping6 2a01:4f8:171:1a43:8000::13c
PING 2a01:4f8:171:1a43:8000::13c(2a01:4f8:171:1a43:8000::13c) 56 data bytes
From 2a01:4f8:171:1a43::2 icmp_seq=1 Destination unreachable: Address unreachable
From 2a01:4f8:171:1a43::2 icmp_seq=2 Destination unreachable: Address unreachable
То есть пинг доходит до хоста, а тот отвечает, что не знает, куда роутить этот адрес. Аналогичное получим, если попытаемся напрямую с хоста попинговать. Ну нету этого адреса в таблице роутинга и все тут. Меняем маску на основном интерфейсе (64->128), что бы таблицу роутинга в порядок привести. Без перезагрузки
ip addr del 2a01:4f8:171:1a43::2/64 dev eth0
ip addr add 2a01:4f8:171:1a43::2/128 dev eth0
А с перезагрузкой в /etc/sysconfig/network-scripts/ifcfg-eth0
Что изменилось? С хоста началась пинговаться виртуалка и все. В общем, лично мне стало понятно, что ipv6 – это нифига не ipv4, только с бОльшими масками.
(чтение мануалов опущено)
В общем, с одной стороны все проще, а с другой – все сложнее. В ipv6 есть такая штука, как SLAAC, которая работает как некий навороченный DHCP сервер. Подробнее в маны.
Поэтому выкидываю нафиг все из настроек dnsmasq (virsh net-edit default) и оставляю только описание интерфейса.
И сеть в ней сразу заработала без каких-либо дополнительных команд. То, что и требовалось получить. Теперь можно и виртуалки клепать.
Как выдаются адреса? А очень просто: простым маппингом мак-адреса сетевой. Опять же за подробностями в документацию.
link/ether 52:54:00:e4:63:05 brd ff:ff:ff:ff:ff:ff
inet6 2a01:4f8:171:1a43:5054:ff:fee4:6305/64 scope global noprefixroute dynamic
Главное изменение теперь в “политике безопасности”.
Раньше: вся сетевая безопасность лежала на хосте. Гости получали уже отфильтрованный трафик, только на те порты, которые разрешены. Можно было спокойно открывать порты, не опасаясь ничего.
Теперь: каждый гость выставлен наружу “напрямую” и требует соответствующей защиты. И не важно, что ipv4 адреса из “приватной” сети. Фаирволл, обновление и выключение ненужного – наше все.
Не страшно и не сложно, но помнить надо.
Итак, считаю, что очередной шаг закрыт. Теперь надо переносить существующее (разумеется, с одновременным апгрейдом)
