Сценарий: У меня есть клиент, использующий Win7 Pro и клиент OpenVPN; эта рабочая станция используется одним из их сотрудников для отправки удаленных команд на сервер OpenVPN (Windows), используя как psexec, так и smb.
Что случилось: Все шло хорошо в течение многих лет, пока их системный администратор не обновил рабочую станцию до Windows 10 Pro. Он полагался на советника по обновлению Windows и просто удалил старый антивирус, который был отмечен как несовместимый. После обновления он добросовестно провел следующие тесты:
-проверьте службу openvpn на клиенте -> запуск
-ping 10.8.0.1 (ip сервера) -> ОК
Так что он, очевидно, думал, что все в порядке.
Поскольку эта рабочая станция используется сотрудником в ночное время, на следующее утро после того, как я был задействован их внутренним системным администратором, поскольку сотрудник не мог отправлять обновления. Он сказал, что ни одна из служб не отправила ответ через vpn, работал только icmp. Сначала я подключил Telnet к портам, которые, как я ожидал, были доступны, и обнаружил, что мгновенное соединение отклонено. Я сделал эхо-запрос и нашел значение TTL в ответе 250!?!? Я сделал следующий tracert:
C:\>tracert -w 100 10.8.0.1
Traccia instradamento verso 10.8.0.1 su un massimo di 30 punti di passaggio
1 3 ms 2 ms 2 ms 192.168.0.4
2 1 ms 2 ms 2 ms 192.168.22.41
3 1 ms 3 ms 1 ms 10.139.59.130
4 5 ms 3 ms 3 ms 10.3.132.113
5 15 ms 13 ms 15 ms 10.254.12.202
6 15 ms 15 ms 15 ms 10.254.1.245
7 27 ms 25 ms 23 ms 10.8.0.1
Когда я впервые посмотрел на это, это было невероятно, но 0,4 - это их внутренний GW по умолчанию, 22,41 - один из их маршрутизаторов, и этот маршрутизатор подключен только к интернет-провайдеру.
Исправление проблемы с Openvpn: Я быстро понял, что в отношении обновления Win10 и клиента openvpn это был просто беспорядок маршрутов, и журналы openvpn подтвердили это, а решение (обновление до последней версии openvpn) исправило это. Я все еще могу пинговать 10.8.0.1 с любого другого компьютера в их сети не работает OpenVPN, если политика маршрутизации устанавливает соединение по этому восходящему каналу 22.41. Если я направлю соединение к любому другому из их 4 (всего 5) восходящих каналов, проблемы не произойдет. Поскольку этот «скажем пиратский» 10.8.0.1 отвечает на каждый порт мгновенными отказами, и все закрыто, я думаю, что это может быть маршрутизатор. Мне просто интересно, нарушает ли интернет-провайдер RFC 1918 или как это возможно, что я могу пинговать ip из пространства частных адресов в общедоступной сети !?
--- Редактировать 2
Вопрос: Поскольку Заказчик считает, что такое неожиданное поведение нанесло ущерб его бизнесу, могут ли он упомянуть какие-либо документы, такие как RFC, в которых говорится, что Интернет-провайдер нарушил какие-либо правила предоставления Интернет-услуг?
RFC1918 Частное адресное пространство МОЖЕТ использоваться провайдером, обычно оно будет прозрачным для клиента, похоже, у них неправильно настроен брандмауэр / ACL, поскольку эти адреса не должны быть видимы для клиента.
Свяжитесь с оператором связи либо через NOC через Net-Whois, либо через службу поддержки клиентов. Мне не известно о каких-либо юридических действиях, которые можно предпринять.
RFC 6598 (100.64.0.0/10) был выделен как пространство CGN / NAT444 для использования провайдерами при переходе на пространство IPv6. Каждый интернет-провайдер занимается своим делом, стандарты - это не законы.
По крайней мере, вы можете настроить брандмауэр клиента так, чтобы неиспользуемое пространство частного провайдера перенаправлялось в глобальную сеть, для чего может потребоваться более совершенный маршрутизатор / брандмауэр или стороннее программное обеспечение (DDRWRT).