Atingi HTTPS-ejon nur-VPN per SSH-plusendo
Ponto unu nur-VPN HTTPS-servon per loka SSH-plusendo, konservu la veran gastigantnomon per --connect-to, kaj sciu, kion unu TCP-plusendo ne povas kovri.
Unu maŝino jam havas aprobitan VPN-aliron, dua maŝino bezonas ĝuste unu privatan HTTPS-servon, kaj loka SSH-plusendo povas ponti tiun breĉon sen doni al la dua maŝino tunelon. La plusendo portas unu TCP-celon anstataŭ la tutan reton, kaj ĝuste tiu limo estas la punkto. Trairu la kvin paŝojn sube laŭorde, ĉar ĉiu malsukcesas pro malsama kaŭzo kaj posta paŝo ne povas savi pli fruan breĉon. Se mankas iu ajn antaŭkondiĉo, ĉi tiu dezajno ne solvas ĝin, kaj neniu agordado de komandoj helpos.
Paŝo unu: konfirmu la tri antaŭkondiĉojn
Tri aferoj jam devas esti veraj antaŭ ol iu komando gravas. Vi bezonas permeson uzi la unuan maŝinon kiel plusendan gastiganton, funkciantan SSH-aliron al ĝi, kaj servilan politikon, kiu permesas la celitan celon. SSH-konto kreita por dosiera transdono eble havas plusendadon malŝaltita, kaj servilo, kiu permesas plusendadon, tamen povas limigi, kiuj celoj estas atingeblaj tra ĝi. Demandu antaŭ ol testi, ĉar uzi la laborejon de kolego kiel saltpunkton sen interkonsento estas politika problemo, eĉ kiam la komando funkcias senriproĉe.
Du komandoj solvas la teknikan duonon de tiu listo. La unua pruvas, ke la konto kaj ŝlosilo funkcias sen interaga instigo, kaj la dua presas la efektivan servilan politikon anstataŭ la komentitan ekzemplon en la agorda dosiero.
ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'
Paŝo du: ligi loopback-pordon kaj teni la sesion viva
Sur la maŝino, kiu rulas la klientan aplikaĵon, malfermu lokan plusendon al la privata servo. Ligu ĝin eksplicite al loopback, por ke ĝi ne estu publikigata en la loka reto, kaj elektu altan pordon, kiun neniu loka servo jam okupas. Tenu la sesion funkcianta dum vi laboras, ĉar fermo de ĝi fermas la aŭskultanton. ExitOnForwardFailure igas rifuzitan ligon aŭ okupitan pordon tuja eliro anstataŭ sesio, kiu restas malfermita sen plusendo, kaj tio estas la malsukcesa reĝimo, kiu malŝparas la plej multe da tempo.
La privata konekto estas farata de la saltgastiganto, do ĝia DNS, itineroj, VPN-politiko kaj serva aliro ĉiuj devas funkcii. La SSH-sesio ne kreas atingeblon, kiun la saltgastiganto ne havas, kaj ĝi ne povas ripari itinero, kiun la VPN neniam puŝis. Konfirmu la aŭskultanton tie, kie ĝi efektive estas, anstataŭ fidi la silenton de la komando.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'
Paŝo tri: konservu la HTTPS-nomon kiam la ingo estas loka
Retumi al https://127.0.0.1:9443/ ŝanĝas la TLS-servilnomon kaj la aplikaĵan aŭtoritaton. Atestilo eldonita por portal.lab.example ne validiĝos kontraŭ loopback-adreso, kaj la rezulta eraro aspektas kiel rompita atestilo anstataŭ kiel plusenda fuĝvojo. Por komandlinia testado konservu la veran URL-on kaj ŝanĝu nur la celon de la ingo. Tion faras --connect-to, kaj la manlibro de curl dokumentas la kvar-kampan formon uzatan sube.
curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/
La nomo restas en la URL, en la TLS-manpremo kaj en la Host-kapo, dum la TCP-konekto iras al la loka aŭskultanto. La senprokura opcio tenas la teston sur ĉi tiu plusendo anstataŭ lasi agorditan HTTP-prokuron interkapti ĝin, kaj teni atestilan validigon ŝaltita estas tio, kio faras la rezulton senchava.
Paŝo kvar: sciu, kion unu plusendo ne povas kovri
Unu TCP-plusendo kovras unu celan pordon. Paĝo, kiu alidirektas al dua gastigantnomo, ŝarĝas rimedojn de gastiganto ene de la privata reto aŭ sendas al alia pordo, bezonas sian propran plusendon, kaj ĉiu el ili bezonas la saman politikan kontrolon kiel la unua. Retumilaj laborfluoj aldonas proprajn postulojn, ĉar oni devas diri al la retumilo sendi la veran nomon al la loka pordo per prokura agordo aŭ loka mapado. Sukcesa komandlinia testado do ne pruvas, ke la retumilo sukcesos, kvankam ĝi pruvas la vojon.
UDP, SMB-malkovro kaj domajna ensaluto tute ne vojaĝas tra TCP-plusendo. Se la vera bezono estas ĝenerala reta aliro, ĉi tiu dezajno estas la malĝusta ilo kaj subtenata fora-alira enirejo estas la ĝusta.
Paŝo kvin: purigu kaj registru
Haltigu la sesion kiam la testado finiĝis kaj konfirmu, ke la aŭskultanto malaperis. Se la elektita pordo jam estis okupita, elektu alian neuzatan loopback-pordon kaj ĝisdatigu kune la URL-on, la testan komandon kaj la noton, anstataŭ haltigi nerilatan lokan servon por liberigi la numeron. Lasi plusendon malfermita sur tekkomputilo ŝanĝas diagnozon en neadministritan servon.
Notu la saltgastiganton, la plusenditan celon, la lokan pordon kaj kiu aprobis la aranĝon. Plusendo, kiu ekzistas nur en ies ŝela historio, estas unu restartigo for de ripeta enketo, kaj la sekva persono ne scios, kiu el la tri antaŭkondiĉoj jam estis kontrolita.