Добавете частен IPv6 към лаборатория с OpenVPN, по една контролна точка наведнъж

Вече имате клиент, който се свързва през IPv4 и достига до частен товар IPv4 зад сървъра. Целта е да достигнете частен товар IPv6 през същия тунел, без да пипате външния транспорт. Редът е важен: външният път остава IPv4 и се променят само вътрешният план на адреси, маршрутът на клиента и обратният път от сървъра към LAN. Пет контролни точки, всяка с нещо конкретно за проверка, преди да продължите.

Контролна точка първа: връзката, която вече работи

Свържете клиента и потвърдете пътя IPv4, преди да добавяте каквото и да е. Работещият тунел ви дава базова линия, която отделя нова грешка IPv6 от стар проблем със свързаността. Той също показва кой екземпляр на сървъра редактирате в действителност.

Отбележете пула, топологията и push-натите маршрути, на които вече разчитате. Работата по IPv6 разширява тази конфигурация; не я заменя.

Контролна точка втора: изберете вътрешните префикси

Изберете ULA /48 за обекта и изрежете от него два /64: един за клиентите на тунела, един за LAN сегмента с товара IPv6. Генерирайте 40-битовия глобален ID, вместо да копирате примерен префикс, и проверете двете подмрежи срещу всяка мрежа, която обектът вече маршрутизира:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Два независими /64 не позволяват пулът на клиентите да бъде изрязан от LAN сегмента, което има значение по-късно, когато пишете обратния маршрут. Стойностите по-горе са един разработен пример, а не префикс за преизползване.

Контролна точка трета: добавете помощника и push на маршрута

Прочетете текущата конфигурация на сървъра, преди да добавяте нещо. Второ копие на съществуваща директива не се слива с първото и получената грешка назовава директивата, а не IPv6. При наличен помощник IPv4 два реда го разширяват. Всеки отговаря на различен въпрос:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Първият е удобен помощник, който настройва интерфейса и пула на клиентите. Вторият назовава дестинацията в LAN, до която клиентът трябва да стигне. Даването на IPv6 адрес на клиента не му казва кои мрежи има зад сървъра, затова са нужни и двата реда.

Помощникът не съжителства със статичен пул IPv6 или с nopool. Ако внедряването съзнателно раздава адреси статично, запазете тази политика и проектирайте еквивалента IPv6 изрично, вместо да изтриете политиката, за да пасне на пример.

Контролна точка четвърта: препращане и маршрут за отговор

Включете препращането на IPv6 на сървъра през собственика на конфигурацията на системата, а не с еднократен запис по време на изпълнение, който ще забравите. Формата по време на изпълнение е полезна за бърз тест. Постоянната конфигурация принадлежи в drop-in файл, който мрежовият собственик на дистрибуцията чете:

sysctl -w net.ipv6.conf.all.forwarding=1

Препращането променя поведението на хоста по IPv6 отвъд маршрутизирането на пакети. Хост, който е приемал обяви от рутер като клиент, спира да го прави по същия начин, щом започне да препраща. Затова машина, чийто uplink IPv6 зависи от RA, се нуждае от изричен план за този uplink.

След това дайте на LAN маршрут обратно към пула на тунела. Шлюзът IPv6 на товара е рутерът на LAN, а не сървърът VPN, така че маршрутът е на този рутер и сочи към LAN адреса на сървъра:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Запазете типовете ICMPv6, от които връзката се нуждае, включително обратната връзка за MTU на пътя. Правило на защитна стена за IPv4 не означава правило за IPv6 и цялостно блокиране на IPv6 чупи откриването на съседи по начин, който изглежда като маршрутна повреда.

Контролна точка пета: прочетете клиента, после тествайте

Свържете клиента отново и прочетете адресите, които той наистина е получил, вместо да ги извеждате от адреса на помощника на сървъра. Списъкът на интерфейсите показва двете семейства на едно и също устройство:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Маршрут, който избира тунела, доказва, че клиентът знае къде да изпрати пакета. Той не доказва, че сървърът го препраща, че рутерът на LAN има обратния маршрут или че на приложението е разрешено да отговори.

Тествайте самото приложение по всяко семейство на свой ред, после повторете след повторно свързване и след рестарт на хоста. Маршрут или sysctl, който оцелява само до рестарт, е тест, а не проект.

Публикувайте запис AAAA само след като пътят IPv6 отговаря от край до край. DNS, заявен през IPv4, все още може да върне адрес IPv6, така че разрешимо име не е доказателство, че нещо слуша. Указанието RFC 4193 за ULA покрива генерирането на глобалния ID, който прави тези префикси ваши, а не копие.