Russian Users MikroTik | Форум пользователей MikroTik

Erik_U писал(а): ↑11 сен 2024, 11:51 Так не будет работать.

ПО факту получается так, что браузер при доступе к одному и тому же сайту ломится на него то по IP4, то по IP6.
И от чего это зависит - непонятно, потому, что в кеше ДНС-а в этот момент есть и А запись, и АААА.
Ваше правило не будет работать.
Потому, что фильтры IP6 оперируют и с адрес-листами IP6, и сформированный адрес-лист будет содержать адреса IP6.
В случае, если ваш браузер пойдет на сайт по IP4, его это правило вообще не коснется.
А если браузер пойдет на другой сайт (которого нет в адрес-листе) по IP6, то его просто отрубит, но он и не подумает переключиться на IP4. Будет выдавать свое "проверьте соединение".

Специально сейчас проверил, всё прекрасно работает. Если нет доступа по IPv6, браузер прекрасно будет ходить по IPv4.

Если днс отвечает адресом IP6, а к нему доступа нет, то браузер где-то сам узнает адрес IP4?
Можете этот механизм осветить подробнее?

Вы полагаетесь на какой-то искусственный интеллект где-то там.

Erik_U писал(а): ↑11 сен 2024, 12:54 Если днс отвечает адресом IP6, а к нему доступа нет, то браузер где-то сам узнает адрес IP4?
Можете этот механизм осветить подробнее?

Вы полагаетесь на какой-то искусственный интеллект где-то там.

DNS получает сразу А и АААА(если имеется) запись DNS. По умолчанию идет соединение по Ipv6, если недоступно то по IPv4.
Если у Вас имеется тунель до брокера, настройте всего два правила в фаервол да проверьте, если не верите.
1) Разрешает Forward из бридж в тунель, только на адреса из Adress List.
2) Блокирует все forward из бриджа в тунель брокера.

RusCosmic писал(а): ↑11 сен 2024, 13:33 DNS получает сразу А и АААА(если имеется) запись DNS. По умолчанию идет соединение по Ipv6, если недоступно то по IPv4.

так должно быть
А фактически:
- Часто (через раз на третий) при наличии адреса АААА (на котором вот только что все работало) соединение устанавливается на А.
- Когда стал недоступен АААА, на А не переключается. Выдает ошибку соединения.
Чтобы заработало, нужно релоадить в браузере несколько раз. Или перезапускать браузер.
- Плюс. Если в списки ДНС серверов добавлен сервер с адресом IP6, и обращение пошло таки к нему, то он возвращает адрес только АААА. Это сразу все "логику" убивает.
Например, ДНС яндекса - 2a02:6b8::feed:ff на ютуб.ком выдает только 2a00400f:801::200e

Искусственный интеллект где-то дает сбой.
Зачем его вообще сделали? Добавили бы просто отдельный протокол, самостоятельный, не завязанный на старые версии. Вся эта "автоматика" сбоит постоянно. И не поддается понятному траблешутингу при этом.

Erik_U писал(а): ↑11 сен 2024, 13:47

RusCosmic писал(а): ↑11 сен 2024, 13:33 DNS получает сразу А и АААА(если имеется) запись DNS. По умолчанию идет соединение по Ipv6, если недоступно то по IPv4.

так должно быть
А фактически:
- Часто (через раз на третий) при наличии адреса АААА (на котором вот только что все работало) соединение устанавливается на А.
- Когда стал недоступен АААА, на А не переключается. Выдает ошибку соединения.
Чтобы заработало, нужно релоадить в браузере несколько раз. Или перезапускать браузер.

Искусственный интеллект где-то дает сбой.
Зачем его вообще сделали? Добавили бы просто отдельный протокол, самостоятельный, не завязанный на старые версии. Вся эта "автоматика" сбоит постоянно. И не поддается понятному траблешутингу при этом.

Речь шла о том - как сделать, чтобы только Ютуб по IPv6 ходил, остальные по IPv4. Как сделать, я написал. Что там у Вас сбоит и при чём тут вообще ИИ, я хз

Если в списки ДНС серверов добавлен сервер с адресом IP6, и обращение пошло таки к нему, то он возвращает адрес только АААА. Это сразу всю вашу "логику" убивает.
Например, ДНС яндекса - 2a02:6b8::feed:ff на ютуб.ком выдает только
2a00400f:801::200e
Скриншот: https://cloud.mail.ru/public/Zhs4/hupFmNz3S
Поэтому "остальные" получат от сервера свои адреса АААА, вы их правилом отрубите, и доступа никуда ни по какому А не случится.

Erik_U писал(а): ↑11 сен 2024, 13:55 Если в списки ДНС серверов добавлен сервер с адресом IP6, и обращение пошло таки к нему, то он возвращает адрес только АААА. Это сразу всю вашу "логику" убивает.
Например, ДНС яндекса - 2a02:6b8::feed:ff на ютуб.ком выдает только
2a00400f:801::200e
Скриншот: https://cloud.mail.ru/public/Zhs4/hupFmNz3S
Поэтому "остальные" получат от сервера свои адреса АААА, вы их правилом отрубите, и доступа никуда ни по какому А не случится.

Вы в этом прям точно уверены, что Ipv6 DNS возвращает только AAAA записи?



Ладно. Не вижу смысла дальше кому-то что-то доказывать. Считаете что так работать не будет, Ваше дело. Я же пользуюсь без проблем.

Я скриншот приложил с ответом от днс.
И это не единичный случай.
Поэтому уверен, что работать будет точно не так, как вы расчитываете.

А вы получили от днс сервера только А запись, и довольны этим?

eclegolas писал(а): ↑09 сен 2024, 21:45 Подскажите неопытному, "белый айпишник" тот что от интернет провайдера? И "адрес интерфейса тунеля" тот что от РКН провайдера? Вы о них говорите, или я ошибся?

верно и верно:)
формулировка огонь:)

Aiser писал(а): ↑09 сен 2024, 16:50 Сайты (YouTube и т.д.) используют HTTPS, поэтому такие правила будут бесполезны для этих доменов.

Спасибо, попробую.
Но сейчас-то оно работает как-то.. Могу предположить, что сначала отрабатывается запрос днс, адрес после ответа попадает в список, а дальше устанавливается соединение и весь поток пакетов направляется согласно правилу по другой таблице маршрутизации, где нормально отрабатываются и хттп, и хттпс. Но это так, просто предположение, скорее всего неправильное, и работает не потому что, а вопреки:)