Vzdialená plocha cez VPN: v ktorej poruche sa nachádzate?

Tunel beží, interná wiki sa načítava a vzdialená plocha napriek tomu odmieta spojenie. Taká kombinácia je normálna, pretože VPN poskytuje trasu k hostiteľovi, kým služba vzdialenej plochy musí načúvať, byť povolená vlastným firewallom a byť ochotná overiť účet. Medzi funkčným tunelom a použiteľnou reláciou stoja štyri fázy poruchy a každá zlyháva s inou správou. Prečítajte najprv správu, pretože pomenúva fázu.

Štyri poruchy, ktoré vyzerajú ako jedna

Fázy sú zoradené: názov sa preloží na privátnu adresu, ktorú návrh zamýšľa, port odpovedá na TCP handshake, hostiteľ prijme spojenie podľa svojej vlastnej politiky a prihlásenie do relácie uspeje. Každá fáza robí tú nasledujúcu netestovateľnou, a preto zmeny nastavení RDP pred upokojením siete vytvárajú len šum. Príznak vyzerá zo strany používateľa vo všetkých štyroch prípadoch rovnako. Rozdeľuje ich iba správa klienta.

Funkčná interná webová stránka nepreukazuje ani jednu zo štyroch. Preukazuje, že hostiteľ v tej istej sieti odpovedal na inom porte inou službou. Berte to ako dôkaz o smerovaní a nič viac.

Testujte po poradí a výsledok si zapíšte. Skočiť na prihlasovaciu obrazovku, pretože port odpovedal, je spôsob, ako stráviť popoludnie problémom firewallu, ktorý prvý krok už lokalizoval.

Načúva na 3389 niečo?

Začnite názvom, pretože názov, ktorý sa preloží na nesprávnu adresu, zneplatní každý ďalší test. Opýtajte sa resolvera tunela, čo názov znamená, a potom odpoveď porovnajte s privátnou adresou, ktorú návrh zamýšľa, nie s úspešnou odpoveďou. Názov, ktorý sa preloží na verejnú adresu, je celý problém a žiadna zmena RDP ho neopraví:

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

Potom testujte port, nie hostiteľa. Dokončený TCP handshake na 3389 oddeľuje dosiahnuteľnosť od všetkého nad ňou:

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

Vykonajte tento test z LAN aj z tunela, pretože rozdiel medzi oboma výsledkami lokalizuje poruchu na trasu VPN. Na trase stoja dva firewally a ľahko sa zamieňajú: sieť musí povoliť adrese tunela klienta dosiahnuť hostiteľa a vlastný firewall hostiteľa musí povoliť ten istý zdroj na načúvajúcom porte. Pravidlo obmedzené na podsiet LAN nepokrýva fond klientov VPN, a to je najčastejšia príčina časového limitu, ktorý hlásia len vzdialení používatelia. Kontrolujte rozsah, nie existenciu pravidla.

Spätná trasa si zaslúži rovnakú kontrolu. Odpovede potrebujú trasu späť do fondu klientov, nie do LAN, a preklad pred hostiteľom mení zdroj, ktorý ukáže váš log. Ak port odpovedá jedným smerom a druhým nie, chýbajúca polovica je zvyčajne spätná trasa.

Prečítajte správu skôr než konfiguráciu

Tretia fáza je hostiteľ, ktorý spojenie odmietne podľa svojej vlastnej politiky, čo často vyzerá ako port, ktorý sa okamžite otvorí a zavrie. Niečo odpovedalo, a to je užitočná informácia namiesto ticha. Ak sa handshake dokončil a relácia hneď zomrela, sieť je v poriadku a rozhoduje hostiteľ. Pozrite sa na oprávnenia vzdialenej plochy, než znova siahnete na sieť.

Funkcia môže byť pre počítač zapnutá, zatiaľ čo prístup je obmedzený na určité skupiny, a načúvač môže byť zviazaný spôsobmi, ktoré vylučujú adresu, z ktorej ste prišli. Overovanie na úrovni siete pridáva bránu, ktorá zlyhá pred načítaním plochy, a jej text chyby sa líši od nesprávneho hesla. Porovnajte správu klienta s protokolom udalostí hostiteľa, pretože správa pomenúva bránu a protokol účet.

Prihlásenie do relácie je vlastná hranica

Overovanie patrí službe vzdialenej plochy, nie VPN. Identita tunela a účet vzdialenej plochy sú oddelené údaje s oddelenými zásadami uzamknutia, takže funkčný tunel dokazuje len to, že vás tunel prijal. Uzamknutie účtu vzdialenej plochy tunel nenaruší a naopak to platí tiež.

Udržte oboje v celku. Keď chýba privátna trasa, opravte trasu, pretože zverejnenie načúvača na internete vymení chybu dosiahnuteľnosti za vystavenú plochu. Neoslabujte ani kontroly identity relácie, aby ste prešli popri varovaní o certifikáte, ktoré sa objavilo súčasne. Samopodpísaný certifikát na načúvači RDP vydáva varovanie zámerne, takže jeho prijatie je rozhodnutie, nie krok.

Spočítajte pokusy, než to skúsite znova. Prahy uzamknutia plochy počítajú neúspešné prihlásenia oddelene od zlyhaní VPN a klient, ktorý skúša znova podľa časovača, môže prah prekročiť, kým ešte upravujete pravidlo. Je to ten istý mechanizmus paralelných pokusov, ktorý uzamkne účty po zmene hesla.

Čo môže relácia prenášať a kde to zostáva

Naučte sa schválený postup odhlásenia skôr, než ho budete potrebovať. Zatvorenie okna môže len odpojiť zobrazenie, zatiaľ čo relácia beží ďalej podľa nastavenej politiky, čo je dôležité na zdieľanom alebo auditovanom hostiteľovi. Odhláste sa zvnútra relácie, keď to politika očakáva.

Potom rozhodnite, čo smie relácia prenášať, pretože schránka, presmerované disky, presmerovanie tlačiarne a prenos súborov presúvajú dáta medzi miestnym a vzdialeným systémom tam, kde to politika dovoľuje. Publikovaná aplikácia bežiaca na druhej strane nie je automaticky hranicou bez sťahovania a relácia, ktorá vyzerá len na čítanie, môže napriek tomu prenášať schránku. Testujte skutočnú úlohu, nie spojenie: otvorte súbor, použite aplikáciu a potvrďte presmerovanie, ktoré potrebujete. Pokyny Microsoftu na prístup k vzdialenej ploche zvonku opisujú podporované možnosti vystavenia a sú lepším zdrojom než verejný načúvač pridaný pod tlakom.