Uw tunnel staat, de interne wiki laadt, en Extern bureaublad weigert nog steeds te verbinden. Die combinatie is normaal, omdat de VPN een route naar de host levert terwijl de bureaubladservice moet luisteren, door zijn eigen firewall moet zijn toegestaan en bereid moet zijn het account te authenticeren. Vier faalfases liggen tussen een werkende tunnel en een bruikbare sessie, en elk faalt met een andere melding. Lees eerst de melding, want die noemt de fase.

Vier fouten die op één lijken

De fasen zijn geordend: de naam resolvet naar het privéadres dat het ontwerp beoogt, de poort antwoordt op een TCP-handshake, de host accepteert de verbinding volgens zijn eigen beleid en de sessieaanmelding slaagt. Elke fase maakt de volgende ontestbaar, waardoor het wijzigen van RDP-instellingen voordat het netwerk is geregeld alleen ruis oplevert. Het symptoom ziet er aan de kant van de gebruiker in alle vier gevallen identiek uit. Alleen de melding van de client scheidt ze.

Een werkende interne website bewijst geen van de vier. Ze bewijst dat een host op hetzelfde netwerk op een andere poort met een andere dienst antwoordde. Beschouw dat als bewijs over routing en niets meer.

Test op volgorde en schrijf het resultaat op. Naar het aanmeldscherm springen omdat de poort antwoordde, is de manier om een middag te verliezen aan een firewallprobleem dat de eerste stap al had gelokaliseerd.

Luistert er iets op 3389?

Begin met de naam, want een naam die naar het verkeerde adres resolvet, maakt elke latere test ongeldig. Vraag de resolver van de tunnel wat de naam betekent en vergelijk het antwoord daarna met het privéadres dat het ontwerp beoogt, niet met een geslaagd antwoord. Een naam die naar een openbaar adres resolvet, is het hele probleem, en geen enkele RDP-wijziging lost het op:

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

Test daarna de poort in plaats van de host. Een voltooide TCP-handshake op 3389 scheidt bereikbaarheid van alles daarboven:

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

Voer die test uit vanaf het LAN en vanaf de tunnel, want een verschil tussen beide resultaten lokaliseert de fout op het VPN-pad. Er liggen twee firewalls op het pad en ze zijn makkelijk te verwarren: het netwerk moet het tunneladres van de client toestaan de host te bereiken, en de eigen firewall van de host moet dezelfde bron op de luisterende poort toestaan. Een regel die beperkt is tot het LAN-subnet dekt de VPN-clientpool niet, en dat is de meest voorkomende oorzaak van een time-out die alleen externe gebruikers melden. Controleer de reikwijdte, niet het bestaan van de regel.

De terugweg verdient dezelfde controle. Antwoorden hebben een route terug naar de clientpool nodig, niet naar het LAN, en een vertaling vóór de host verandert de bron die uw log toont. Als de poort in één richting antwoordt en in de andere niet, is de ontbrekende helft meestal de terugweg.

Lees de melding voordat u de configuratie leest

De derde fase is de host die de verbinding volgens zijn eigen beleid weigert, wat er vaak uitziet als een poort die direct opengaat en sluit. Iets antwoordde, en dat is nuttige informatie in plaats van stilte. Als de handshake is voltooid en de sessie meteen stierf, is het netwerk in orde en beslist de host. Bekijk de machtigingen voor Extern bureaublad voordat u het netwerk opnieuw aanraakt.

De functie kan voor de machine zijn ingeschakeld terwijl de toegang tot specifieke groepen beperkt is, en de listener kan zo zijn gebonden dat het adres waarvan u kwam wordt uitgesloten. Netwerkniveau-verificatie voegt een poort toe die faalt voordat het bureaublad laadt, en de fouttekst verschilt van een verkeerd wachtwoord. Vergelijk de melding van de client met het gebeurtenislogboek van de host, want de melding noemt de poort en het logboek het account.

Sessieaanmelding is een eigen grens

Verificatie hoort bij de bureaubladservice, niet bij de VPN. De identiteit van de tunnel en het bureaubladaccount zijn gescheiden referenties met gescheiden vergrendelingsbeleid, dus een werkende tunnel bewijst alleen dat de tunnel u heeft geaccepteerd. Het bureaubladaccount vergrendelen stoort de tunnel niet, en het omgekeerde geldt ook.

Houd beide intact. Ontbreekt de privéroute, repareer dan de route, want de listener op internet publiceren ruilt een bereikbaarheidsfout in voor een blootgesteld bureaublad. Verzwak ook de identiteitscontroles van de sessie niet om een certificaatwaarschuwing te omzeilen die tegelijkertijd verscheen. Een zelfondertekend certificaat op een RDP-listener geeft naar zijn aard een waarschuwing, dus het accepteren daarvan is een beslissing en geen stap.

Tel de pogingen voordat u het opnieuw probeert. Vergrendelingsdrempels van het bureaublad tellen mislukte aanmeldingen apart van VPN-fouten, en een client die op een timer opnieuw probeert kan de drempel overschrijden terwijl u nog een regel bewerkt. Dat is hetzelfde parallelle herhaalmechanisme dat accounts na een wachtwoordwijziging vergrendelt.

Wat de sessie kan verplaatsen, en waar het blijft

Leer de goedgekeurde afmeldingsworkflow voordat u die nodig hebt. Het venster sluiten verbreekt mogelijk alleen de weergave terwijl de sessie volgens zijn geconfigureerde beleid blijft draaien, wat op een gedeelde of geauditeerde host uitmaakt. Meld u binnen de sessie af wanneer het beleid dat verwacht.

Bepaal daarna wat de sessie mag dragen, want klembord, omgeleide schijven, printeromleiding en bestandsoverdracht verplaatsen gegevens tussen de lokale en externe systemen waar het beleid dat toestaat. Een gepubliceerde toepassing die aan de andere kant draait is niet automatisch een grens zonder download, en een sessie die alleen-lezen lijkt kan nog steeds een klembord dragen. Test de echte taak in plaats van de verbinding: open het bestand, gebruik de toepassing en bevestig de omleiding die u nodig hebt. De Microsoft-richtlijnen om een extern bureaublad van buitenaf te bereiken beschrijven de ondersteunde blootstellingsopties, en ze zijn een betere referentie dan een openbare listener die onder druk is toegevoegd.

Gerelateerde artikelen