Megosztás a következőn keresztül:

Nyilvános hálózatok RDP-rövidútvonalának hibaelhárítása

  • Cikk

Fontos

Az RDP Shortpath használata nyilvános hálózatokhoz a TURN használatával az Azure Virtual Desktophoz jelenleg előzetes verzióban érhető el. A bétaverziójú, előzetes verziójú vagy másként még általánosan nem elérhető Azure-szolgáltatások jogi feltételeit lásd: Kiegészítő használati feltételek a Microsoft Azure előzetes verziójú termékeihez.

Ha problémákat tapasztal az RDP Shortpath nyilvános hálózatokhoz való használatakor, a cikkben található információk segítségével elháríthatja a problémát.

A STUN-/TURN-kiszolgálókapcsolat és a NAT-típus ellenőrzése

A végrehajtható avdnettest.exefájl futtatásával ellenőrizheti a STUN-/TURN-végpontokhoz való kapcsolódást, és ellenőrizheti, hogy az alapszintű UDP-funkciók működnek-e. Íme egy letöltési hivatkozás a avdnettest.exelegújabb verziójára .

A futtatáshoz avdnettest.exe kattintson duplán a fájlra, vagy futtassa azt a parancssorból. A kimenet a következőhöz hasonló lesz, ha a kapcsolat sikeres:

Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server 20.202.68.109:3478 ... OK
Checking ACS server 20.202.21.66:3478 ... OK

You have access to TURN servers and your NAT type appears to be 'cone shaped'.
Shortpath for public networks is very likely to work on this host.

Fontos

Az előzetes verzióban a TURN csak az érvényesítési gazdagépkészlet munkamenetgazdáival létesített kapcsolatokhoz érhető el. A gazdagépkészlet érvényesítési környezetként való konfigurálásához lásd : A gazdagépkészlet meghatározása érvényesítési környezetként.

A Log Analyticsben naplózott hibainformációk

Íme néhány hibacím, amelyeket a Log Analyticsbe bejelentkezve láthat, és hogy mit jelentenek.

ShortpathTransportNetworkDrop

A TCP esetében két különböző útvonalat különböztetünk meg – a munkamenet-gazdagépet az átjáróhoz és az átjárót az ügyfélhez –, de ennek nincs értelme az UDP-nek, mivel nincs átjáró. A TCP esetében a másik különbség az, hogy sok esetben az egyik végpont, vagy esetleg valamilyen infrastruktúra generál egy TCP Reset csomagot (RST vezérlő bit), amely a TCP-kapcsolat kemény leállítását okozza. Ez azért működik, mert a TCP RST -t (és a tcp FIN-t is a szabályos leállításhoz) az operációs rendszer és néhány útválasztó kezeli, de az alkalmazás nem. Ez azt jelenti, hogy ha egy alkalmazás összeomlik, a Windows értesíti a társát arról, hogy a TCP-kapcsolat megszakadt, de az UDP-hez nem létezik ilyen mechanizmus.

A legtöbb csatlakozási hibát, például a ConnectionFailedClientDisconnect és a ConnectionFailedServerDisconnect, a TCP reset csomagok okozzák, nem pedig időtúllépést. Nincs mód arra, hogy az operációs rendszer vagy az útválasztó bármit jelezzen az UDP-vel, így a társ eltűnésének egyetlen módja egy időtúllépési üzenet.

ShortpathTransportReliabilityThresholdFailure

Ez a hiba akkor aktiválódik, ha egy adott csomag nem jut át, annak ellenére, hogy a kapcsolat nem halott. A csomag újraküldése legfeljebb 50-szer történik, ezért nem valószínű, de a következő esetekben fordulhat elő:

  1. A kapcsolat nagyon gyors és stabil volt, mielőtt hirtelen leállt volna. A csomag elveszettként való deklarálásához szükséges időtúllépés az ügyfél és a munkamenetgazda közötti oda-vissza útidőtől (RTT) függ. Ha az RTT nagyon alacsony, az egyik oldal nagyon gyakran megpróbálhat újraküldni egy csomagot, így az 50 próbálkozás eléréséhez szükséges idő kisebb lehet, mint a szokásos 17 másodperces időtúllépési érték.

  2. A csomag nagyon nagy. A maximálisan továbbítható csomagméret korlátozott. A csomag mérete mintavételezett, de ingadozhat, és néha zsugorodhat. Ha ez történik, előfordulhat, hogy az elküldött csomag túl nagy, és folyamatosan sikertelen lesz.

ConnectionBrokenMissedHeartbeatThresholdExceeded

Ez egy RDP-szintű időtúllépés. A helytelen konfiguráció miatt az RDP-szint időtúllépése néha az UDP-szintű időtúllépés előtt aktiválódik.