Akina

Сталкивался несколько раз.

Чаще всего проблема была в разного рода антивирусах/файрволах.
Реже - в неисправной/нестабильной памяти.
Один раз - в контроллере доступа к диску (который буквально через пару дней умер - по счастью, на матери было два контроллера, второй после этого работал достаточно долго без проблем).
И несколько раз найти причину не удалось.

Рекомендую начать с выполнения той же операции из другого инстанса ОС - просто чтобы понять, аппаратная или программная часть шалит.

А связь-то какая? можно, конечно.

Другой вопрос, как внешние клиенты будут узнавать нужный в текущий кол времени адрес... хотя для этого существуют сервисы динамического DNS. При условии, что Ваш внешний адрес - маршрутизируемый в Интернете (белый), конечно.

Может ли провайдер изменить ... https на http

Внутри своей сети - запросто, хоть на что угодно (нафига бы только ему это?). Но на выходе из своей маршрутизирующей сети ему придётся вернуть всё как было - иначе у тебя с тем сервером, к которому ты обращался, никакой любви в виде соединения не случится.

и снифером словить ваш трафик?

Во-первых, для того, чтобы снифить твой трафик, провайдеру никакой конвертации протоколов не требуется.

Во-вторых, даже если провайдер преобразует трафик из HTTPS в HTTP, это вовсе не означает, что он этот трафик каким-то волшебным образом расшифрует. Как была шифрованная нечитаемая лабуда, так и останется. Так что не жадничай - пусть снифит, если ему заняться нечем, твоих секретов это не раскроет.

Оператор связи / провайдер, согласно договору, предоставляет тебе доступ в Интернет. Но стопудово в договоре нет ни полслова о том, через какой именно шлюз он это сделает. И если провайдеру так проще, дешевле, или просто у него так организовано - он в своём праве. Да вообще ты можешь ходить в Инет через высокоанонимный прокси.

Я уж не говорю о том, что блок адресов выдан LIR-у и изначально описан по его местоположению. И если тот не соизволит уточниться по геопривязке суб-блока (а для своей внутренней сети - нафига бы ему это надо?), то будешь ты думать, что адрес - в штаб-квартире LIR-а, а он на самом деле в тьмутаракани.

1) На микротике проверьте, и при отсутствии разрешите, маршрутизацию из 192.168.0.0/24 в 20.20.20.0/22, если она запрещена (вряд ли, но вдруг...), для 192.168.0.2 или для всей 1925.168.0.0/24 - это по вкусу.
2) На 192.168.0.2 пропишите статический маршрут в 20.20.20.2/32 (или шире, вплоть до 20.20.20.0/22) через 192.168.0.40.
3) Проверьте, что на тплинке LAN-порты не работают в изолированном режиме. Если всё же установлено - отключите.

Всё.

PS. 192.168.20.2/22 - это опечатка?

Если у Вас имеется только одно волокно - Вы ограничены только WDM-модулями. Для одномодового волокна, как Вы сообщаете.

WDM модули передают на одной длине волны, принимают на другой. Соответственно нужна пара модулей, у которых длины волн совпадают "накрест" - один модуль на некоей волне вещает, второй слушает. И наоборот. Если при этом у них ещё и скорости совпадают, то будет между ними мир, трафик и счастье... и, как правило, плевать на вендора, у меня работали (а кое-где и сейчас работают) комплементарные пары самых диких сочетаний.

Не, это ещё пока полдела. SFP-модуль - это достаточно неглупая машинка. И, чтобы она правильно и успешно работала в коммутаторе, она должна быть соотв. образом прошита. И вот тут у меня для Вас плохие новости - если D-Link достаточно "всеядны", и SPF с ними уживаются, как правило, "искаропки", то вот оборудование HP отличается в этом смысле изрядной капризностью. И надо проверять конкретный коммутатор и конкретный SFP - заведётся ли одно в другом, или нет. Но тут либо экспериментально, либо при приобретении чётко указывать, что SFP будет работать в HP.

Чисто теоретически может сработать следующее.

Устанавливаем на комп любой локальный DNS-сервер. В качестве родителя (куда стучаться за разрешением неизвестных адресов) указываем ему регулярный DNS (скажем, провайдерский), прописываем у него статические соответствия (с малым временем актуальности), нужные нам в VPN.

Пока всё как обычно... а вот теперь - фортель. Привязываем его слушать ТОЛЬКО на тот адрес, который указан в настройках VPN, а его самого прописываем ТОЛЬКО в настойках VPN-адаптера.

Что в итоге? Когда VPN-адаптер подключается, этот DNS-сервер ставится в начало очереди (кстати, поэтому, адаптер следует включать после загрузки станции). И соответственно через него идут все разрешения. Если адаптер остановить - этот DNS убирается, и первым становится тот, что в настройках другого адаптера - регулярный провайдерский (или там гугловый фри - неважно). А статические записи о ресурсах в VPN достаточно быстро, за 2-5 минут, будут вымыты из локального кэша.

Ещё разумнее - иметь собственный DNS-сервер в VPN-сети, и указать его в настройках VPN-адаптера. Работать будет так же, только не нужен дополнительный локальный софт.

Свой роутер не поставить, нет оптического порта.

Наличие оптического порта для установки своего роутера не нужно - от слова "совсем". Подключайся по меди.

и настроить на него DMZ

DMZ - не нужен для каких-то там торрентов, и вообще о DMZ следует начинать думать только при наличии реального IP.

Насколько жизнеспособное решение - подключить mikrotik hap ac к провайдерскому роутеру

Нормально, корректное и правильное решение. При этом WiFi на провайдерском роутере лучше всего отключить.

Судя по описанию, на компьютере 2 сетевые карты. И скорее всего у каждой в настройках присутствует шлюз по умолчанию. Так вот - у сетевой карты, которая работает в локальной сети (гигабитной), шлюза по умолчанию быть не должно, вообще, и его нужно в настройках удалить.

Для более точного ответа нужна схема сети и настройки сетевых интерфейсов всех интересующих узлов (компьютера, серверов, ...).

Может по схеме понятней будет

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

Простейшее возможное решение проблемы - выделить каждому серверу ещё одно имя, под этим именем прописать серверы в файле HOSTS (у каждого сервера прописываются только остальные два, себя необязательно), указав в соответствии только адрес из 29-й подсетки. Общение между серверами выполнять только по этим именам. заодно - повысьте метрику сетевой карты из 30 подсети.

У Вас выполняется ARP-запрос, который ограничивается Ethernet-сегментом - т.е. Вы можете с 10.73.0.1 сделать ARP-запрос на 10.73.0.2, но не за пределы Ethernet-сегмента.

Хотите проверить маршрутизацию - используйте более высокоуровневые протоколы. Тот же пинг - вроде для его прохождения всё настроено правильно (впрочем, Вы не показываете сетевые настройки узлов 10.73.0.1 и 172.23.73.3 - но, надеюсь, там дефолтные шлюзы верные).