RDP sicuro al domain controller, raggiungibile solo dalla VPN

Il listener non si aggancia finché non riavvii, e il servizio non si riavvia a mano. Poi una regola di firewall che lascia passare solo la VPN.

Un domain controller è la macchina che meno vuoi raggiungibile e che più hai bisogno di raggiungere. Ecco com’è finita: RDP attivo, ma che risponde solo al traffico che arriva dalla VPN — con due sorprese per strada, una delle quali sembra un servizio rotto.

Abilitarlo, e il riavvio che nessuno annuncia

Server Manager → Local Server → Remote Desktop → Enable, lasciando attiva la NLA.

E poi non funziona.

Restart-Computer -Force

Dopo il riavvio, verifica sul server stesso:

netstat -ano | findstr ":3389"
# atteso: 0.0.0.0:3389 ... LISTENING

Test-NetConnection -ComputerName 127.0.0.1 -Port 3389
# atteso: TcpTestSucceeded : True

Raggiungerlo senza esporlo

Il domain controller non è un nodo della VPN. Ci si arriva tramite un subnet router: un’altra macchina sulla stessa rete che annuncia la subnet alla VPN.

Sul client le rotte vanno accettate esplicitamente — è disattivato per impostazione predefinita, ed è il motivo abituale per cui un subnet router «non funziona»:

tailscale set --accept-routes=true

Poi mstsc verso l’indirizzo privato del server, accesso come DOMINIO\Administrator. In Risorse locali → Altro → Unità condividi un disco: trasferire file dentro la sessione RDP è molto meno faticoso che organizzare una condivisione verso una rete di gestione.

La restrizione che la rende solo-VPN

A questo punto l’RDP funziona da tutta la rete locale, che è più di quanto si voleva. L’obiettivo è: raggiungibile dalla VPN, e non altrimenti.

La scoperta utile è come si presenta il traffico quando arriva.

Verifica

Il traffico che passa da un subnet router arriva SNAT-ato all’indirizzo del router stesso. Dal punto di vista del domain controller ogni connessione VPN sembra venire da una macchina sola — il subnet router — indipendentemente da quale dispositivo l’abbia davvero iniziata.

Verificalo invece di darlo per scontato, con una sessione aperta:

Get-NetTCPConnection -LocalPort 3389 -State Established

L’indirizzo remoto mostrato è quello del subnet router. È su quel singolo indirizzo che si può costruire la regola.

Quindi la restrizione è una riga:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
    Set-NetFirewallRule -RemoteAddress 192.168.50.10

Risultato: l’RDP al domain controller è raggiungibile solo dalla VPN, e non dagli altri dispositivi della rete locale.

Da cosa protegge, e da cosa no

Vale la pena essere precisi, perché è facile esagerare.

Protegge da tutto quello che sta sulla rete locale: un dispositivo IoT, il portatile di un ospite, una postazione compromessa su un’altra VLAN. Nessuno di questi raggiunge più la 3389 sul domain controller, perché il loro indirizzo di origine non è quello consentito.

Due cose da tenere

Un servizio protetto che non si riavvia non è un guasto. TermService che rifiuta di fermarsi sembra qualcosa di rotto. È di progetto, e il riavvio è la strada prevista — meglio saperlo prima di perdere tempo a forzarlo.

Scopri come arriva davvero il traffico prima di scrivere una regola su di esso. Il comportamento SNAT del subnet router era la differenza fra una regola che funziona e una che avrebbe bloccato in silenzio proprio l’accesso che doveva preservare. Un comando, con una sessione aperta, ha risposto.