Даем пользователям keenetic ipv6

Внезапно (тм) я обнаружил, что пользователям, которые сидят за кинетиком, не достается ipv6. Хотя сам кинетик исправно получает ipv6 и отображает его в дашборде. Немного погуглив, я обнаружил, что одной подсетки /64 кинетику мало, ему надо еще отдать некий prefix description.

Итак, схема соединения простая router - keenetic - user.

На роутере поднят radvd, который отдает RA.

$ cat /etc/radvd.conf 
interface ens19 {
  AdvSendAdvert on;
  AdvDefaultPreference low;
  MinRtrAdvInterval 10;
  MaxRtrAdvInterval 30;

  prefix 2001:db8:99::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
    AdvValidLifetime 120;
    AdvPreferredLifetime 100;
  };

  RDNSS 2001:db8:1::1 {
    AdvRDNSSLifetime 30;
  };

  DNSSL hlevnoe.lan {
    AdvDNSSLLifetime 30;
  };
};

Роутер совершенно честно получает 2001:db8:99:0:52ff:20ff:fe7d:5d71 и показывает этот же адрес у себя в дашборде. И вот тут у меня возник затык. Везде рецепты по получению этого самого PD приводили к каким-то шаманским пляскам с systemd-network и прочим вещам. Естественно, роутеру на это было совершенно монопенисуально. В итоге индеец зоркий глаз обнаружил, что ISC DHCPD умеет отдавать этот самый PD.

$ cat /etc/dhcp/dhcpd6.conf 
default-lease-time 150;

preferred-lifetime 100;
option dhcp-renewal-time 50;
option dhcp-rebinding-time 50;
allow leasequery;
option dhcp6.name-servers 2001:db8:1::1;
option dhcp6.domain-search "hlevnoe.lan","iot.hlevnoe.lan","wifi.hlevnoe.lan";

option dhcp6.preference 255;

option dhcp6.info-refresh-time 60;

subnet6 2001:db8:99::/48 {
	prefix6 2001:db8:100:100:: 2001:db8:100:200:: /56;
}

Я вырезал лишнее. Если кратко, то вся суть в последних трех строчках. 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 и прочими положенными плюшками

Игрища с сервером – 3 или openvpn и ipv6

Сделав очередной openvpn сервер, я задался вопросом: а нафига я его вообще делал? Нет, что бы добираться безопасно до своих ресурсов, это да. Но одна из главных задач – дать клиенту ipv6 в мире ipv4. И именно её он не выполняет. Значит сейчас починим.

Самый простой вариант “в лоб” – перевести сервер в бридж режим и пусть клиенты будут представляться хост-машине как еще одни виртуалки. Минус – замучаюсь с безопасностью. Плюс – тупо и надежно.

Вариант посложнее – выпилить кусочек ipv6 сети и давать её клиентам. Минус тут один – некоторые клиенты почему-то желают видеть у себя /64 и никак иначе. А у меня всего одна /64. Нет, можно получить еще через любого туннельного брокера, но не хочу.

Значит вариант остается один: взять приватную ipv6 подсеть и сделать раздачу из него. Для выбора сетки мы можем брать все что нам понравится, главное что бы первый байт адреса был fd. Вот тут можно даже побаловаться, просто обновляя страничку.

Я возьму для своих крамольных целей сеть fdab:cdef:1234:5678::/64

Почитав маны, добавляю следующие строчки в конфиг сервера

server-ipv6 fdab:cdef:1234:5678::/64
tun-ipv6
push tun-ipv6

И перезагружаю сервер

systemctl restart openvpn@server.service

Переподключаю клиента и смотрю в логи. Вижу заветную строку.

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, а вернее его хипстерские правила, которые не умеют ничего, кроме открытия и закрытия портов. Выносим его

systemctl stop firewalld
yum -y install iptables-services
systemctl enable iptables
systemctl enable ip6tables
systemctl start iptables
systemctl start ip6tables

Добавляем правила для 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

Теперь последний шаг – sysctl.conf

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding=1

То, что надо перечитать – перечитываем, то, что надо перезагрузить – перезагружаем.

Если все сделано правильно, клиент VPN начнет пинговать внешние ipv6 ресурсы. traceroute у меня почему-то обламывался на первом же хопе. Посмотрел tcpdump – видимо, не до конца допилили модуль, отвечающий за NAT: адреса не переписываются. Но с другой стороны – ну и пофиг: если очень надо, то я смогу зайти прямо на хост.

Последняя проверка: а файлики-то клиент утащит?

$ wget -6 google.com
--2016-01-29 04:07:49-- http://google.com/
Resolving google.com (google.com)... 2607:f8b0:4005:800::1002
Connecting to google.com (google.com)|2607:f8b0:4005:800::1002|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.de/?gfe_rd=cr&ei=5SurVtbrKeaD8Qeu6YvACw [following]
--2016-01-29 04:07:49-- http://www.google.de/?gfe_rd=cr&ei=5SurVtbrKeaD8Qeu6YvACw
Resolving www.google.de (www.google.de)... 2607:f8b0:4010:800::101f
Connecting to www.google.de (www.google.de)|2607:f8b0:4010:800::101f|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

[ <=> ] 19,066 97.8KB/s in 0.2s

2016-01-29 04:07:50 (97.8 KB/s) - ‘index.html’ saved [19066]

Утащил!

Значит, можно удовлетворенно потирать руки и идти спать

Новый сервер с игрищами и блудницами – 2

Итак, надо виртуализироваться. Виртуализироваться будем через KVM потому что опять же продвигается редхатом, всеми поддерживается и так далее и тому подобное.

Для начала ставим кучку жутко “необходимого” софта: yum install qemu-kvm libvirt python-virtinst bridge-utils

Затем запускаем установленное

systemctl start libvirtd
systemctl enable libvirtd

Опять же, ничего такого вроде не появилось, за исключением пары интерфейсов с названиями 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

Screenshot 2016-01-16 15.18.40

И добавим еще одно определение сети.

Screenshot 2016-01-16 15.27.38

virsh net-start default

Screenshot 2016-01-16 15.30.24

а в логах должно быть что-то похожее на

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

yum install policycoreutils-python
semanage fcontext -a -t virt_image_t "/vm(/.*)?"
restorecon -R /vm

И выкачиваю дистрибутив 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

Значение каждого параметра либо понятны сразу, либо описаны в документации или интернете. Если все сделали правильно (я каюсь, не сразу все сделал правильно, но это оставим за скобками), то вы должны увидеть текстовый интерфейс, очень похожий расположением элементов на графический. Инсталлятор понятен любому, кто хоть раз ставил центось. В общем, после указания всех шагов получим наглядную иллюстрацию процесса инсталляции.

Screenshot 2016-01-16 16.40.05

После установки мы увидим консоль сервера и может туда залогиниться и даже попинговать ipv4 адреса. ipv6 не пингуется, потому что на интерфейсе сидит только локальный адрес.

Screenshot 2016-01-16 17.37.01

Более того, можно даже немного поэстетствовать и использовать графический virt-manager. Правда, придется добавить немного пакетов, что бы графическая часть морды не ругалась.

yum install xauth libcanberra-gtk3 PackageKit-gtk3-module dejavu-lgc-sans-fonts dejavu-lgc-sans-mono-fonts

Если virt-manager ругается на то, что консоль занята, значит вы не отцепились (Ctrl-]) от текстовой в другом терминале

Ну и затем с любого линукса ssh -X на машину и я получаю вот это.

Screenshot 2016-01-16 17.50.45

В принципе, полный контроль над машинами. Иногда очень удобно, иногда нет.

Но я отвлекся. В виртуальной машине 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_AUTOCONF=yes
IPV6ADDR=2a01:4f8:171:1a43:8000::1234

и перезапустить network

Так, раз пингуется, значит проблема не в адресе, а в настройках. Судя по аналогичным сообщениям, у меня проблемы с маской. Почитав еще немного интернетов, я дошел до такой конфигурации.

<ip family='ipv6' address='2a01:4f8:171:1a43:8000::2' prefix='64'>
<dhcp>
<range start='2a01:4f8:171:1a43:8000::100' end='2a01:4f8:171:1a43:8000::200'/>
</dhcp>
</ip>

Как видите, разница только в маске. Как ни странно, но в этом отношении 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) и оставляю только описание интерфейса.

<ip family='ipv6' address='2a01:4f8:171:1a43::3' prefix='64'>
</ip>

Ну и адрес попроще сделал. И сделал /etc/radvd.conf

interface virbr0
{
AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;
prefix 2a01:4f8:171:1a43::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
RDNSS 2001:db8:0:a0a1::add:1010
2001:db8:0:a102::add:9999
2001:db8:0:a111::add:9898
{
};
};

Затем

systemctl enable radvd.service
systemctl start radvd.service

и перезагрузка виртуалки. Вуаля! Магия ipv6 сработала и виртуалка получила свой адрес.

inet6 2a01:4f8:171:1a43:5054:ff:fe81:5b8f/64 scope global noprefixroute dynamic
valid_lft 86170sec preferred_lft 14170sec

И даже пинги ходят во все стороны. То, что и требовалось получить.

Для проверки я создал еще одну виртуалочку (теперь с сразу с “быстрым” диском)

virt-install --name test2 --ram 1024 --disk path=/vm/test2.qcow2,size=8,bus=virtio,cache=none --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

И сеть в ней сразу заработала без каких-либо дополнительных команд. То, что и требовалось получить. Теперь можно и виртуалки клепать.

Как выдаются адреса? А очень просто: простым маппингом мак-адреса сетевой. Опять же за подробностями в документацию.

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 адреса из “приватной” сети. Фаирволл, обновление и выключение ненужного – наше все.

Не страшно и не сложно, но помнить надо.

Итак, считаю, что очередной шаг закрыт. Теперь надо переносить существующее (разумеется, с одновременным апгрейдом)