Lietotnei, kas runā tikai SOCKS, parastā VPN nav ar ko runāt, jo tunelis pārvieto paketes, bet lietotne grib starpniekservera galapunktu. OpenSSH var nodrošināt šo punktu, kad piekļuves īpašnieks to atļauj, jo dinamiskā pāradresācija vienu SSH sesiju pārvērš vietējā starpniekserverī. Pēc tam ir divi lēcieni, kas jātur atsevišķi: tunelis, kas sasniedz SSH resursdatoru, un savienojums, ko šis resursdators tālāk atver. To nošķiršana izskaidro gan to, kāpēc šī kārtība strādā, gan to, ko tā nekad nedarīs.

Par ko SSH klausītājs kļūst un par ko ne

Dinamiskā pāradresācija liek SSH klientam klausīties lokāli un runāt SOCKS4 vai SOCKS5 ar visu, kas pieslēdzas. Katrs pieprasījums nosauc galamērķi, un SSH serveris atver tālāko savienojumu, tāpēc galamērķa meklēšana var notikt otrā pusē. Tā ir TCP pāradresācija lietotnes līmenī, nevis VPN visai ierīcei. Tā nepārvieto ne UDP asociāciju, ne ICMP, ne neko tām lietotnēm, kas pilnībā ignorē starpniekservera iestatījumus. Arī lēciens no SSH servera līdz lietotnei nav jūsu tuneļa iekšpusē, un tas ir svarīgi, kad galamērķis pieņem datplūsmu tikai no zināmiem tīkliem.

Priekšnosacījumi ir reāli: maršruts uz SSH resursdatoru, autorizēts konts, pārbaudīta servera resursdatora atslēga un atļauja pāradresēt. Nevienu no tiem neveido starpniekserveris, un pēdējā parasti trūkst vispirms. Apstipriniet visas četras, pirms atkļūdojat ko citu, jo no klienta puses kļūme izskatās vienādi, kura gan trūkst.

Palaidiet to uz loopback ar skaidru portu

Izvēlieties neizmantotu lokālu portu un skaidri piesaistiet to loopback, nevis atstājiet adresi tukšu. Trīs zemāk esošās opcijas pastāv katra viena iemesla dēļ.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N izlaiž attālo komandu, un -T izlaiž pseidotermināli, tāpēc sesija pastāv tikai pāradresēšanai. ExitOnForwardFailure liek klientam iziet, kad klausītāju nevar izveidot, nevis darboties bez pieprasītās pāradresācijas. ControlPath=none tur sesiju ārpus esoša multipleksēta savienojuma, kas varētu pievienot savas pāradresācijas. Loopback tur klausītāju ārpus LAN, bet koplietotā mašīnā tā nav autorizācijas robeža, jo tam var piekļūt arī citi lokālie procesi. OpenSSH klienta uzziņa dokumentē visus šos karodziņus, un brīdinājums par loopback izriet no tā, kas ir klausoša ligzda.

Sūtiet vārdus caur starpniekserveri, nevis tam apkārt

SOCKS5 klients var pats atrisināt galamērķi vai lūgt starpniekserveri to darīt, un šī izvēle nosaka, kurš atrisinātājs atbildēs. Ar socks5h curl sūta resursdatora vārdu caur starpniekserveri, tāpēc meklēšana notiek SSH serverī. Ar vienkāršu socks5 portatīvais dators vispirms atrisina, un ceļo tikai savienojums, kas klusi iznīcina jēgu, ja vārds ir iekšējs. Zemāk esošais pieprasījums arī iztīra sarakstu bez starpniekservera, lai mantotā NO_PROXY vērtība nevarētu to virzīt apkārt starpniekserverim.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

Sertifikāta pārbaude un pašas lietotnes pieteikšanās joprojām ir spēkā, jo starpniekserveris neaizstāj nevienu no tiem. Paliek divas meklēšanas: portatīvajam datoram jāsasniedz SSH resursdators atļautajā VPN un DNS ceļā, un SSH serverim pašam jāatrisina lietotnes vārds. Otro var pārbaudīt atsevišķi, pirms jebkura datplūsma iet caur starpniekserveri.

ssh [email protected] getent hosts app.corp.example

Pierādiet vienu atļautu galamērķi, tad aizveriet sesiju

Pārbaudiet galamērķi, ko politika atļauj, un to, ko tai vajadzētu noraidīt, jo strādājoša pāradresācija pierāda tikai to, ka klausītājs strādā, un neko vairāk. Lietotne redz avota adresi, ko izvēlas SSH serveris, un tā nav jūsu portatīvā datora tuneļa adrese. Kur tālā puse reģistrē savienojumus pēc avota, šī atšķirība ir pirmā lieta, kas jāpārbauda, kad pieprasījums tiek noraidīts.

Apturiet sesiju ar procesu, kuram tā pieder, nevis nogalinot nesaistītu čaulu. Pēc tam apstipriniet, ka klausītājs ir pazudis, jo ports, kas vēl atbild, ir sesija, kuru jūs īsti neaizvērāt. Noņemiet tikai to starpniekservera iestatījumu, ko ieviesa šis vingrinājums, un atstājiet pārējo lietotnes konfigurāciju mierā. Neuzraudzīts terminālis ar pāradresācijas noteikumu nav pakalpojums, un pastāvīgam starpniekserverim vajag apstiprinātu dzīves ciklu, nevis aizmirstu logu.

ss -ltn | grep 1080

Kļūmes, ko šī kārtība nevar izlabot

Daži simptomi norāda tieši uz iepriekš minētajām robežām, un to agrīna atpazīšana ietaupa pēcpusdienu starpniekservera atkļūdošanas. Tabula saista to, ko redzat, ar to, ko tas parasti nozīmē. Viss pēdējā kolonnā ir dizaina jautājums, nevis konfigurācijas kļūda.

What you seeWhat it usually meansWhere to look
The app connects and nothing followsIt ignores proxy settings entirelyIts own network settings, not the SSH session
A name resolution error for the destinationThe SSH server cannot resolve itServer resolver and search domains
A UDP-only application failsDynamic forwarding carries TCP onlyThis arrangement cannot serve it
curl works, the browser does notThe browser is not using the socks5h endpointBrowser proxy configuration
The listener answers after the session endedAnother process owns port 1080The ss output, then the owning process

Pirmās trīs rindas ir tās, ko cilvēki diagnosticē nepareizi, jo katra rada savienojuma mēģinājumu, nevis kļūdu par pašu starpniekserveri. Vārds, kas tiek atrisināts portatīvajā datorā, neko nepasaka par servera atrisinātāju, un kļūme tiek lasīta kā sertifikāta vai noildzes problēma. Lietotnes, kas darbojas tikai ar UDP, stāv ārpus dizaina, nevis salūzušas tā iekšienē, un neviena papildu ssh opcija to nemaina. Pārlūka rinda ir parastais atgādinājums, ka starpniekservera iestatījumi attiecas uz katru lietotni atsevišķi. Pēdējā rinda ir iemesls, kāpēc pastāv aizvēršanas pārbaude: ports, kas vēl klausās, nozīmē, ka tagad to pārvalda kaut kas cits.

Saistītie raksti