Kiun aplikaĵan trafikon SSH-plusendo efektive portas?

La terminalo konektiĝas, la invito aperas, kaj ĉiuj konsentas, ke la SSH-aliro funkcias. Poste datumbaza kliento sur la tekkomputilo ankoraŭ ne povas atingi la privatan gastiganton, kaj la sesio estas kulpigita. Tio, kio estis konstruita, estis ŝelo, kaj ĝi estas unu el kvar tute malsamaj interfacoj, kiujn SSH povas proponi. Unue nomu la interfacon, poste testu, ke la aplikaĵo efektive uzas ĝin. La ordo gravas, ĉar ĉiu interfaco malsukcesas laŭ sia propra maniero.

Nomu la interfacon antaŭ ol kompari ion ajn

La manlibro de la OpenSSH-kliento distingas kvar mekanismojn, kiuj facile konfuziĝas. Ŝelo aŭ fora komando plenumiĝas sur la SSH-gastiganto. Loka plusendo malfermas aŭskultantan soketon sur la kliento kaj faras la pluan konekton de la fora flanko. Fora plusendo faras la malon, aŭskultante sur la servila flanko. Dinamika plusendo prezentas SOCKS-finpunkton por programoj, kiuj scias uzi ĝin.

• Ŝelo: la programo ruliĝas sur la fora maŝino, nenio aŭskultas loke.
• Loka plusendo: via tekkomputilo havas pordon, la fora gastiganto faras la eliran konekton.
• Fora plusendo: la fora flanko havas pordon, la trafiko revenas al vi.
• Dinamika: SOCKS-prokurilo sur la kliento, uzata nur de prokuril-konsciaj aplikaĵoj.

Neniu el ĉi tiuj instalas itineron. Programo, kiu ignoras prokurilajn agordojn, aŭ parolas UDP, aŭ solvas nomojn mem, ne estas tuŝata de aktiva SSH-sesio. Tio ne estas cimo en SSH; ĝi estas la amplekso de la interfaco, kiun vi elektis.

Loka, fora kaj dinamika plusendoj malsamas laŭ tio, kiu aŭskultas

La distingo, kiu decidas la plej multajn kazojn, estas kiu posedas la aŭskultantan soketon. Ĉe loka plusendo la kliento aŭskultas kaj la fora fino vokas la celon, tial la cela adreso estas solvata el la vidpunkto de la servilo. Ĉe fora plusendo la servilo aŭskultas kaj la konekto estas portata reen al via flanko, kaj tiel vi elmontras lokan servon sen rekte publikigi ĝin.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

La unua komando ligas pordon 5432 sur la tekkomputilo kaj plusendas ĝin al la datumbazo, kiel ĝi videblas de la bastiono. La dua kreas SOCKS-prokurilon sur pordo 1080. La tria komando konfirmas, kiuj procezoj efektive aŭskultas, kaj tio estas la sola pruvo, ke la plusendo ekzistas, anstataŭ malsukcesis silente pro pordokolizio.

Dinamika plusendo meritas propran averton: ĝi kovras nur aplikaĵojn, kiuj respektas SOCKS. Retumilo povas esti direktita al ĝi, komandlinia ilo povas esti instrukciita uzi ĝin, sed datumbaza pelilo kun propra konekta stako kutime ne povas. Supozi, ke ĉiu programo sur la maŝino nun uzas la tunelon, estas la plej ofta eraro en ĉi tiu tuta kampo.

Tunel-aparata reĝimo estas la sola vera reta escepto

OpenSSH ankaŭ subtenas -w tunel-aparatan plusendon, kiu pasigas punkt-al-punktan interfacon anstataŭ TCP-aŭskultanton. Tio estas vera reta tunelo, kaj ĝi estas intence agordita, ne kromefiko de malfermo de ŝelo.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Ĝi bezonas la respondajn interfacajn numerojn disponeblajn ĉe ambaŭ finoj, la ĝustan agordon sur la servilo kaj sufiĉan privilegion sur la kliento por krei la aparaton. Ĝi ankaŭ bezonas adresan kaj enkursigan planon, ĉar nuda interfaco portas neniun politikon pri tio, kiuj celoj uzu ĝin.

Eĉ tiam la tunelo finiĝas ĉe la fora gastiganto. Kiun ajn protekton la SSH-transporto donis, ĝi finiĝas tie, kaj la plua konekto estas aparta salto. VPN-enirejo havas la saman formon de limo, tial la komparo devus temi pri amplekso kaj finiĝo, ne pri tio, kiu ilo estas pli forta. Nomante tiun limon laŭte ankaŭ solvas la disputon pri tio, ĉu tunelo «ĉifras ĉion», ĉar ĝi videble ne faras tion.

Testu, ke via aplikaĵo uzas la interfacon, kiun vi konstruis

La kontrolo estas por ĉiu aplikaĵo, ne por la sesio. Funkcianta plusendo pruvas, ke la pordo estas ligita kaj la fora flanko povas voki; ĝi ne pruvas, ke la programo, pri kiu vi zorgas, konektiĝis tra ĝi.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

La unua komando sendas peton tra la SOCKS-finpunkto kun la gastigantnomo solvata fore, kaj la dua ekzercas la plusenditan datumbazan pordon kun TLS ankoraŭ postulata. Rulu la samajn testojn kun la plusendo haltigita por konfirmi, ke ili malsukcesas, ĉar testoj, kiuj sukcesas ambaŭmaniere, neniam uzis la tunelon.

Poste komparu kun enkursigita VPN nur laŭ la dimensioj, kiuj gravas: kiuj celoj estas kovritaj, kiuj protokoloj funkcias, kie protekto finiĝas kaj kiu devas aprobi la aliron. Plusendo por unu servo povas esti la pli mallarĝa kaj pli bona respondo, dum VPN estas la ĝusta formo, kiam multaj aplikaĵoj bezonas la saman retan vojon. Neniu el la du donas ĉion atingeblan de sia fora finpunkto.