Kufikia tovuti ya HTTPS inayopatikana kupitia VPN tu kwa usambazaji wa SSH

Mashine moja tayari ina ufikiaji wa VPN ulioidhinishwa, mashine ya pili inahitaji huduma moja ya faragha ya HTTPS, na usambazaji wa ndani wa SSH unaweza kuziba pengo hilo bila kuipa mashine ya pili handaki. Usambazaji hubeba lengwa moja la TCP badala ya mtandao wote, na kikomo hicho ndicho kiini cha jambo. Pitia hatua tano zilizo hapa chini kwa mpangilio, kwa sababu kila moja inashindikana kwa sababu tofauti na hatua ya baadaye haiwezi kuokoa pengo la awali. Iwapo sharti lolote la awali halipo, muundo huu hautatui na hakuna urekebishaji wa amri utakaosaidia.

Hatua ya kwanza: thibitisha masharti matatu

Mambo matatu lazima yawe tayari kweli kabla amri yoyote kuwa na maana. Unahitaji ruhusa ya kutumia mashine ya kwanza kama mwenyeji wa usambazaji, ufikiaji wa SSH unaofanya kazi kwake, na sera ya seva inayoruhusu lengwa lililokusudiwa. Akaunti ya SSH iliyoundwa kwa uhamishaji wa faili inaweza kuwa na usambazaji umezimwa, na seva inayoruhusu usambazaji bado inaweza kuzuia ni malengo gani yanafikika kwa njia yake. Uliza kabla ya kujaribu, kwa sababu kutumia kituo cha kazi cha mwenzako kama sehemu ya kuruka bila makubaliano ni tatizo la sera, hata amri inapofanya kazi bila hitilafu.

Amri mbili hutatua nusu ya kiufundi ya orodha hiyo. Ya kwanza inathibitisha kuwa akaunti na ufunguo hufanya kazi bila ombi la mwingiliano, na ya pili inachapisha sera halisi ya seva badala ya mfano uliotolewa maoni katika faili ya usanidi.

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

Hatua ya pili: funga bandari ya loopback na uweke kikao hai

Kwenye mashine inayotekeleza programu ya mteja, fungua usambazaji wa ndani kuelekea huduma ya faragha. Ufunge kwa uwazi kwenye loopback ili usisambazwe kwenye mtandao wa ndani, na uchague bandari ya juu ambayo hakuna huduma yoyote ya ndani inayoshikilia tayari. Weka kikao kikiendelea unapofanya kazi, kwa sababu kukifunga hufunga msikilizaji. ExitOnForwardFailure hubadilisha ufungaji uliokataliwa au bandari iliyokaliwa kuwa kutoka papo hapo badala ya kikao kinachobaki bila usambazaji, na hiyo ndiyo hali ya kushindikana inayopoteza muda mwingi.

Muunganisho wa faragha hufanywa kutoka kwa mwenyeji wa kuruka, kwa hivyo DNS, njia, sera ya VPN na ufikiaji wa huduma wa mwenyeji huyo lazima vyote vifanye kazi. Kikao cha SSH hakiundi ufikikaji ambao mwenyeji wa kuruka hauna, na hakiwezi kurekebisha njia ambayo VPN haikupiga kamwe. Thibitisha msikilizaji mahali ulipo kweli badala ya kuamini ukimya wa amri.

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

Hatua ya tatu: hifadhi jina la HTTPS wakati soketi ni ya ndani

https://127.0.0.1:9443/ kuvinjari hubadilisha jina la seva ya TLS na mamlaka ya programu. Cheti kilichotolewa kwa portal.lab.example hakitathibitishwa dhidi ya anwani ya loopback, na hitilafu inayotokana inaonekana kama cheti kilichovunjika badala ya njia ya mkato ya usambazaji. Kwa jaribio la mstari wa amri, hifadhi URL halisi na ubadilishe tu lengwa la soketi. --connect-to hufanya hivyo, na mwongozo wa curl unaandika umbo la sehemu nne linalotumika hapa chini.

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

Jina linabaki kwenye URL, kwenye kupeana mkono kwa TLS na kwenye kichwa cha Host, huku muunganisho wa TCP ukienda kwa msikilizaji wa ndani. Chaguo la bila proksi huweka jaribio kwenye usambazaji huu badala ya kuruhusu proksi ya HTTP iliyosanidiwa kuinasa, na kuweka uthibitishaji wa cheti umewashwa ndiko kunakofanya matokeo kuwa na maana.

Hatua ya nne: ujue kile usambazaji mmoja hauwezi kufunika

Usambazaji mmoja wa TCP hufunika bandari moja ya lengwa. Ukurasa unaoelekeza kwenye jina la pili la mwenyeji, unaopakia rasilimali kutoka kwa mwenyeji ndani ya mtandao wa faragha au unaotuma kwenye bandari nyingine unahitaji usambazaji wake, na kila moja yao inahitaji ukaguzi huo huo wa sera kama wa kwanza. Mipango ya kazi ya kivinjari huongeza mahitaji yake, kwa sababu kivinjari lazima kiambiwe kitume jina halisi kwenye bandari ya ndani kupitia usanidi wa proksi au uchoraji ramani wa ndani. Kwa hivyo jaribio la mstari wa amri lililofanikiwa halithibitishi kuwa kivinjari kitafanikiwa, ingawa linathibitisha njia.

UDP, ugunduzi wa SMB na kuingia kwenye kikoa hazipiti kabisa kwa usambazaji wa TCP. Ikiwa hitaji halisi ni ufikiaji wa jumla wa mtandao, muundo huu ni chombo kibaya na lango la ufikiaji wa mbali linaloungwa mkono ndilo sahihi.

Hatua ya tano: safisha na uandike

Simamisha kikao jaribio linapokamilika na uthibitishe kuwa msikilizaji ameondoka. Ikiwa bandari iliyochaguliwa ilikuwa imekaliwa tayari, chagua bandari nyingine ya loopback isiyotumika na usasishe URL, amri ya jaribio na dokezo pamoja, badala ya kusimamisha huduma ya ndani isiyohusiana ili kuachilia namba. Kuacha usambazaji wazi kwenye kompyuta ya mkononi hubadilisha utambuzi kuwa huduma isiyosimamiwa.

Andika mwenyeji wa kuruka, lengwa lililopelekwa, bandari ya ndani na nani aliidhinisha mpango huo. Usambazaji unaopatikana tu katika historia ya shell ya mtu uko umbali wa kuwasha upya mmoja kutoka uchunguzi unaorudiwa, na mtu anayefuata hatajua ni sharti gani kati ya matatu ambalo tayari limeangaliwa.