У меня установлен стандартный сервер Windows 2012 R2 с SSTP VPN, который по большей части работает. Мне удалось подключиться к этой VPN с внешнего компьютера и использовать все правильно.
Проблема возникает, когда сервер перестает прослушивать порт 443, как показано ниже:
Я думал, что « d можно будет просто перезапустить RRAS и заставить его снова начать прослушивание порта 443:
Но, похоже, это не работает. Все перезагружается правильно, но не возобновляет прослушивание порта 443. Вот снимок Running
служб, относящихся к VPN / удаленному доступу.
Несколько забавный аспект этого заключается в том, что я сейчас нахожусь удаленный, пока я пишу это, и мне пришлось прибегнуть к использованию удаленного рабочего стола для диагностики этой проблемы, и если я не смогу понять это, мне придется перезапустить сервер, чтобы он снова начал прослушивание порт 443. Я, очевидно, не хочу этого делать, так как это нарушает работу офиса, а также является плохой идеей.
Я нашел следующие записи из журнала событий, которые кажутся имеющими отношение к этой проблеме, но я не уверен. Их довольно много.
ID:
36888
Уровень серьезности:Ошибка
Источник:Schannel
Журнал:Система
Было создано и отправлено на удаленную конечную точку фатальное предупреждение. Это может привести к разрыву соединения. Определенный протокол TLS код фатальной ошибки - 10. Состояние ошибки Windows SChannel - 1203.
и
ID:
8016
Уровень серьезности:Предупреждение
Источник:Microsoft-Windows-DNS Client События
Журнал:Система
Системе не удалось зарегистрировать записи ресурсов (RR) хоста (A или AAAA) для сетевого адаптера с настройками:
Имя адаптера: {B34E76CF ...} Имя хоста:
Суффикс основного домена: Список DNS-серверов: :: 1, 192.168.0.1 Отправлено обновление на сервер: > IP-адрес (а): 192.168.0.166 Причина, по которой система не могла зарегистрировать эти записи RR, заключалась в том, что DNS сервер не смог выполнить запрос на обновление. Наиболее вероятная причина этого что авторитетный DNS-сервер требуется для обработки этого обновления запрос имеет блокировку в зоне, вероятно, потому что зона выполняется передача.
Вы можете вручную повторить DNS-регистрацию сетевого адаптера и его настройки, набрав
ipconfig / registerdns
в командной строке. Если проблемы все еще сохраняются, обратитесь к своему DNS-серверу или сетевым системам администратор.
Я купил сертификат Comodo для своего VPN-домена, который привязывается, когда я перехожу к свойствам сервера RRAS:
Я также перешел в раздел реестра HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ SstpSvc \ Parameters
и видно, что хэши SHA, похоже, соответствуют моему связанному сертификату:
Я пытаюсь выяснить:
Надеюсь, я включил достаточно информации, если я что-то упустил, дайте мне знать. Имейте в виду, что все в моих настройках работает, если сервер прослушивает порт 443. Вот почему я не совсем понимаю, что происходит.
Edit # 1 @ 21-07-21 10 : 13 PM UTC
Некоторое дополнительное исследование показало мне, что служба, отвечающая за прослушивание порта 443 ( SstpSvc
), работает, когда я сталкиваюсь с описанными выше проблемами. Его перезапуск не решает проблем. Я не вижу ошибок в средстве просмотра событий для этой службы при перезапуске.
Можно ли настроить параметры восстановления для службы, чтобы она просто перезапускалась при завершении работы?
Существует вероятность того, что она отключится из-за бездействия. (Я просто беру здесь службу телефонии, чтобы показать настройки) Установите дни на 0 и минуты на 1, чтобы произошел перезапуск.
Ваш вопрос является наиболее исчерпывающим, поэтому я предоставлю здесь свой вклад.
По результатам моего тестирования в Windows Server 2012 R2 я могу восстановить эту функциональность без перезагрузки, выполнив следующие действия:
Перезапустить w3svc
Перезапустить sstpsvc
К сожалению, вам нужно принудительно перезапустить sstpsvc, что также требует перезапуска маршрутизации и удаленного доступа, эффективно отключая пользователей. Гораздо быстрее перезапускается, чем полная перезагрузка, но, к сожалению, все еще прерывается.
Если вы хотите написать сценарий с помощью PowerShell, вы можете:
Restart-Service -Name w3svc
Restart-Service -Name sstpsvc -Force
У меня есть мониторинг, поэтому, возможно, я смогу определить, почему это происходит. Моя текущая теория состоит в том, что w3svc управляет TLS для сеансов SSTP, и он перестает работать в процессе.