LINUX.ORG.RU
Форум — Admin  

настройка ipv6 / 124, 2 интерфейса.

 ,


0

1

Приветствую, сразу оговорюсь, я администрированием в принципе не занимаюсь, появилась необходимость в впне (для себя и друзей), гуглю - настраиваю. С ipv4 проблем никаких, впн работает без проблем, захотелось ipv6 добавить, на нем споткнулся сразу, моих знаний и опыта не хватает, чтобы разобраться и настроить правильно.

Сервер centos7 на digitalocean, выдали следующее
Public IPv6 Address: 2a03:b0c0:3:d0::101:9001
Public IPv6 Gateway: 2a03:b0c0:3:d0::1
Configurable Address Range: 2a03:b0c0:3:d0::101:9000 - 2a03:b0c0:3:d0::101:900f

после настройки с учетом выданных данных имеем:

ip -6 addr s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a03:b0c0:3:d0::101:9001/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::78a5:49ff:fe48:b704/64 scope link
       valid_lft forever preferred_lft forever
4: tap_softether: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 1000
    inet6 fe80::2ac:71ff:fe7b:f6b2/64 scope link
       valid_lft forever preferred_lft forever
ip -6 r s
unreachable ::/96 dev lo metric 1024 error -113
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113
unreachable 2002:a00::/24 dev lo metric 1024 error -113
unreachable 2002:7f00::/24 dev lo metric 1024 error -113
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113
unreachable 2002:ac10::/28 dev lo metric 1024 error -113
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113
unreachable 2002:e000::/19 dev lo metric 1024 error -113
2a03:b0c0:3:d0::/64 dev eth0 proto kernel metric 256
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev tap_softether proto kernel metric 256
default via 2a03:b0c0:3:d0::1 dev eth0 metric 1024
ping6 google.com -I eth0
PING google.com(fra16s14-in-x0e.1e100.net (2a00:1450:4001:81a::200e)) from 2a03:b0c0:3:d0::101:9001 eth0: 56 data bytes
64 bytes from fra16s14-in-x0e.1e100.net (2a00:1450:4001:81a::200e): icmp_seq=1 ttl=58 time=0.959 ms

Пока все отлично. eth0 - смотрит в инет, на tap_softether висят впн клиенты. Но забудем пока про впн пользователей настройку radvd для анонсов и пр., вначале для проверки я хотел настроить вручную, чтобы на интерфейсе tap_softether был белый ip из выданного диапазона и через него можно было ломится в интернет.

Как я себе представлял все:
интерфейсу eth0 назначаем 2a03:b0c0:3:d0::101:9001/128, интерфейсу tap_softether назначаем, к примеру, 2a03:b0c0:3:d0::101:9008/126, добавляем маршрут по которому 9008/126 отправляем на 2a03:b0c0:3:d0::101:9001 и в принципе все. Но сразу же как я назначаю 2a03:b0c0:3:d0::101:9001/128 на eth0, пропадает шлюз по умолчанию, добавить его больше не получается 

ip -6 route add default via 2a03:b0c0:3:d0::1
RTNETLINK answers: No route to host
В общем я пробовал много всего, но больше смахивает на «метод тыка», т.к. моих знаний недостаточно, поэтому решил обратиться за помощью. Подскажите рабочее решение, если оно вообще возможно.

net.ipv6.conf.all.forwarding=1 добавлен
ip6tables отключен


← curlftpfs не показывает содержимого на FTP
Автоматизация сборки deb-пакетов →

Нету в ipv6 префиксов длинее /64. А в эзернет-сегменте он всегда /64. Поэтому

ip -6 addr add 2a03:b0c0:3:d0::101:9001/64 dev eth0
ip -6 route add ::/0 via 2a03:b0c0:3:d0::1
iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 2)

Но сразу же как я назначаю 2a03:b0c0:3:d0::101:9001/128 на eth0, пропадает шлюз по умолчанию, добавить его больше не получается

Что логично, Public IPv6 Gateway: 2a03:b0c0:3:d0::1 не входит в сеть 2a03:b0c0:3:d0::101:9001/128

На eth оставьте маску как было, а для vpn уже кусочек отрежте как и планировали.

anc ★★★★★
()
Ответ на: комментарий от iliyap

Нету в ipv6 префиксов длинее /64. А в эзернет-сегменте он всегда /64

Енто хто вам такое рассказал?

anc ★★★★★
()
Ответ на: комментарий от iliyap

И дальше что? Я чего-то не вижу что что-то мне мешает резать сетку на куски или это что-то - будет мешать работе. Насчет мешать работе я конечно гоню, могут найтись устройства умеющие только в /64, да что там далеко ходить еще не так давно в dhclient-те это было тупо захаркодено (я тут даже тему по этому поводу создавал). Но в целом развитие радует, думаю что когда ipv6 наконец доползет в массы, про 64 уже можно будет и не вспоминать.

anc ★★★★★
()
Ответ на: комментарий от anc

Так ведь у топикстартера речь не про то, что может быть когда-нибудь в будущем. Ему сейчас надо настроить. В рфц по ссылке как раз текущая ситуация и описывается: "... using an IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications".

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

ТС я уже ответил. Вороде должно сработать, во всяком случае нечто подобное у меня работает.

anc ★★★★★
()
Ответ на: комментарий от anc

Что логично, Public IPv6 Gateway: 2a03:b0c0:3:d0::1 не входит в сеть 2a03:b0c0:3:d0::101:9001/128
На eth оставьте маску как было, а для vpn уже кусочек отрежте как и планировали.

Сделал как Вы советовали (лишнее уберу для экономии места),

ip -6 a s
2: eth0: 
    inet6 2a03:b0c0:3:d0::101:9001/64 scope global
    inet6 fe80::78a5:49ff:fe48:b704/64 scope link
4: tap_softether:
    inet6 2a03:b0c0:3:d0::101:9008/126 scope global
    inet6 fe80::2ac:71ff:fe7b:f6b2/64 scope link

ip -6 r s
2a03:b0c0:3:d0::101:9008/126 dev tap_softether proto kernel metric 256
2a03:b0c0:3:d0::/64 dev eth0 proto kernel metric 256
fe80::/64 dev tap_softether proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
default via 2a03:b0c0:3:d0::1 dev eth0 metric 1024
Честно говоря меня это еще больше запутало, получается что на 2ух интерфейсах назначены адреса с пересекающимися по маске диапазонами. На сервере интерфейсы друг друга не пингуют (и я не уверен что должны) 
ping6 2a03:b0c0:3:d0::101:9001 -I tap_softether
ping6: Warning: source address might be selected on device other than tap_softether.
PING 2a03:b0c0:3:d0::101:9001(2a03:b0c0:3:d0::101:9001) from 2a03:b0c0:3:d0::101:9001 tap_softether: 56 data bytes
ping: sendmsg: Network is unreachable
подключенный впн-клиент при этом пингует адреса обоих интерфейсов (но в интернет его при этом не пускает) 
C:\>ping 2a03:b0c0:3:d0::101:9008
Обмен пакетами с 2a03:b0c0:3:d0::101:9008 по с 32 байтами данных:
Ответ от 2a03:b0c0:3:d0::101:9008: время=38мс

C:\>ping 2a03:b0c0:3:d0::101:9001
Обмен пакетами с 2a03:b0c0:3:d0::101:9001 по с 32 байтами данных:
Ответ от 2a03:b0c0:3:d0::101:9001: время=37мс

C:\>ping ipv6.google.com
Обмен пакетами с ipv6.l.google.com [2a00:1450:400c:c04::8b] с 32 байтами данных:
Превышен интервал ожидания для запроса.
Настройки на впн-клиент (указаны в ручную, windows)
   IPv6-адрес. . . . . . . . . . . . : 2a03:b0c0:3:d0::101:9009(Основной)
   Локальный IPv6-адрес канала . . . : fe80::ddd7:5018:33f5:408%18(Основной)
   Основной шлюз. . . . . . . . . : 2a03:b0c0:3:d0::101:9008

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
 Метрика   Сетевой адрес            Шлюз
 18    276 ::/0                     2a03:b0c0:3:d0::101:9008
  1    306 ::1/128                  On-link
 18    276 2a03:b0c0:3:d0::101:9008/126
                                    On-link
 18    276 2a03:b0c0:3:d0::101:9009/128
                                    On-link
 11    266 fe80::/64                On-link
 18    276 fe80::/64                On-link
 11    266 fe80::1410:5934:ae9d:7ea2/128
                                    On-link
 18    276 fe80::ddd7:5018:33f5:408/128
                                    On-link
  1    306 ff00::/8                 On-link
 11    266 ff00::/8                 On-link
 18    276 ff00::/8                 On-link
===========================================================================
Постоянные маршруты:
 Метрика   Сетевой адрес            Шлюз
  0 4294967295 ::/0                     2a03:b0c0:3:d0::101:9008
===========================================================================
я попробовал «методом тыка» поставить шлюзом 2a03:b0c0:3:d0::101:9001, но тогда 2a03:b0c0:3:d0::101:9001 перестает пинговаться с впн-клиента, доступа в интернет тоже нет. Так как я окончательно запутался, подскажите чего еще не хватает чтобы впн-клиенты имели доступ в интернет?

Или это все же невозможно? Если я правильно понял iliyap, то реализовать подобное, с выданным в моем случае диапазоном /124, невозможно?

jdit
() автор топика

Все адреса выделены из одного /64 префикса, который адресует одну подсеть. Остальные хосты в этой подсети (в частности, шлюз 2a03:b0c0:3:d0::1) считают все эти адреса directly connected, поэтому используют NDP для поиска MAC-адреса по IPv6-адресу. В таких случаях для IPv4 используют proxy ARP, а для IPv6 — ND proxy https://tools.ietf.org/html/rfc4389

gw
 | 2a03:b0c0:3:d0::1/64
<=>2a03:b0c0:3:d0::/64 subnet
 | 2a03:b0c0:3:d0::101:9001/64 (eth0)
host
 | link-local/64 (tun0)
 :vpn1 link
 | 2a03:b0c0:3:d0::101:9002/128 (tun0)
vpn client1

На хосте включаем ND proxy для выделенных адресов:

ip nei add proxy 2a03:b0c0:3:d0::101:9002 dev eth0

Для vpn-соединений используем point to point интерфейсы (не tap, а tun), на хосте используем link-local адрес, на vpn-клиенте один из выделенных адресов с длиной префикса /128.

iliyap ★★★★★
()
Ответ на: комментарий от jdit

Простите, ошибся, у меня схема чуть другая. Впрочем iliyap уже дополнил.

anc ★★★★★
()
Ответ на: комментарий от anc

ТС пишет, что у него IPv4 для впн-клиентов настроен. Так как IPv4 адрес выдан скорее всего один, значит IPv4 работает через серые адреса, роутинг и нат. Если сменить роутинг на бриджинг, серые адреса и нат отвалятся, а вместе с ними и IPv4. То есть топология такая как я нарисовал. Так как в IPv6 ната нет, то остается только ND proxy.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Я правильно понимаю что замена tap на tun обязательное условие ? tap создается самим vpn-сервером (softether vpn) и заменить его на tun похоже не получится. Я, конечно, попробовал сделать как Вы написали, только с tap, но не заработало.

jdit
() автор топика

Имхо, проще сделать NAT в локальную сеть, типа fec0::/64, что бы там хейтеры ни говорили, аналогично ipv4

TheAnonymous ★★★★★
()
Последнее исправление: TheAnonymous (всего исправлений: 1)
Ответ на: комментарий от iliyap

ТС пишет, что у него IPv4 для впн-клиентов настроен. Так как IPv4 адрес выдан скорее всего один, значит IPv4 работает через серые адреса, роутинг и нат.

Телепатия 80-го уровня! Не подкол.

Если сменить роутинг на бриджинг, серые адреса и нат отвалятся, а вместе с ними и IPv4.

Не обязательно. Добавить на бридж интерфейс вторым адресом серый ip и его использовать для тунеля. Ну и нат само собой.

Так как в IPv6 ната нет

Уже завезли.

anc ★★★★★
()
Ответ на: комментарий от jdit

1. Выше про бридж.
В части IPv4: Если телепатия у iliyap сработала, то как и написал добавить в бридж еще серый адрес + нат.
Может быть подводный камень в виде включенного net.ipv4.conf.*.send_redirects, хотя при маскараде не должен работать. Но если что запретите вручную.
Второй камень: если необходимо между клиентами впн общаться и видеть именно их адреса, а не замаскараденные, то чуть больше правил добавить придется. Но судя по топику вам это не нужно.

2. nat для ipv6 как упомянул TheAnonymous.

anc ★★★★★
()
Ответ на: комментарий от Legioner

А разве нельзя просто перевести клиентов на IPv6-only и выкинуть IPv4 NAT.

Это вы у клиентов спросите.

anc ★★★★★
()
Ответ на: комментарий от anc

Ну в случае топикстартера думаю клиенты это обычные более-менее современные компьютеры или мобильные устройства у которых вроде с IPv6 всё должно быть в порядке.

Legioner ★★★★★
()

да, ipv4 через нат. Только ipv6 не вариант, половина сайтов не будет открываться. в общем более менее варианты понял, спасибо за советы, буду разбираться, читать мануалы и пробовать настроить.

jdit
() автор топика
Ответ на: комментарий от anc

Я детали не знаю, но знаю, что оно прекрасно работает. Во многих странах мобильные провайдеры давно выдают IPv6 адреса. Вроде IPv4 адрес транслируется в IPv6. Ну понятно, что кто-то должен пакеты перекодировать, видимо роутер.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Ты даже на ЛОР с ipv6-only не зайдёшь, без v4 сейчас никуда, хоть даже серого за натом

TheAnonymous ★★★★★
()
Ответ на: комментарий от Legioner

Типичный уровень понимания ситуации с IPv6. Характерен для масс. На деле же все не так. Нет никакого перекодирования между IPv4 и IPv6. Это два совершенно разных протокола. То, что они называются почти одинаково, ничего не значит. Самое смешное, скажи вот такому кадру «ну есть наверное перекодирование между IP и IPX» — назовет тебя дураком некомпетентным, а сам верит в перекодирование между IPv4 и IPv6.

Ситуация такова, что существует два параллельных интернета, работающих по этим двум протоколам. Пакет не может перетечь из протокола в протокол где-то посреди сети. В каком протоколе его хост инициировал, в таком протоколе этот пакет и живет. Поэтому нельзя перейти на IPv6 с IPv4, можно только добавить IPv6 к IPv4.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Почитай про Address Family Translation (AFT), просветись.

Legioner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← curlftpfs не показывает содержимого на FTP
Admin
Автоматизация сборки deb-пакетов →