Всем привет! Я использую RBwAPGR-5HacD2HnD в качестве домашнего интернет-роутера, подключённого через LTE. Чтобы обойти всю эту тоску с двойным NAT от LTE, я ещё настроил WireGuard, чтобы весь трафик с роутера уходил в VPN на мой pfsense с публичным IP. Всё крутейше работает — сайты летят без нареканий, жизнь прекрасна и так далее. Теперь хочу добавить в эту схему HD HomeRun TV-тюнер, который находится в другом месте. Проблема в том, что эти тюнеры «считаются» теми, под которые большинство приложений не работают при наличии L3-прыжка — их задумывали и проектировали для работы в одной локальной сети с устройством, которое ими пользуется.
У меня валялся старый роутер Mikrotik, и я решил протянуть между ними EoIP-туннель (без дополнительного шифрования, ведь устройство физически подключено к «безопасной» физической LAN, которая уже зашифрована WireGuard с pfsense, так что всё, что потенциально нужно — уже в крипте). Собрал EoIP-туннель, добавил его в бридж вместе с ether1 на домашнем конце, и на удалённом Mikrotik сделал бридж с портами для HDHR. Настроил — HDHR, подключённый к удалённому Mikrotik, получает IP от DHCP домашнего Mikrotik, страницы HDHR в браузере открываются с IP из LAN — всё выглядит многообещающе, но пока не идеально: автодетект в Jellyfin не срабатывает, и при просмотре 1080p видео постоянно подвисает, хотя на меньших разрешениях всё пашет отлично. При этом трафик в пределах норм для 720p и 1080p, ограничения по пропускной способности исключаю.
Странность в том, что некоторые сайты дома перестали нормально работать. Три конкретных примера: bankofamerica.com, yahoo.com и duckduckgo.com. Если убрать интерфейс EoIP из бриджа дома — всё начинает работать как часы, остальные сайты, которые я тестировал, тоже норм (хотя некоторые грузятся чуть медленнее, но у меня нет точных данных). Другие домочадцы отмечали, что «интернет как-то странно себя ведёт», но деталей не смогли дать. Убрал EoIP из бриджа — сразу всё вернулось на круги своя.
Первым делом мне подумалось, что это может быть проблема с MTU. Такое ощущение, что большие пакеты не проходят (особенно странные заикания потока 1080p через EoIP — думаю, отбрасывается пакет, превышающий MTU). Раньше уже боролся с подобными проблемами, и это очень на MTU похоже, но могу ошибаться. В любом случае провёл кучу тестов, сосредоточившись на MTU. Заметил, что у интерфейса EoIP реальный MTU — 1378. В бридже MTU разное: Actual MTU меняется на 1378, когда туннель EoIP включён в бридж, и возвращается к 1500, когда нет; при этом L2 MTU — 1598. Пробовал вручную ставить MTU 1378 — без изменений.
Дальше пробовал определять MTU вручную через ping с DF (Don't Fragment) и выяснил, что для интернет-трафика MTU ограничен 1420 из-за WireGuard. Забавно, что при MTU 1378 на EoIP я пинганул HDHR с эффективным MTU 1500! И ещё: когда Actual MTU в бридже был 1378 (EoIP включён), MTU до 1.1.1.1 не менялась.
Теперь я в замешательстве. Я совсем не ожидал, что смогу пинговать HDHR с MTU 1500 через EoIP и WireGuard! Особенно учитывая, что через один только WireGuard у меня MTU 1420. Также думал, что сайты по TCP не выставляют флаг DF, пакеты бы фрагментировались и всё бы работало.
Пока не знаю, что дальше делать. Кажется, решение должно быть, а тестовые случаи противоречивы. Есть идеи, как выкрутиться? Раньше я на ubnt gear настраивал VPN с ipsec и openvpn в tap-режиме с MSS clamping и ещё чем-то, чтобы заставить фрагментировать, когда нужно — через это нормально проходили multicast и UDP, которые ловили проблемы с MTU. Не уверен, как аналогично сделать здесь и правильно ли это вообще решение.
Спасибо за помощь!
У меня валялся старый роутер Mikrotik, и я решил протянуть между ними EoIP-туннель (без дополнительного шифрования, ведь устройство физически подключено к «безопасной» физической LAN, которая уже зашифрована WireGuard с pfsense, так что всё, что потенциально нужно — уже в крипте). Собрал EoIP-туннель, добавил его в бридж вместе с ether1 на домашнем конце, и на удалённом Mikrotik сделал бридж с портами для HDHR. Настроил — HDHR, подключённый к удалённому Mikrotik, получает IP от DHCP домашнего Mikrotik, страницы HDHR в браузере открываются с IP из LAN — всё выглядит многообещающе, но пока не идеально: автодетект в Jellyfin не срабатывает, и при просмотре 1080p видео постоянно подвисает, хотя на меньших разрешениях всё пашет отлично. При этом трафик в пределах норм для 720p и 1080p, ограничения по пропускной способности исключаю.
Странность в том, что некоторые сайты дома перестали нормально работать. Три конкретных примера: bankofamerica.com, yahoo.com и duckduckgo.com. Если убрать интерфейс EoIP из бриджа дома — всё начинает работать как часы, остальные сайты, которые я тестировал, тоже норм (хотя некоторые грузятся чуть медленнее, но у меня нет точных данных). Другие домочадцы отмечали, что «интернет как-то странно себя ведёт», но деталей не смогли дать. Убрал EoIP из бриджа — сразу всё вернулось на круги своя.
Первым делом мне подумалось, что это может быть проблема с MTU. Такое ощущение, что большие пакеты не проходят (особенно странные заикания потока 1080p через EoIP — думаю, отбрасывается пакет, превышающий MTU). Раньше уже боролся с подобными проблемами, и это очень на MTU похоже, но могу ошибаться. В любом случае провёл кучу тестов, сосредоточившись на MTU. Заметил, что у интерфейса EoIP реальный MTU — 1378. В бридже MTU разное: Actual MTU меняется на 1378, когда туннель EoIP включён в бридж, и возвращается к 1500, когда нет; при этом L2 MTU — 1598. Пробовал вручную ставить MTU 1378 — без изменений.
Дальше пробовал определять MTU вручную через ping с DF (Don't Fragment) и выяснил, что для интернет-трафика MTU ограничен 1420 из-за WireGuard. Забавно, что при MTU 1378 на EoIP я пинганул HDHR с эффективным MTU 1500! И ещё: когда Actual MTU в бридже был 1378 (EoIP включён), MTU до 1.1.1.1 не менялась.
Теперь я в замешательстве. Я совсем не ожидал, что смогу пинговать HDHR с MTU 1500 через EoIP и WireGuard! Особенно учитывая, что через один только WireGuard у меня MTU 1420. Также думал, что сайты по TCP не выставляют флаг DF, пакеты бы фрагментировались и всё бы работало.
Пока не знаю, что дальше делать. Кажется, решение должно быть, а тестовые случаи противоречивы. Есть идеи, как выкрутиться? Раньше я на ubnt gear настраивал VPN с ipsec и openvpn в tap-режиме с MSS clamping и ещё чем-то, чтобы заставить фрагментировать, когда нужно — через это нормально проходили multicast и UDP, которые ловили проблемы с MTU. Не уверен, как аналогично сделать здесь и правильно ли это вообще решение.
Спасибо за помощь!
