Fora labortablo tra VPN: en kiu paneo vi estas?

Via tunelo funkcias, la interna vikio ŝargiĝas, kaj la fora labortablo ankoraŭ rifuzas konektiĝi. Tiu kombinaĵo estas normala, ĉar la VPN donas itineron al la gastiganto, dum la labortabla servo devas aŭskulti, esti permesita de sia propra fajroŝirmilo kaj voli aŭtentikigi la konton. Kvar paneoŝtupoj staras inter funkcianta tunelo kaj uzebla sesio, kaj ĉiu malsukcesas per malsama mesaĝo. Legu unue la mesaĝon, ĉar ĝi nomas la ŝtupon.

Kvar paneoj, kiuj aspektas kiel unu

La ŝtupoj estas ordigitaj: la nomo rezolviĝas al la privata adreso, kiun la dezajno intencas, la pordo respondas al TCP-manpremo, la gastiganto akceptas la konekton laŭ sia propra politiko, kaj la sesia ensaluto sukcesas. Ĉiu ŝtupo igas la sekvan netestebla, kaj tial ŝanĝi RDP-agordojn antaŭ ol la reto firmiĝis produktas nur bruon. La simptomo aspektas identa de la uzanta flanko en ĉiuj kvar kazoj. Nur la mesaĝo de la kliento apartigas ilin.

Funkcianta interna retejo pruvas neniun el la kvar. Ĝi pruvas, ke gastiganto en la sama reto respondis sur malsama pordo per malsama servo. Taksu tion kiel pruvon pri enkursigado kaj nenion pli.

Testu laŭ ordo kaj skribu la rezulton. Salti al la ensaluta ekrano ĉar la pordo respondis estas la maniero pasigi posttagmezon per fajroŝirmila problemo, kiun la unua paŝo jam lokalizis.

Ĉu io aŭskultas sur 3389?

Komencu per la nomo, ĉar nomo, kiu rezolviĝas al la malĝusta adreso, senvalidigas ĉiun postan teston. Demandu la rezolvilon de la tunelo, kion signifas la nomo, poste komparu la respondon kun la privata adreso, kiun la dezajno intencas, anstataŭ kun sukcesa respondo. Nomo, kiu rezolviĝas al publika adreso, estas la tuta problemo, kaj neniu RDP-ŝanĝo riparos ĝin:

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

Poste testu la pordon anstataŭ la gastiganton. Kompletigita TCP-manpremo sur 3389 apartigas atingeblecon de ĉio super ĝi:

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

Rulu tiun teston el la LAN kaj el la tunelo, ĉar diferenco inter la du rezultoj lokigas la paneon al la VPN-itinero. Du fajroŝirmiloj staras en la itinero kaj facile konfuzeblas: la reto devas permesi al la tunela adreso de la kliento atingi la gastiganton, kaj la propra fajroŝirmilo de la gastiganto devas permesi tiun saman fonton sur la aŭskultanta pordo. Regulo limigita al la LAN-subreto ne kovras la naĝejon de VPN-klientoj, kaj tio estas la plej ofta kaŭzo de tempolimo, kiun raportas nur foraj uzantoj. Kontrolu la amplekson, ne la ekziston de la regulo.

La revena itinero meritas la saman kontrolon. Respondoj bezonas itineron reen al la naĝejo de klientoj anstataŭ al la LAN, kaj traduko antaŭ la gastiganto ŝanĝas la fonton, kiun montros via protokolo. Se la pordo respondas unudirekte kaj ne la alidirekte, la mankanta duono kutime estas la revena itinero.

Legu la mesaĝon antaŭ ol legi la agordon

La tria ŝtupo estas la gastiganto rifuzanta la konekton laŭ sia propra politiko, kio ofte aspektas kiel pordo, kiu malfermiĝas kaj fermiĝas tuj. Io respondis, kaj tio estas utila informo anstataŭ silento. Se la manpremo kompletiĝis kaj la sesio tuj mortis, la reto estas en ordo kaj la gastiganto decidas. Rigardu la permesojn de la fora labortablo antaŭ ol tuŝi la reton denove.

La funkcio povas esti ŝaltita por la maŝino, dum aliro estas limigita al difinitaj grupoj, kaj la aŭskultanto povas esti ligita tiel, ke ĝi ekskludas la adreson, per kiu vi alvenis. Retnivela aŭtentikigo aldonas pordegon, kiu malsukcesas antaŭ ol la labortablo ŝargiĝas, kaj ĝia erarteksto diferencas de malĝusta pasvorto. Komparu la mesaĝon de la kliento kun la eventa protokolo de la gastiganto, ĉar la mesaĝo nomas la pordegon kaj la protokolo la konton.

Sesia ensaluto estas propra limo

Aŭtentikigo apartenas al la labortabla servo, ne al la VPN. La identeco de la tunelo kaj la labortabla konto estas apartaj legitimiloj kun apartaj ŝlosilaj politikoj, do funkcianta tunelo pruvas nur, ke la tunelo akceptis vin. Ŝlosi la labortablan konton ne ĝenas la tunelon, kaj la malo ankaŭ veras.

Tenu ambaŭ sendifektaj. Kiam la privata itinero mankas, riparu la itineron, ĉar publikigi la aŭskultanton en la interreto interŝanĝas atingeblan cimon kontraŭ elmetita labortablo. Ne malfortigu ankaŭ la identecajn kontrolojn de la sesio por preterpasi atestilan averton, kiu aperis samtempe. Memsubskribita atestilo sur RDP-aŭskultanto produktas averton laŭ dezajno, do akcepti ĝin estas decido, ne paŝo.

Kalkulu la provojn antaŭ reprovi. Ŝlosaj sojloj de la labortablo kalkulas malsukcesajn ensalutojn aparte de VPN-malsukcesoj, kaj kliento, kiu reprovas laŭ tempigilo, povas superi la sojlon dum vi ankoraŭ redaktas regulon. Tio estas la sama paralela reprova mekanismo, kiu ŝlosas kontojn post pasvorta ŝanĝo.

Kion la sesio povas movi, kaj kie ĝi restas

Lernu la aprobitan elsalutan laborfluon antaŭ ol vi bezonos ĝin. Fermi la fenestron eble nur malkonektas la vidon dum la sesio daŭre funkcias laŭ sia agordita politiko, kio gravas sur dividita aŭ reviziita gastiganto. Elsalutu el la sesio, kiam la politiko tion atendas.

Poste decidu, kion la sesio rajtas porti, ĉar poŝmemoro, alidirektitaj diskoj, printila alidirektado kaj dosiera transigo movas datumojn inter la loka kaj fora sistemoj, kie la politiko permesas. Publikigita aplikaĵo ruliĝanta sur la alia flanko ne estas aŭtomate limo sen elŝuto, kaj sesio, kiu aspektas nurlegebla, tamen povas porti poŝmemoron. Testu la realan taskon, ne la konekton: malfermu la dosieron, uzu la aplikaĵon kaj konfirmu la alidirektadon, kiun vi bezonas. La gvidilo de Microsoft pri atingado de fora labortablo el ekstere priskribas la subtenatajn elmetajn opciojn, kaj ĝi estas pli bona referenco ol publika aŭskultanto aldonita sub premo.