Cześć,
To zachowanie jest typowe dla DirectAccess, kiedy serwer NLS (Network Location Server) traci lub ma niepoprawnie skonfigurowane powiązanie SSL. Klienci wewnętrzni nie mogą wtedy potwierdzić obecności w sieci lokalnej i zawsze przechodzą na tunel IP‑HTTPS.
Najpierw sprawdź, czy certyfikat SSL dla NLS jest prawidłowo zainstalowany w magazynie Local Computer\Personal i czy jego nazwa CN/FQDN odpowiada dokładnie temu, co skonfigurowane w konsoli Remote Access Management jako adres NLS. Następnie na serwerze uruchom:
Code
netsh http show sslcert
Jeśli nie widzisz wpisu dla portu 443 lub hash certyfikatu jest niepoprawny, musisz odtworzyć powiązanie. Zrób to poleceniem:
Code
netsh http add sslcert ipport=0.0.0.0:443 certhash=<SHA1_Thumbprint> appid={<GUID>}
certhash to odcisk palca certyfikatu, a appid może być dowolnym GUID wygenerowanym np. w PowerShell ([guid]::NewGuid()). Po dodaniu powiązania sprawdź, czy serwer NLS odpowiada poprawnie przez HTTPS i zwraca kod 200.
Ważne jest również, aby w konsoli Remote Access Management adres NLS był zgodny z certyfikatem. Jeśli nazwa w konfiguracji różni się od CN certyfikatu, klienci będą traktować serwer jako niedostępny. Po przywróceniu powiązania i dopasowaniu konfiguracji klienci wewnętrzni powinni ponownie wykrywać obecność w sieci lokalnej i nie wymuszać tunelu IP‑HTTPS.
Domic Vo.