Kādu lietotnes datu plūsmu SSH pāradresēšana patiešām pārvadā?

Terminālis pieslēdzas, uzvedne parādās, un visi piekrīt, ka SSH piekļuve darbojas. Tad datubāzes klients klēpjdatorā joprojām nevar sasniegt privāto resursdatoru, un vaino sesiju. Uzbūvētais bija čaula, un tā ir viena no četrām diezgan atšķirīgām saskarnēm, ko SSH var piedāvāt. Vispirms nosauciet saskarni, pēc tam pārbaudiet, vai lietotne to patiešām izmanto. Secība ir svarīga, jo katra saskarne neizdodas savā veidā.

Nosauciet saskarni, pirms kaut ko salīdzināt

OpenSSH klienta rokasgrāmata izšķir četrus viegli sajaucamus mehānismus. Čaula vai attālināta komanda tiek izpildīta SSH resursdatorā. Lokālā pāradresēšana atver klausošu ligzdu klientā un veic tālāko savienojumu no attālās puses. Attālinātā pāradresēšana dara pretējo, klausoties servera pusē. Dinamiskā pāradresēšana atklāj SOCKS galapunktu programmām, kas prot to izmantot.

• Čaula: programma darbojas attālajā mašīnā, lokāli nekas neklausās.
• Lokālā pāradresēšana: jūsu klēpjdatoram ir ports, attālais resursdators veic izejošo savienojumu.
• Attālinātā pāradresēšana: attālajā pusē ir ports, datu plūsma nāk atpakaļ pie jums.
• Dinamiskā: SOCKS starpniekserveris klientā, to izmanto tikai starpniekserveri saprotošas lietotnes.

Neviena no tām neinstalē maršrutu. Programma, kas ignorē starpniekservera iestatījumus, vai runā UDP, vai pati atrisina nosaukumus, to neietekmē aktīva SSH sesija. Tā nav SSH kļūda; tas ir jūsu izvēlētās saskarnes apjoms.

Lokālā, attālinātā un dinamiskā pāradresēšana atšķiras ar to, kas klausās

Atšķirība, kas nosaka vairumu gadījumu, ir tas, kam pieder klausošā ligzda. Lokālajā pāradresēšanā klients klausās un tālais gals izsauc galamērķi, tāpēc galamērķa adrese tiek atrisināta no servera viedokļa. Attālinātajā pāradresēšanā serveris klausās un savienojums tiek nests atpakaļ uz jūsu pusi, un tā jūs atklājat lokālu pakalpojumu, to tieši nepublicējot.

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

Pirmā komanda piesaista portu 5432 klēpjdatorā un pāradresē to uz datubāzi, kā tā redzama no bastiona. Otrā izveido SOCKS starpniekserveri portā 1080. Trešā komanda apstiprina, kuri procesi patiešām klausās, un tas ir vienīgais pierādījums, ka pāradresēšana pastāv, nevis klusi neizdevās portu konflikta dēļ.

Dinamiskā pāradresēšana pelnījusi savu brīdinājumu: tā aptver tikai lietotnes, kas respektē SOCKS. Pārlūku var novirzīt uz to, komandrindas rīkam var teikt to izmantot, bet datubāzes draiveris ar savu savienojumu steku parasti to nevar. Pieņēmums, ka tagad katra programma mašīnā izmanto tuneli, ir visizplatītākā kļūda visā šajā jomā.

Tuneļa ierīces režīms ir vienīgais īstais tīkla izņēmums

OpenSSH atbalsta arī -w tuneļa ierīces pāradresēšanu, kas nodod no punkta uz punktu saskarni, nevis TCP klausītāju. Tas ir īsts tīkla tunelis, un tas tiek konfigurēts apzināti, nevis kā čaulas atvēršanas blakusefekts.

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

Tam nepieciešami attiecīgie saskarnes numuri abos galos, pareiza konfigurācija serverī un pietiekamas tiesības klientā ierīces izveidei. Tam nepieciešams arī adresācijas un maršrutēšanas plāns, jo kaila saskarne nenes nekādu politiku par to, kuri galamērķi to izmantos.

Pat tad tunelis beidzas attālajā resursdatorā. Kāda vien būtu SSH transporta sniegtā aizsardzība, tā beidzas tur, un tālākais savienojums ir atsevišķs lēciens. VPN vārtejai ir tāda pati robežas forma, tāpēc salīdzinājumam jābūt par apjomu un beigām, nevis par to, kurš rīks ir stiprāks. Šīs robežas skaļa nosaukšana arī izbeidz strīdu par to, vai tunelis «šifrē visu», jo acīmredzami nešifrē.

Pārbaudiet, vai jūsu lietotne izmanto jūsu būvēto saskarni

Pārbaude tiek veikta katrai lietotnei, nevis sesijai. Strādājoša pāradresēšana pierāda, ka ports ir piesaistīts un tālais gals var izsaukt; tā nepierāda, ka programma, kas jums svarīga, savienojās caur to.

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'

Pirmā komanda sūta pieprasījumu caur SOCKS galapunktu ar attālināti atrisinātu resursdatora nosaukumu, un otrā pārbauda pāradresēto datubāzes portu, kamēr TLS joprojām tiek prasīts. Palaidiet tos pašus testus ar apstādinātu pāradresēšanu, lai apstiprinātu, ka tie neizdodas, jo tests, kas iztur abos veidos, tuneli nekad nav izmantojis.

Pēc tam salīdziniet ar maršrutētu VPN tikai tajos aspektos, kas ir svarīgi: kuri galamērķi ir aptverti, kuri protokoli darbojas, kur beidzas aizsardzība un kam jāapstiprina piekļuve. Viena pakalpojuma pāradresēšana var būt šaurāka un labāka atbilde, savukārt VPN ir pareizā forma, kad daudzām lietotnēm vajadzīgs viens un tas pats tīkla ceļš. Neviens no tiem nedod visu, kas sasniedzams no tā attālā galapunkta.