Afgeleë lessenaar deur 'n VPN: in watter fout sit jy?

Jou tonnel is op, die interne wiki laai, en die afgeleë lessenaar weier steeds om te verbind. Daardie kombinasie is normaal, want die VPN verskaf 'n roete na die gasheer, terwyl die lessenaardiens moet luister, deur sy eie vuurmuur toegelaat moet word en die rekening moet wil verifieer. Vier foutstadia lê tussen 'n werkende tonnel en 'n bruikbare sessie, en elkeen misluk met 'n ander boodskap. Lees eers die boodskap, want dit noem die stadium.

Vier foute wat soos een lyk

Die stadia is georden: die naam los op na die private adres wat die ontwerp beoog, die poort antwoord op 'n TCP-handdruk, die gasheer aanvaar die verbinding onder sy eie beleid, en die sessie-aanmelding slaag. Elke stadium maak die volgende onmoontlik om te toets, en daarom veroorsaak veranderinge aan RDP-instellings voordat die netwerk reg is net geraas. Die simptoom lyk uit die gebruiker se oogpunt in al vier gevalle identies. Net die kliënt se boodskap skei hulle.

'n Werkende interne webwerf bewys nie een van die vier nie. Dit bewys dat 'n gasheer op dieselfde netwerk op 'n ander poort met 'n ander diens geantwoord het. Behandel dit as bewyse oor roetering en niks meer nie.

Toets in volgorde en skryf die resultaat neer. Om na die aanmeldskerm te spring omdat die poort geantwoord het, is hoe 'n middag verlore gaan aan 'n vuurmuurprobleem wat die eerste stap al opgespoor het.

Luister iets op 3389?

Begin by die naam, want 'n naam wat na die verkeerde adres oplos, maak elke latere toets ongeldig. Vra die tonnel se oplosser wat die naam beteken en vergelyk dan die antwoord met die private adres wat die ontwerp beoog, nie met 'n suksesvolle reaksie nie. 'n Naam wat na 'n openbare adres oplos, is die hele probleem, en geen RDP-verandering sal dit regstel nie:

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

Toets dan die poort eerder as die gasheer. 'n Voltooide TCP-handdruk op 3389 skei bereikbaarheid van alles daarbo:

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

Voer daardie toets van die LAN en van die tonnel af uit, want 'n verskil tussen die twee resultate plaas die fout op die VPN-roete. Twee vuurmure sit in die roete en hulle is maklik om te verwar: die netwerk moet die kliënt se tonneladres toelaat om die gasheer te bereik, en die gasheer se eie vuurmuur moet dieselfde bron op die luisterende poort toelaat. 'n Reël wat op die LAN-subnet gemik is, dek nie die VPN-kliëntpoel nie, en dit is die algemeenste oorsaak van 'n time-out wat net afgeleë gebruikers rapporteer. Kyk na die omvang eerder as die bestaan van die reël.

Die terugroete verdien dieselfde tjek. Antwoorde het 'n roete terug na die kliëntpoel nodig eerder as na die LAN, en 'n vertaling voor die gasheer verander die bron wat jou log sal wys. As die poort in een rigting antwoord en nie in die ander nie, is die ontbrekende helfte gewoonlik die terugroete.

Lees die boodskap voordat jy die konfigurasie lees

Die derde stadium is die gasheer wat die verbinding volgens sy eie beleid weier, wat dikwels lyk soos 'n poort wat onmiddellik oopgaan en toegaan. Iets het geantwoord, en dit is nuttige inligting eerder as stilte. As die handdruk voltooi is en die sessie dadelik dood is, is die netwerk reg en beslis die gasheer. Kyk na die toestemmings vir die afgeleë lessenaar voordat jy weer aan die netwerk raak.

Die funksie kan vir die masjien geaktiveer wees terwyl toegang tot spesifieke groepe beperk is, en die luisteraar kan op maniere gebind wees wat die adres waarop jy aangekom het, uitsluit. Netwerkvlak-verifikasie voeg 'n hek by wat misluk voordat die lessenaar laai, en sy foutteks verskil van 'n verkeerde wagwoord. Vergelyk die kliënt se boodskap met die gasheer se gebeurtenislog, want die boodskap noem die hek en die log noem die rekening.

Sessie-aanmelding is sy eie grens

Verifikasie hoort by die lessenaardiens, nie by die VPN nie. Die tonnel se identiteit en die lessenaarrekening is aparte geloofsbriewe met aparte uitsluitingsbeleide, dus 'n werkende tonnel bewys net dat die tonnel jou aanvaar het. Om die lessenaarrekening te sluit, versteur nie die tonnel nie, en die omgekeerde is ook waar.

Hou albei ongeskonde. Wanneer die private roete ontbreek, maak die roete reg, want om die luisteraar aan die internet bekend te maak, ruil 'n bereikbaarheidsfout vir 'n blootgestelde lessenaar. Moet ook nie die sessie se identiteitstoetse verswak om verby 'n sertifikaatwaarskuwing te kom wat terselfdertyd verskyn het nie. 'n Selfondertekende sertifikaat op 'n RDP-luisteraar produseer per ontwerp 'n waarskuwing, so om dit te aanvaar is 'n besluit eerder as 'n stap.

Tel die pogings voordat jy weer probeer. Lessenaar-uitsluitdrempels tel mislukte aanmeldings apart van VPN-mislukkings, en 'n kliënt wat op 'n tydhouer weer probeer, kan die drempel oortree terwyl jy nog aan 'n reël werk. Dit is dieselfde parallelle herprobeermeganisme wat rekeninge ná 'n wagwoordverandering sluit.

Wat die sessie kan beweeg, en waar dit bly

Leer die goedgekeurde afmeldingswerkvloei voordat jy dit nodig het. Om die venster te sluit, mag net die aansig ontkoppel terwyl die sessie onder sy gekonfigureerde beleid aanhou loop, wat op 'n gedeelde of geouditeerde gasheer saak maak. Meld binne die sessie af wanneer die beleid dit verwag.

Besluit dan wat die sessie mag dra, want knipbord, herleide skywe, drukkerherleiding en lêeroordrag beweeg almal data tussen die plaaslike en afgeleë stelsels waar beleid dit toelaat. 'n Gepubliseerde toepassing wat aan die oorkant loop, is nie outomaties 'n geen-aflaai-grens nie, en 'n sessie wat net-lees lyk, kan steeds 'n knipbord dra. Toets die werklike taak eerder as die verbinding: maak die lêer oop, gebruik die toepassing en bevestig die herleiding wat jy nodig het. Die Microsoft-riglyne oor hoe om 'n afgeleë lessenaar van buite te bereik beskryf die ondersteunde blootstellingsopsies, en dit is 'n beter verwysing as 'n openbare luisteraar wat onder druk bygevoeg is.