Le ecureuil

Конечно порт на public-интерфейсе нужно открыть. Его за вас никто не откроет. И не забудьте установить правильный протокол - proto udp или как у вас там.

Если вы используете EoIP как трубу между L2-сегментами, то вы просто обязаны сделать его MTU не меньше, чем минимальный MTU у этих сегментов. То есть скорее всего это будет именно 1500 и скорее всего у вас только путь с фрагментацией - он же 2б.

Ничего не понял. Давайте подробнее, в том числе расставьте пунктуационные знаки.

А security-level у OpenVPN0 какой?

NFS мы реально не поддерживаем в виде компонента прошивки, потому и нет апдейтов. Ядро все же старое, и тащить туда последние изменения очень тяжело. Насчет подержки туннелей - все же мы делаем роутер, а не NAS. Поддержку сетевых компонентов мы будем делать всегда в первую очередь, а диски и накопители... уж насколько останется сил.

Это врядли.

В теории должно работать, только все VLAN на нужном trunk-порту Кинетика должны быть прописаны на роутере по типу interface GigabitEthernet0/3 no switchport access switchport trunk 256 switchport trunk 290 ... и 2-й пункт по идее делать не нужно, vlan-tagged кадры должны прозрачно пройти от EoIP0 сквозь bridge и уйти в тегированном виде в порт. Но не забудьте про суммарное ограничение по MTU у сетевой карты роутера в 1536 байт.

Попробуйте отключить nat loopback.

Надо ставить не равный, а больше текущего.

Строку в вашем конфиге замените на <auth-user-pass> login password </auth-user-pass> И с таким конфигом все должно работать (не забудьте про галочку "получать маршруты от сервера").

Напишите вот это вот все в тему по "Новому Web". Старый трогать уже не будут однозначно, а в новом может и сделают.

Там основные моменты конечно более-менее работают, но спека NFSv4 очень огромная и раздутая. По сравнению с 3.4.0, в 3.4.112 добавлены только совсем критические багфиксы и сильно это ситуацию не улучшило. Сами посмотрите, сколько нам пришлось бы тащить бэкпортов из текущих ядер (там страницы и страницы коммитов с фиксами): https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/fs/nfs/nfs4proc.c Ну и на самом деле большинству полностью хватает NFSv3, она умеет и по TCP, и по UDP, а Kerberos и подобные извращения как-то немного не для дома. У вас есть реальный usecase, где дома NFSv4 лучше?

Да, собрано без NFSv4 и 4.1. Это сделано специально, потому что 3.4 ядро уже достаточно древнее и v4 там реализован очень криво. В современных ядрах ситуация лучше, как будем переходить на них (рано или поздно) - тогда и включим v4.

Каналы ВГТРК там скорее всего из-за так называемых "региональных блоков".

@gaaronk реализовано в 2.11.A.4.0-0.

Это все лирика, ничего не гарантирующая. Берите в руки wireshark и смотрите кто реально вам гадит в сеть.

У вас однозначно проблемы с ARP у этого сервера, и это нужно чинить, а не сканер отключать. Сканер, как мы видим, помог их выявить.

Нет, пока таких настроек нет. Рассмотрим возможность их добавления.

Давно пора на свалку

https://en.wikipedia.org/wiki/TCP_Fast_Open То есть вы понимаете, что у нас просто нет TFO из-за более старого ядра и прикрутить мы его не можем.

Ваши сертификаты подписаны MD5, и новый OpenSSL считает эту подпись слишком слабой - потому и не дает коннекта. Подробности здесь: https://forums.openvpn.net/viewtopic.php?t=23979 Вообще я с ними согласен, неплохо бы перевыпустить сертификаты с SHA256 (SHA1 тоже уже устарел), но в качестве обходного решения попробуйте добавить tls-cipher "DEFAULT:@SECLEVEL=0" в конфиг OpenVPN для обхода ситуации.

Любой трекер с https - и приплыли

С приложенным торрентом на новой версии curl все нормально - качает, соединение с трекером успешное.

Скорее всего причина была в старой версии curl, которая не поддерживает новый OpenSSL. Это поправлено, появится в новой сборке draft.

Приложите любой torrent-файл еще.