Përcjellje lokale SSH apo VPN i plotë për një ekran Mac?
Për një ekran në një pritës të vetëm, një përcjellje SSH në loopback është më e vogël se një VPN. Ja kur mjafton, çfarë kripton dhe kur duhet të ndaloni së përdoruri atë.
Ju duhet të shihni ekranin e një Mac nga makina juaj, Mac-i ndodhet pas një pritësi ku tashmë mund të lidheni me SSH, dhe pyetja është nëse kjo meriton një VPN. Zakonisht jo. Një përcjellje e vetme lokale mbart një port TCP përmes sesionit SSH që tashmë e keni, dhe për një ekran në një pritës të vetëm ky është një rregullim më i vogël dhe më i auditueshëm sesa rrugëtimi i një rrjeti të tërë.
Tre kushte e vendosin, dhe secila prej tyre mund t’ju shtyjë drejt VPN-it të menaxhuar.
Tre kushte e vendosin
E para është shtrirja: një shërbim në një pritës të vetëm, ose disa pritës dhe disa porta. E dyta është nëse çdo kërcim mes bastionit dhe objektivit është tashmë i besuar, sepse SSH mbron vetëm segmentin që përfundon. E treta është kush duhet ta mbështesë rregullimin pasi ta ndërtoni, sepse një tunel i bërë me dorë zakonisht mbijeton personin që e kuptoi. Emërtojeni atë person para se të filloni, dhe shkruajeni komandën në një vend ku ai mund ta gjejë. Një përcjellje e padokumentuar është një incident i ardhshëm me datë fillimi të shtyrë.
Nëse përgjigjet janë «një», «po» dhe «unë, për tani», përcjellja është mjeti i duhur. Nëse ndonjë përgjigje ndryshon, një projekt i mbështetur i aksesit në distancë kushton më pak gjatë një viti sesa rishikimi i incidentit që vjen pas një tuneli të padokumentuar.
Përcillni një port, jo rrjetin
Një përcjellje lokale hap një dëgjues në makinën tuaj dhe përcjell çdo lidhje përmes serverit SSH drejt një destinacioni që ai server mund të arrijë. Për një Mac, shërbimi i ndarjes së ekranit të të cilit dëgjon në TCP 5900, dhe një bastion që mund të zgjidhë mac.corp.example, komanda është e shkurtër dhe qëllimisht e ngushtë. Çdo opsion në të ekziston për ta mbajtur rregullimin të vogël: pa shell, pa dëgjues në të gjitha ndërfaqet, pa daemon. Lexojeni si një deklaratë shtrirjeje, jo si një recetë.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]Lidhja e dëgjuesit me 127.0.0.1 e mban larg çdo ndërfaqeje tjetër. Kjo nuk është formalitet: një përcjellje e lidhur me të gjitha ndërfaqet e kthen laptopin tuaj në një rele të hapur drejt rrjetit korporativ për këdo në të njëjtin Wi-Fi të kafenesë. Nëse porta është tashmë në përdorim, zgjidhni një port tjetër të lartë dhe përditësoni shikuesin; mos ndaloni një shërbim të palidhur që shembulli të përshtatet.
Llogaria në bastion gjithashtu ka nevojë për leje për të përcjellë drejt atij destinacioni. Disa konfigurime SSH të forcura e çaktivizojnë plotësisht përcjelljen e portave, dhe disa e kufizojnë atë me një direktivë permit-listen ose permit-open. Lexoni politikën e serverit para se të supozoni që një kanal i refuzuar do të thotë fjalëkalim i gabuar.
Çfarë kripton SSH, dhe ku ndalon
Sesioni SSH mbron trafikun nga Mac-i juaj deri në bastion, dhe përcjellja mbart protokollin VNC brenda atij sesioni pa e kuptuar. Pasi lidhja largohet nga bastioni drejt objektivit, ajo nuk është më brenda sesionit tuaj SSH. Çfarëdo mbrojtjeje që ekziston në atë kërcim të fundit, i përket protokollit të objektivit dhe kontrolleve të vetë rrjetit privat.
Prandaj një kërcim i thjeshtë i fundit VNC nuk duhet të përshkruhet si i kriptuar nga fundi në fund vetëm sepse kërcimi i parë përdori SSH. Përshkruani segmentet me ndershmëri: i fortë nga klienti në bastion, dhe më pas çfarë mbështet objektivi. Nëse kërkesa është që e gjithë rruga të kriptohet nga një mekanizëm i vetëm, përcjellja nuk e përmbush atë.
Vërtetimi në objektiv është përsëri çështje më vete. Llogaria SSH nuk jep një hyrje në macOS, dhe shërbimi i ndarjes së ekranit kërkon ende kredencialet e veta dhe zbaton ende listën e vet të aksesit. Një dëgjues lokal që pranon një lidhje nuk provon asgjë për atë nëse shërbimi në distancë do ta pranojë sesionin.
Kur VPN-i i plotë është zgjedhja e duhur
Zgjidhni VPN-in kur detyra kërkon më shumë se një port: funksionet e menaxhimit dhe raportimit të Apple Remote Desktop përdorin trafik shtesë TCP dhe UDP që një përcjellje e vetme TCP nuk e mbart. Përcjellja nuk është një zbatim i pjesshëm i të gjithë produktit; është një mjet tjetër, më i vogël.
Zgjidhni atë kur disa administratorë lidhen nga vende që ndryshojnë, sepse një profil i menaxhuar shpërndan rrugë, kredenciale dhe politikë pa e shpikur secili një rresht komande. Zgjidhni atë kur gjurma e auditimit duhet të tregojë kush u lidh me çfarë, pasi një sesion SSH për përdorues dhe një përcjellje lokale e ndarë lënë regjistrime shumë të ndryshme.
Zgjidhni atë, së fundi, kur rrjeti objektiv nuk duhet të jetë fare i arritshëm nga një laptop pa portën e vetë organizatës. Një përcjellje personale e anashkalon atë portë nga vetë dizajni, dhe pikërisht për këtë i përket një regjistri ndryshimesh dhe jo një historiku shell.
Bëni përcjelljen të dështojë me zë të lartë
Përdorni ExitOnForwardFailure=yes që një lidhje e dështuar ta ndalojë sesionin në vend që të lërë një shell që duket i lidhur dhe nuk përcjell asgjë. Mbajeni aktiv verifikimin e çelësit të pritësit, dhe parapëlqeni një çelës ose agjent ndaj një fjalëkalimi. Më pas provoni URL-në e saktë që do të përdorë shikuesi, sepse një sesion SSH që funksionon dhe një lidhje ekrani që funksionon janë dy rezultate të ndryshme.
Për klientin vendas në macOS, shikuesi arrihet përmes një URL lokale: open "vnc://127.0.0.1:15900". Nëse dritarja hapet dhe pritësi në distancë e refuzon vërtetimin, tuneli është në rregull dhe problemi është tek objektivi. Nëse dritarja nuk hapet kurrë, problemi është dëgjuesi ose porta.
Ndaloni sesionin kur të mbaroni, dhe shënoni portën, bastionin, objektivin dhe politikën e llogarisë. Një përcjellje që askush nuk e dokumentoi nuk dallohet nga një derë e pasme gjashtë muaj më vonë, dhe ky është argumenti më i fortë për ta mbajtur të vogël, të emërtuar dhe të përkohshme.