Távoli asztal VPN-en keresztül: melyik hibában van?

Az alagút működik, a belső wiki betöltődik, a távoli asztal mégis megtagadja a kapcsolódást. Ez a kombináció normális, mert a VPN útvonalat ad a gazdagéphez, miközben az asztalszolgáltatásnak figyelnie kell, a saját tűzfalának engedélyeznie kell, és készen kell állnia a fiók hitelesítésére. Négy hibaállapot van egy működő alagút és egy használható munkamenet között, és mindegyik más üzenettel bukik el. Először az üzenetet olvassa el, mert az nevezi meg a szakaszt.

Négy hiba, amely egynek látszik

A szakaszok sorrendben vannak: a név arra a privát címre oldódik fel, amelyet a tervezés szán, a port válaszol a TCP kézfogásra, a gazdagép saját házirendje szerint fogadja a kapcsolatot, és a munkamenet-bejelentkezés sikerül. Minden szakasz vizsgálhatatlanná teszi a következőt, ezért az RDP-beállítások módosítása a hálózat rendezése előtt csak zajt kelt. A tünet a felhasználó oldaláról mind a négy esetben azonosnak látszik. Csak az ügyfél üzenete választja szét őket.

Egy működő belső webhely egyiket sem bizonyítja a négy közül. Azt bizonyítja, hogy egy gazdagép ugyanazon a hálózaton más porton, más szolgáltatással válaszolt. Tekintse ezt az útválasztásra vonatkozó bizonyítéknak, és semmi másnak.

Sorrendben teszteljen, és írja le az eredményt. A bejelentkező képernyőre ugrani azért, mert a port válaszolt, pontosan az a módja, hogy egy délutánt egy olyan tűzfalproblémára pazaroljon, amelyet az első lépés már megtalált.

Figyel-e valami a 3389-es porton?

Kezdje a névvel, mert a rossz címre feloldódó név érvényteleníti az összes későbbi tesztet. Kérdezze meg az alagút feloldóját, mit jelent a név, majd hasonlítsa össze a választ azzal a privát címmel, amelyet a tervezés szán, és ne egy sikeres válasszal. A nyilvános címre feloldódó név maga a teljes probléma, és semmilyen RDP-változtatás nem javítja meg:

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

Utána a portot tesztelje, ne a gazdagépet. A 3389-en befejezett TCP kézfogás elválasztja az elérhetőséget mindattól, ami fölötte van:

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

Futtassa ezt a tesztet a LAN-ból és az alagútból, mert a két eredmény közötti különbség a VPN-útvonalra lokalizálja a hibát. Két tűzfal van az útvonalon, és könnyű összekeverni őket: a hálózatnak engedélyeznie kell, hogy az ügyfél alagútcíme elérje a gazdagépet, a gazdagép saját tűzfalának pedig engedélyeznie kell ugyanazt a forrást a figyelő porton. A LAN-alhálózatra korlátozott szabály nem fedi le a VPN-ügyfélkészletet, és ez a leggyakoribb oka annak az időtúllépésnek, amelyről csak a távoli felhasználók számolnak be. A szabály hatókörét ellenőrizze, nem a létezését.

A visszaút ugyanazt az ellenőrzést érdemli. A válaszoknak visszaút kell az ügyfélkészlethez, nem a LAN-hoz, és a gazdagép előtti fordítás megváltoztatja azt a forrást, amelyet a napló mutatni fog. Ha a port az egyik irányban válaszol, a másikban nem, a hiányzó fél általában a visszaút.

Olvassa el az üzenetet, mielőtt a konfigurációt olvassa

A harmadik szakasz a gazdagép, amely saját házirendje szerint utasítja el a kapcsolatot, ami gyakran úgy néz ki, mint egy port, amely azonnal kinyílik és bezárul. Valami válaszolt, és ez hasznos információ a csend helyett. Ha a kézfogás befejeződött és a munkamenet azonnal meghalt, a hálózat rendben van, és a gazdagép dönt. Nézze meg a távoli asztal engedélyeit, mielőtt újra hozzányúl a hálózathoz.

A funkció engedélyezett lehet a géphez, miközben a hozzáférés adott csoportokra korlátozódik, és a figyelő olyan módon lehet kötve, amely kizárja azt a címet, ahonnan jött. A hálózati szintű hitelesítés olyan kaput ad hozzá, amely az asztal betöltése előtt elbukik, és hibaüzenete eltér a rossz jelszóétól. Hasonlítsa össze az ügyfél üzenetét a gazdagép eseménynaplójával, mert az üzenet a kaput, a napló pedig a fiókot nevezi meg.

A munkamenet-bejelentkezés a saját határa

A hitelesítés az asztalszolgáltatásé, nem a VPN-é. Az alagút identitása és az asztalfiók külön hitelesítő adatok külön zárolási házirendekkel, ezért egy működő alagút csak azt bizonyítja, hogy az alagút elfogadta Önt. Az asztalfiók zárolása nem zavarja az alagutat, és fordítva is igaz.

Tartsa mindkettőt érintetlenül. Ha hiányzik a privát útvonal, javítsa az útvonalat, mert a figyelő internetre történő közzététele elérhetőségi hibát cserél egy szabaddá tett asztalra. Ne gyengítse a munkamenet identitásellenőrzéseit sem, hogy átjusson egy egyidejűleg megjelent tanúsítványfigyelmeztetésen. Az önaláírt tanúsítvány egy RDP-figyelőn tervezés szerint figyelmeztetést ad, ezért elfogadása döntés, nem lépés.

Számolja meg a kísérleteket, mielőtt újrapróbálja. Az asztal zárolási küszöbei külön számolják a sikertelen bejelentkezéseket a VPN-hibáktól, és az időzítővel újrapróbálkozó ügyfél átlépheti a küszöböt, miközben Ön még egy szabályt szerkeszt. Ez ugyanaz a párhuzamos újrapróbálkozási mechanizmus, amely a jelszóváltás után zárolja a fiókokat.

Mit mozgathat a munkamenet, és hol marad

Tanulja meg a jóváhagyott kijelentkezési folyamatot, mielőtt szüksége lenne rá. Az ablak bezárása csak a nézetet szakíthatja meg, miközben a munkamenet a beállított házirendje szerint tovább fut, ami megosztott vagy auditált gazdagépen számít. Jelentkezzen ki a munkamenet belsejéből, amikor a házirend ezt várja.

Ezután döntse el, mit vihet a munkamenet, mert a vágólap, az átirányított meghajtók, a nyomtatóátirányítás és a fájlátvitel mind adatot mozgat a helyi és a távoli rendszer között ott, ahol a házirend engedi. Az a közzétett alkalmazás, amely a másik oldalon fut, nem automatikusan letöltés nélküli határ, és egy csak olvashatónak látszó munkamenet is vihet vágólapot. A valódi feladatot tesztelje, ne a kapcsolatot: nyissa meg a fájlt, használja az alkalmazást, és igazolja a szükséges átirányítást. A Microsoft útmutatója a távoli asztal kívülről történő eléréséhez leírja a támogatott kitettségi lehetőségeket, és jobb hivatkozás, mint egy nyomás alatt hozzáadott nyilvános figyelő.