Arritja e një sajti HTTPS të disponueshëm vetëm përmes VPN-së me një përcjellje SSH

Një makinë tashmë ka akses VPN të miratuar, makina e dytë ka nevojë për saktësisht një shërbim privat HTTPS, dhe një përcjellje SSH lokale mund ta mbulojë atë hendek pa i dhënë makinës së dytë një tunel. Përcjellja transporton një destinacion të vetëm TCP në vend të të gjithë rrjetit, dhe pikërisht ky kufizim është thelbi. Kaloni nëpër pesë hapat më poshtë me radhë, sepse secili dështon për një arsye tjetër dhe një hap i mëvonshëm nuk mund të shpëtojë një hendek të mëparshëm. Nëse mungon ndonjë parakusht, ky dizajn nuk e zgjidh atë dhe asnjë rregullim komandash nuk do të ndihmojë.

Hapi i parë: konfirmoni tre parakushtet

Tre gjëra duhet të jenë tashmë të vërteta përpara se çdo komandë të ketë rëndësi. Ju nevojitet leja për të përdorur makinën e parë si strehues përcjelljeje, akses SSH funksional tek ajo dhe një politikë serveri që lejon destinacionin e synuar. Një llogari SSH e krijuar për transferim skedarësh mund ta ketë përcjelljen të çaktivizuar, dhe një server që lejon përcjelljen mund të kufizojë ende cilat destinacione janë të arritshme përmes saj. Pyetni përpara testimit, sepse përdorimi i stacionit të punës të një kolegu si pikë kërcimi pa marrëveshje është problem politike, edhe kur komanda punon pa të meta.

Dy komanda zgjidhin gjysmën teknike të asaj liste. E para vërteton që llogaria dhe çelësi punojnë pa një kërkesë interaktive, dhe e dyta shtyp politikën e vërtetë të serverit në vend të shembullit të komentuar në skedarin e konfigurimit.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Hapi i dytë: lidhni një portë loopback dhe mbani sesionin gjallë

Në makinën që ekzekuton aplikacionin klient, hapni një përcjellje lokale drejt shërbimit privat. Lidheni atë në mënyrë eksplicite me loopback që të mos publikohet në rrjetin lokal, dhe zgjidhni një portë të lartë që asnjë shërbim lokal nuk e mban tashmë. Mbani sesionin në punë ndërsa punoni, sepse mbyllja e tij mbyll dëgjuesin. ExitOnForwardFailure e kthen një lidhje të refuzuar ose një portë të zënë në dalje të menjëhershme në vend të një sesioni që mbetet pa përcjellje, dhe ky është mënyra e dështimit që harxhon më shumë kohë.

Lidhja private bëhet nga strehuesi i kërcimit, prandaj DNS, rrugët, politika VPN dhe aksesi në shërbim i atij strehuesi duhet të punojnë të gjitha. Sesioni SSH nuk krijon arritshmëri që strehuesi i kërcimit nuk e ka, dhe nuk mund të riparojë një rrugë që VPN-ja nuk e ka shtyrë kurrë. Konfirmoni dëgjuesin aty ku është vërtet, në vend që të mbështeteni në heshtjen e komandës.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Hapi i tretë: mbani emrin HTTPS kur soketi është lokal

Shfletimi drejt https://127.0.0.1:9443/ ndryshon emrin e serverit TLS dhe autoritetin e aplikacionit. Një certifikatë e lëshuar për portal.lab.example nuk do të vlerësohet kundrejt një adrese loopback, dhe gabimi që rezulton duket si një certifikatë e prishur, jo si një shkurtore përcjelljeje. Për një test nga rreshti i komandës, mbani URL-në e vërtetë dhe ndryshoni vetëm destinacionin e soketit. Këtë bën --connect-to, dhe manual i curl dokumenton formën me katër fusha të përdorur më poshtë.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Emri mbetet në URL, në shtrëngimin e dorës TLS dhe në kokën Host, ndërsa lidhja TCP shkon te dëgjuesi lokal. Opsioni pa proxy e mban testin në këtë përcjellje në vend që të lejojë një proxy HTTP të konfiguruar ta përgjojë, dhe mbajtja e verifikimit të certifikatës aktive është ajo që e bën rezultatin kuptimplotë.

Hapi i katërt: dini çfarë nuk mund të mbulojë një përcjellje

Një përcjellje e vetme TCP mbulon një portë destinacioni. Një faqe që ridrejton te një emër i dytë strehuesi, ngarkon burime nga një strehues brenda rrjetit privat ose dërgon në një portë tjetër ka nevojë për përcjelljen e vet, dhe secila prej tyre ka nevojë për të njëjtin kontroll politike si e para. Rrjedhat e punës së shfletuesit shtojnë kërkesa të vetat, sepse shfletuesit duhet t'i thuhet ta dërgojë emrin e vërtetë te porta lokale përmes një konfigurimi proxy ose një hartëzimi lokal. Prandaj një test i suksesshëm nga rreshti i komandës nuk provon që shfletuesi do të ketë sukses, edhe pse provon rrugën.

UDP, zbulimi SMB dhe hyrja në domen nuk kalojnë fare përmes një përcjelljeje TCP. Nëse nevoja e vërtetë është akses i përgjithshëm në rrjet, ky dizajn është mjeti i gabuar dhe porta e aksesit në distancë e mbështetur është e duhura.

Hapi i pestë: pastroni dhe shkruajeni

Ndaloni sesionin kur testi të ketë përfunduar dhe konfirmoni që dëgjuesi ka ikur. Nëse porta e zgjedhur ishte tashmë e zënë, zgjidhni një portë tjetër loopback të papërdorur dhe përditësoni së bashku URL-në, komandën e testit dhe shënimin, në vend që të ndaloni një shërbim lokal të palidhur për të liruar numrin. Lënia e një përcjelljeje të hapur në një laptop e kthen një diagnostikim në një shërbim të pamenaxhuar.

Shkruani strehuesin e kërcimit, destinacionin e përcjellë, portën lokale dhe kush e miratoi marrëveshjen. Një përcjellje që ekziston vetëm në historikun shell të dikujt është një rinisje larg një hetimi të përsëritur, dhe personi tjetër nuk do ta dijë se cili nga tre parakushtet është kontrolluar tashmë.