Продолжение предыдущего поста . В общем, настроил я себе "типа клёвую" домашнюю сеть с блэкджеком и шлюхами IPv4 и IPv6, маршрутизацией через забугорный VDS и всё вот это. И на следующий день обнаружил, что оно ни х*я не работает по причинам, описанным здесь: раз , два . Если кратко, собака порылась в поведении функции GetAddrInfo(), сокращённо "GAI". Какие-то умные дядьки из IETF решили и постановили, что коннективити (связность) по ULA-адресам должна иметь самый низкий приоритет. Даже ниже, чем IPv4. Поэтому если в ответ на доменное имя возвращается несколько адресов, среди которых есть и IPv4, и IPv6, а на клиенте также настроены и IPv4, и IPv6+ULA интерфейсы, то клиент выберет IPv4, без вариантов. Ковырять "/etc/gai.conf" при этом бесполезно, т.к. он управляет только выбором на основании destination-адреса. Другими словами, если клиент имеет ULA-адрес и IPv4-адрес, то после разрешения доменного имени он всегда выберет IPv4. Некоторые на эту тему даже шутят, что ULA по этой причине должно расшифровываться как "Useless Local Address". Таким образом, та схема, которую я собрал в предыущем посте, может стать работоспособной только в двух случаях. Я вообще выключаю IPv4 в своей локальной сети. Я средствами своего локального кеширующего DNS-сервера вырезаю из ответов вышестоящих серверов A-записи, но только если в них присутствуют также и AAAA-записи. Первый вариант не канает по причине того, что я тут же потеряю связность до хостов, у которых нет IPv6-адреса. То есть мне станет недоступна больше чем половина рунета. Второй вариант теоретически жизнеспособен, но покажите мне DNS-сервер, который такое умеет. Да, в DNSMasq 2.87 появилась опция "filter-A", но она работает слишком топорно: удаляет A-записи в любом случае. А мне нужно, чтобы удаляла только если в ответе есть AAAA. Поэтому тоже "не судьба". Технически возможно делегировать на клиентов в локальной сети GUA-адреса сразу от двух провайдеров. Но тогда мы приходим к тому, что правила маршрутизации должны быть определены на самом клиенте, в противном случае он не сможет выбрать правильный source IP для установления соединения. То есть, на клиенте должен быть запущен какой-то софт, который откуда-то скачает список заблокированных ресурсов, прожуёт его, сопоставит с имеющимися на интерфейсах IPv6-адресами, каким-то образом разберется какой из них куда смотрит и в зависимости от этого заполнит таблицу маршрутизации ядра. Слишком геморройно, чтобы рассматривать такой способ всерьёз. М-дя. Когда разрабатывали IPv6, ещё не было ни Роскомпозора, ни блокировок, ни "культуры отмены". Так что вынужден констатировать, что использовать IPv6 в сложившихся обстоятельствах, увы, не получится. Остается, правда, последний вариант. Весь IPv6 целиком "как есть" завернуть "туда", через VDS. А IPv4 оставить "как было". Но для этого надо выяснить раздает ли мой забугорный хостинг-провайдер "/56"-подсетки. И если да, то как протащить и раздать её кусочек "сюда", в домашнюю LAN. Ох блин, сложно всё это. Теперь я понимаю почему большинство одминов не любят и боятся IPv6.