Как стать автором
Обновить

Комментарии 6

У меня это реализовано на Linux, 2 канала до hurnicate electric (Швеция и Нидерланды) через 2 физических провайдеров. Для клиентов подняты 2 подсети маршрутизируемые 2мя разными роутерами. Выбор маршрута происходит автоматически на уровне клиента. Yandex через 1го, Google через 2го.

Такая же схема с pfsense: 2 HE туннеля, по одному на WAN, с разными HE endpoint через NATPt. Клиенты в сети получают IPv6 с подсети основного WAN, и транслируются через резервный канал когда основной не доступен. Минус: на момент переключения мы теряем преимущество IPv6: прозрачную маршрутизацию, но без своей ASN я другого решения не вижу. Схема в работе больше 3 лет, работает отлично.

Ну и есть два минуса в самом использовании туннеля:

  1. увы, но в интернетах до сих пор встречаются сервисы которые не понимая важность ICMP трафика банят то что банить нельзя (destination unreachable/package too big) ломая PMTUD и этим ломая HE туннель так как из-за 5 калек вешать на всю intranet MTU 1480 не охота, а без этого они не доступны через туннель.

  2. приходится пройтись по многим geoip db и откорректировать данные о тех подсетях что вы используете для того чтобы бы сервисы которые их используют корректнее работали. Увы война с корпорацией добра (Google) у меня так и не увенчалась успехом, что я не делал, они не меняют geoip информацию на мои 2*/48 подсети на протяжении всех лет. Не понимаю я их если честно - у них в руках их личная geoip, данные геолокации с телефонов и они не могут даже их сопоставить, и форму заявки для ipv6 адаптировать не могут, как и человеко-саппорт добавить.

    Разруливаю оба этих недостатка через unbound python модуль (раньше свой личный, а теперь тот что в pfBlockerNG): делаю strip AAAA для таких нехороших сервисов в DNS resolving. К слову снова с Google пришлось снова повоевать, нужно было обрезать AAAA сразу для нескольких их доменов, видители они в токены авторизации зашивают IP, и выдают свои токены на разные сервисы. Выходит: пришел на google.com по ipv4 - значит иди и на googleusercontent и на youtube, и т.д. Не знаю как у них это вообще работает даже с нормальным резолвингом, ибо любой браузер умеет и сам делать downgrade на запросы с ipv6 на ipv4, если при этом есть выигрыш в производительности.

Я чуть дольше в этой теме у "вконтакте" сервер с картинками отваливался на ipv6, потом поправили :))) У меня оба he канала паралельно работают, но один из них время от времени падает из за падения их ipv4 шлюза. По поводу mtu не понял, у меня 1480 на ipv6 нормально работает. Есть лишь сложности с некоторыми клиентскими машинами в частности на Ubuntu 20.04 netplan настроил на 2 шлюза, а после обновления он вылетел с ошибкой, оказалось больше не держит 2 ipv6 шлюза, а при получении шлюза автоматически другие проблемы вылезают. Поэтому маршрутизатор крутится на SlackWare и все настройки жёстко прописаны.

не понял причем там ВК :).

По MTU - прочитайте еще раз, проблем нет пока вы не наткнетесь на сервер у которого не функционирует PMTUD из-за неверного firewall на его стороне.

у ВК, по крайней мере на момент, когда я ipv6 начал осваивать, часть серваков не умело в ipv6 и когда клиент заходил по v6 - текстовая часть сайта грузилась, а фотки нет. Сейчас там всё работает в полном объёме, но сам факт, что некоторые сайты могут криво работать с ipv6 забавляет :) А с mtu и icmp мне видимо везло или я не рассматривал с этой точки зрения неработающие сайты.

В смысле в полном обьеме? ВК вообще вырубили IPv6, еще давным давно, еще до того как его в Украине забанили...

>> но сам факт, что некоторые сайты могут криво работать с ipv6 забавляет :)

Скажем так - чем сайты которые работают по IPv6 могут делать что то криво? Разве что:geoip, rate limiting, brute force protection, ip restrictions. Тоесть все логические взяви с IP, их в системах не так уж и много. А то что не отображась картинки - это уже проблема из ряда DNS который указывает не на тот сервер или мисконфигурации самого веб сервера..., на прямую к IPv6 не имеющего отношения, просто те кто тестил работу сервиса могли банально забыть что у них еще есть IPv6. Видел одного клиента у которого "заводские" настройки DNS у регистратора имели АААА на парковочные IPv6. Их админ не понимая что такое АААА и почему он там - не стал его убирать, а А запись он конечно поправил. Вышла картина: сайт у них работает "для них", потому что у них нет IPv6, но для нас и для всех нормальных поисковых систем их сайт это что? Правильно - просто заглушка. А потом они удивлялись почему их в поисковиках никто найти не может... Ахаха...

По PMTUD - запустите Microsoft Skype for Business или Lync, и поймете :P

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации