El túnel està actiu, el wiki intern es carrega i l'escriptori remot continua negant-se a connectar. Aquesta combinació és normal, perquè la VPN proporciona una ruta fins a l'amfitrió mentre el servei d'escriptori ha d'estar escoltant, permès pel seu propi tallafoc i disposat a autenticar el compte. Quatre etapes de fallada separen un túnel funcional d'una sessió utilitzable, i cadascuna falla amb un missatge diferent. Llegeix primer el missatge, perquè anomena l'etapa.

Quatre fallades que semblen una

Les etapes estan ordenades: el nom es resol a l'adreça privada que el disseny pretén, el port respon a un handshake TCP, l'amfitrió accepta la connexió segons la seva pròpia política i l'inici de sessió té èxit. Cada etapa fa que la següent no es pugui provar, i per això canviar la configuració d'RDP abans que la xarxa estigui resolta només produeix soroll. El símptoma sembla idèntic des del costat de l'usuari en els quatre casos. Només el missatge del client els separa.

Un lloc web intern funcional no demostra cap de les quatre coses. Demostra que un amfitrió de la mateixa xarxa ha respost en un port diferent amb un servei diferent. Tracta-ho com a evidència sobre l'encaminament i res més.

Prova-ho per ordre i anota el resultat. Saltar a la pantalla d'inici de sessió perquè el port ha respost és com es perd una tarda en un problema de tallafoc que el primer pas ja ha localitzat.

Hi ha res escoltant al 3389?

Comença pel nom, perquè un nom que es resol a l'adreça equivocada invalida totes les proves posteriors. Pregunta al resoledor del túnel què significa el nom i després compara la resposta amb l'adreça privada que el disseny pretén, no amb una resposta correcta. Un nom que es resol a una adreça pública és tot el problema, i cap canvi d'RDP el resoldrà:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Després prova el port, no l'amfitrió. Un handshake TCP complet al 3389 separa l'abast de tot el que hi ha a sobre:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Fes aquesta prova des de la LAN i des del túnel, perquè una diferència entre els dos resultats localitza la fallada a la ruta de la VPN. A la ruta hi ha dos tallafocs i és fàcil confondre'ls: la xarxa ha de permetre que l'adreça del túnel del client arribi a l'amfitrió, i el tallafoc propi de l'amfitrió ha de permetre aquesta mateixa font al port que escolta. Una regla limitada a la subxarxa LAN no cobreix el pool de clients VPN, i és la causa més comuna d'un temps d'espera que només reporten els usuaris remots. Comprova l'abast, no l'existència de la regla.

La ruta de retorn mereix la mateixa comprovació. Les respostes necessiten una ruta de tornada cap al pool de clients i no cap a la LAN, i una traducció davant de l'amfitrió canvia la font que mostrarà el teu registre. Si el port respon en una direcció i no en l'altra, la meitat que falta sol ser la ruta de retorn.

Llegeix el missatge abans de llegir la configuració

La tercera etapa és l'amfitrió que rebutja la connexió segons la seva pròpia política, cosa que sovint sembla un port que s'obre i es tanca immediatament. Alguna cosa ha respost, i això és informació útil i no silenci. Si el handshake s'ha completat i la sessió ha mort de seguida, la xarxa està bé i decideix l'amfitrió. Revisa els permisos de l'escriptori remot abans de tornar a tocar la xarxa.

La funció pot estar activada per a la màquina mentre l'accés es limita a grups concrets, i l'escoltador pot estar lligat de maneres que exclouen l'adreça des de la qual has arribat. L'autenticació de nivell de xarxa afegeix una porta que falla abans que es carregui l'escriptori, i el seu text d'error és diferent del d'una contrasenya incorrecta. Compara el missatge del client amb el registre d'esdeveniments de l'amfitrió, perquè el missatge anomena la porta i el registre anomena el compte.

L'inici de sessió és una frontera pròpia

L'autenticació pertany al servei d'escriptori, no a la VPN. La identitat del túnel i el compte de l'escriptori són credencials separades amb polítiques de bloqueig separades, així que un túnel funcional només demostra que el túnel t'ha acceptat. Bloquejar el compte de l'escriptori no altera el túnel, i el contrari també és cert.

Mantingues tots dos intactes. Quan falta la ruta privada, arregla la ruta, perquè publicar l'escoltador a internet canvia un error d'abast per un escriptori exposat. Tampoc no debilitis les comprovacions d'identitat de la sessió per passar un avís de certificat que ha aparegut al mateix temps. Un certificat autosignat en un escoltador RDP produeix un avís per disseny, així que acceptar-lo és una decisió i no un pas.

Compta els intents abans de reintentar. Els llindars de bloqueig de l'escriptori compten els inicis de sessió fallits per separat de les fallades de la VPN, i un client que reintenta amb temporitzador pot superar el llindar mentre encara estàs editant una regla. És el mateix mecanisme de reintents paral·lels que bloqueja comptes després d'un canvi de contrasenya.

Què pot moure la sessió i on es queda

Aprèn el flux de tancament de sessió aprovat abans de necessitar-lo. Tancar la finestra pot només desconnectar la vista mentre la sessió continua executant-se segons la seva política configurada, cosa que importa en un amfitrió compartit o auditat. Tanca la sessió des de dins quan la política ho espera.

Després decideix què pot portar la sessió, perquè el porta-retalls, les unitats redirigides, la redirecció d'impressores i la transferència de fitxers mouen dades entre els sistemes local i remot on la política ho permet. Una aplicació publicada que s'executa a l'altre costat no és automàticament una frontera sense descàrregues, i una sessió que sembla només de lectura pot portar igualment un porta-retalls. Prova la tasca real i no la connexió: obre el fitxer, utilitza l'aplicació i confirma la redirecció que necessites. Les indicacions de Microsoft per arribar a un escriptori remot des de fora descriuen les opcions d'exposició suportades, i són una referència millor que un escoltador públic afegit sota pressió.

Articles relacionats