Këtu grumbullohen tre transporte dhe secili ka kornizimin e vet. Ngarkesa e VPN udhëton brenda një sesioni TLS, ai sesion TLS udhëton brenda një lidhjeje TCP drejt një porti loopback, dhe bajtët e asaj lidhjeje udhëtojnë brenda SSH drejt një hosti relay, i cili hap lidhjen reale TCP drejt dëgjuesit të VPN. Asgjë në këtë rregullim nuk ndryshon atë që OpenVPN vërteton, dhe asgjë në të nuk e bën një dëgjues UDP të arritshëm përmes TCP. Pjesën tjetër lexojeni si përshkrim të rrugës së bajtëve, jo si recetë për të anashkaluar një kontroll rrjeti.

Çfarë lëviz në të vërtetë përcjellja lokale

Klienti SSH dëgjon në një port lokal. Kur një proces lokal lidhet, klienti i paketon bajtët në kanalin e tij të kriptuar, dhe ana e serverit hap një lidhje të re TCP drejt destinacionit të emërtuar në kërkesën e përcjelljes.

Atë destinacion e zgjidh relay-i, jo makina juaj, prandaj një emër që ekziston vetëm brenda rrjetit të largët vazhdon të funksionojë. Kjo do të thotë gjithashtu se relay-i duhet të arrijë dëgjuesin e VPN dhe të ketë një rrugë kthimi drejt tij. Një emër që zgjidhet në laptopin tuaj nuk thotë asgjë për atë që relay-i mund të shohë.

Nisja e sesionit SSH vërteton vetëm që relay-i është i arritshëm dhe i vërtetuar. Nuk thotë nëse dëgjuesi tjetër është aktiv, nëse një firewall midis relay-it dhe dëgjuesit e pranon lidhjen, ose nëse VPN do të pranojë profilin tuaj.

Drejtojeni klientin drejt dëgjuesit lokal

Një shembull i deklaruar: relay-i arrin një dëgjues TCP në gw.internal.example:443, dhe një port i lartë lokal e ekspozon atë rrugë vetëm për këtë makinë.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Manuali i OpenSSH e përshkruan përcjelljen lokale si pranim lokal i lidhjeve TCP dhe hapje e lidhjes pasuese nga ana e largët. Lidheni dëgjuesin me loopback dhe jo me të gjitha ndërfaqet, sepse një përcjellje e arritshme nga rrjeti është një relay i hapur me emrin tuaj mbi të. Lidhja me karakter joker ekspozon portin edhe për çdo llogari tjetër lokale në një makinë të përbashkët.

Më pas vendosni klientin VPN në modalitetin TCP dhe drejtojeni në 127.0.0.1:24011. Nëse profili përdor UDP, ky dizajn nuk mund të ndihmojë: përcjellja mbart një rrjedhë bajtësh dhe nuk ka rrugë datagramësh përmes saj.

Mbani të ndara dy vërtetimet

SSH vërteton hostin relay. OpenVPN vazhdon të vërtetojë palën VPN dhe destinacioni loopback nuk e ndryshon këtë kërkesë. Çaktivizimi i kontrolleve të certifikatës sepse socket-i tani tregon localhost është shkurtesa më e keqe në këtë dizajn. E kthen një rregullim transporti në rregullim besimi, dhe për të dytin askush nuk ka dhënë pëlqimin.

Mbani të paprekura ankorën e besimit të profilit, kontrollin e rolit të serverit dhe verifikimin e emrit. Nëse klienti juaj krahason emrin e serverit me adresën që thirri, loopback mund të ketë nevojë për një konfigurim të qartë emri në vend të një kontrolli të çaktivizuar, dhe dokumentacioni i profilit është vendi për të konfirmuar cili fushë krahasohet.

Trajtojeni relay-in si palën e dytë në historinë e besimit: administratori i tij sheh metadata lidhjesh dhe mund ta ridrejtojë përcjelljen nëse konfigurimi ndryshohet. Rregullimi kërkon miratim si nga relay-i ashtu edhe nga pronari i shërbimit VPN, jo vetëm nga ai që i nevojitet sot.

Mos ndërtoni një cikël nën tunel

Pasi VPN instalon rrugët, lidhja SSH që e mbart ka ende nevojë për një rrugë drejt relay-it që nuk kalon nëpër tunel. Nëse rruga e paracaktuar kalon te VPN dhe relay-i është i arritshëm vetëm përmes të njëjtit tunel, transporti shembet dhe VPN shkon me të. Dështimi duket si tunel i rënë dhe jo si gabim rrugëtimi, prandaj diagnostikohet gabimisht.

Rregullimi i zakonshëm është një rrugë hosti drejt adresës së relay-it e fiksuar në ndërfaqen fizike përpara se tuneli të ngrihet, plus një kontroll që rruga i mbijeton një rilidhjeje. Verifikojeni me një kërkim rruge për adresën e relay-it në vend që të supozoni se renditja ishte e saktë.

Prisni gjithashtu që ky stiv të jetë më i ngadaltë dhe më i brishtë se një lidhje e drejtpërdrejtë, sepse tani ka dy transporte të renditura dhe një pikë tjetër fundore për t'u mirëmbajtur. Është një mënyrë për të kaluar një kufi rrjeti, jo një teknikë performance.

Mbylle dëgjuesin kur të mbaroni

Ndaloni sesionin SSH kur tuneli nuk nevojitet më, dhe konfirmoni që porti lokal është liruar. Një përcjellje e harruar mban një rrugë të vërtetuar të hapur në një makinë që mund të jetë e përbashkët.

Rishikoni edhe destinacionet e lejuara të përcjelljes në relay, sepse një konfigurim lejues e kthen çdo llogari të komprometuar në një pikë mbështetjeje të përgjithshme. Shënoni portin, relay-in dhe destinacionin së bashku, që personi tjetër të dijë për çfarë ishte përcjellja dhe nëse është ende e miratuar.

Artikuj të ngjashëm