Loka SSH-plusendado aŭ plena VPN por unu Mac-ekrano?

Vi bezonas vidi la ekranon de unu Mac de via propra maŝino, la Mac staras malantaŭ gastiganto al kiu vi jam povas SSH, kaj la demando estas ĉu tio meritas VPN-on. Kutime ne. Unu loka plusendado portas unu TCP-pordon tra la SSH-sesio, kiun vi jam havas, kaj por unu ekrano sur unu gastiganto tio estas pli malgranda kaj pli aŭdebla aranĝo ol enkursigi tutan reton.

Tri kondiĉoj decidas tion, kaj iu ajn el ili povas puŝi vin al la administrata VPN anstataŭe.

Tri kondiĉoj decidas tion

La unua estas amplekso: unu servo sur unu gastiganto, aŭ pluraj gastigantoj kaj pluraj pordoj. La dua estas ĉu ĉiu salto inter la bastiono kaj la celo jam estas fidata, ĉar SSH protektas nur la segmenton, kiun ĝi finas. La tria estas kiu devas subteni la aranĝon post kiam vi konstruos ĝin, ĉar mane farita tunelo emas postvivi la personon, kiu komprenis ĝin. Nomu tiun personon antaŭ ol vi komencos, kaj skribu la komandon en loko, kie ŝi povas trovi ĝin. Nedokumentita plusendado estas estonta incidento kun prokrastita startdato.

Se la respondoj estas «unu», «jes» kaj «mi, por nun», la plusendado estas la ĝusta ilo. Se iu respondo ŝanĝiĝas, subtenata dezajno de fora aliro estas pli malmultekosta dum jaro ol la incidenta revizio, kiu sekvas nedokumentitan tunelon.

Plusendu unu pordon, ne la reton

Loka plusendado malfermas aŭskultanton sur via maŝino kaj plusendas ĉiun konekton tra la SSH-servilo al celo, kiun tiu servilo povas atingi. Por Mac, kies ekrankomuniga servo aŭskultas sur TCP 5900, kaj bastiono, kiu povas solvi mac.corp.example, la komando estas mallonga kaj intence mallarĝa. Ĉiu opcio en ĝi ekzistas por teni la aranĝon malgranda: neniu ŝelo, neniu aŭskultanto sur ĉiuj interfacoj, neniu demono. Legu ĝin kiel ampleksan deklaron, ne kiel recepton.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

Ligi la aŭskultanton al 127.0.0.1 tenas ĝin for de ĉiuj aliaj interfacoj. Tio ne estas formaleco: plusendado ligita al ĉiuj interfacoj igas vian tekkomputilon malferma relajso en la kompanian reton por iu ajn en la sama kafeja Wi-Fi. Se la pordo jam estas uzata, elektu alian altan pordon kaj ĝisdatigu la vidigilon; ne haltigu nerilatan servon por ke la ekzemplo taŭgu.

La konto sur la bastiono ankaŭ bezonas permeson plusendi al tiu celo. Iuj harditaj SSH-agordoj tute malŝaltas pordan plusendadon, kaj iuj limigas ĝin per direktivo permit-listen aŭ permit-open. Legu la servilan politikon antaŭ ol supozi, ke rifuzita kanalo signifas malĝustan pasvorton.

Kion SSH ĉifras, kaj kie ĝi haltas

La SSH-sesio protektas trafikon de via Mac al la bastiono, kaj la plusendado portas la VNC-protokolon ene de tiu sesio sen kompreni ĝin. Post kiam la konekto forlasas la bastionon al la celo, ĝi jam ne estas ene de via SSH-sesio. Kia ajn protekto ekzistas sur tiu lasta salto, ĝi apartenas al la cela protokolo kaj al la propraj kontroloj de la privata reto.

Tial ordinara lasta VNC-salto ne devus esti priskribita kiel ĉifrita de fino al fino nur ĉar la unua salto uzis SSH. Priskribu la segmentojn honeste: forta de kliento al bastiono, kaj kion ajn la celo subtenas poste. Se la postulo estas, ke la tuta vojo estu ĉifrita per unu mekanismo, la plusendado ne plenumas tion.

Aŭtentigo ĉe la celo estas denove aparta afero. La SSH-konto ne donas macOS-saluton, kaj la ekrankomuniga servo ankoraŭ postulas siajn proprajn akreditaĵojn kaj ankoraŭ aplikas sian propran alirliston. Loka aŭskultanto, kiu akceptas konekton, pruvas nenion pri tio, ĉu la fora servo akceptos la sesion.

Kiam la plena VPN estas la ĝusta elekto

Elektu la VPN-on, kiam la tasko bezonas pli ol unu pordon: la administraj kaj raportaj funkcioj de Apple Remote Desktop uzas plian TCP- kaj UDP-trafikon, kiun unu TCP-plusendado ne portos. Plusendado ne estas parta efektivigo de la tuta produkto; ĝi estas alia, pli malgranda ilo.

Elektu ĝin, kiam pluraj administrantoj konektiĝas de ŝanĝiĝantaj lokoj, ĉar administrata profilo disdonas itinerojn, akreditaĵojn kaj politikon sen ke ĉiu persono elpensu komandlinion. Elektu ĝin, kiam la revizia spuro devas montri, kiu konektiĝis al kio, ĉar SSH-sesio por uzanto kaj komuna loka plusendado lasas tre malsamajn rikordojn.

Elektu ĝin, fine, kiam la cela reto tute ne estu atingebla de tekkomputilo sen la propra pordego de la organizo. Persona plusendado ĉirkaŭiras tiun pordegon laŭdezajne, kaj ĝuste tial ĝi apartenas al ŝanĝa rikordo anstataŭ al ŝela historio.

Igu la plusendadon laŭte malsukcesi

Uzu ExitOnForwardFailure=yes por ke malsukcesa ligo haltigu la sesion anstataŭ lasi ŝelon, kiu aspektas konektita kaj plusendas nenion. Tenu la kontrolon de gastiganta ŝlosilo ŝaltita, kaj preferu ŝlosilon aŭ agenton anstataŭ pasvorton. Poste testu la ĝustan URL-on, kiun la vidigilo uzos, ĉar funkcianta SSH-sesio kaj funkcianta ekrana konekto estas du malsamaj rezultoj.

Por la denaska kliento sur macOS, la vidigilo atingeblas per loka URL: open "vnc://127.0.0.1:15900". Se la fenestro malfermiĝas kaj la fora gastiganto rifuzas aŭtentigon, la tunelo estas en ordo kaj la problemo estas ĉe la celo. Se la fenestro neniam malfermiĝas, la problemo estas la aŭskultanto aŭ la pordo.

Haltigu la sesion, kiam vi finos, kaj notu la pordon, la bastionon, la celon kaj la kontan politikon. Plusendado, kiun neniu dokumentis, ne estas distingebla de malantaŭa pordo post ses monatoj, kaj tio estas la plej forta argumento teni ĝin malgranda, nomita kaj provizora.