• hjem
  •  > 
  • Sette opp Windows 10
  •  > 
  • Opprette SSH-tunneler ved hjelp av PuTTY. Hva er SSH-tunneling og hvorfor er det nødvendig?

Opprette SSH-tunneler ved hjelp av PuTTY. Hva er SSH-tunneling og hvorfor er det nødvendig?

Denne artikkelen vil beskrive hvordan du bygger SSH-tunneler ved hjelp av PuTTY.

1. Lokal portvideresending

Tenk på følgende situasjon. Vi er inne bedriftsnettverk, datamaskinen vår har adressen 192.168.0.2, tilgangen til omverdenen er helt stengt (det vil si ingen NAT, proxy osv.). Vi har ikke mulighet til å påvirke tilgangsbegrensningspolicyen, men vi har SSH-tilgang til en av serverne med en rutbar IP-adresse som er tilgjengelig fra Internett. La for eksempel den interne adressen til denne serveren være 192.168.0.3. Nettverksstrukturen er vist i figuren:

La oss anta at vi virkelig trenger å koble til, for eksempel via SSH, til en ekstern server med IP-adressen 212.212.212.212 et sted langt unna på Internett. For å gjøre dette, start PuTTY, opprett en SSH-tilkobling til server 192.168.0.3 (heretter referert til som SSH-økt 1), gå til Tunnels-elementet:

og indikere at lokal port 2222 på datamaskinen vår skal matches med port 22 på serveren med IP-adresse 212.212.212.212. Klikk deretter på "Åpne"-knappen og logg på server 192.168.0.3. Deretter oppretter vi en annen tilkobling (heretter referert til som SSH-økt 2), men på localhost, port 2222 og klikk på "Åpne"-knappen:

Som et resultat vil SSH-økt 2 bli tunnelert (det vil si at den vil bli installert inne i den tidligere etablerte SSH-økt 1). For den eksterne serveren 212.212.212.212 vil alt se ut som om 111.111.111.111 kobler til den:

2. Ekstern portvideresending

I dette tilfellet etableres forbindelsen inne i SSH-tunnelen i den andre retningen - fra den eksterne serveren til vår lokale datamaskin. Det kan være nyttig hvis du trenger å åpne tilgang til lokale tjenester på datamaskinen. La oss vurdere det samme nettverket som i punkt 1, men for enkelhets skyld, la oss anta at vi nå har NAT:

Her har vi allerede muligheten til å koble via SSH direkte til 212.212.212.212 takket være tilstedeværelsen av NAT. Men 212.212.212.212 vil selvfølgelig ikke kunne kobles til 192.168.0.2 uten spesielle triks, fordi 192.168.0.2 er ikke direkte koblet til Internett. La oss anta at en bruker som sitter under X på 212.212.212.212 trenger å komme til datamaskinen vår 192.168.0.2 via eksternt skrivebord. For å gjøre dette, i en SSH-tilkoblingsøkt fra 192.168.0.2 til 212.212.212.212, må du endre innstillingene i Tunnels-delen som følger:

#lsof -i -nP | grep 3333 sshd 18598 avz 11u IPv4 592868957 TCP 127.0.0.1:3333 (LYTT)

Det vil si at sshd venter på tilkoblinger på TCP-port 3333, som deretter vil bli omdirigert via SSH-tunnelen til 192.168.0.2 port 3389. Og brukeren som sitter på 212.212.212.212 vil kunne se skrivebordet vårt ved å bruke rdesktop:

3. Sokker-proxy

I dette tilfellet kan vi bruke en server med en SSH-demon som mellomliggende (proxy). Nettverksdiagram som i tilfelle #1 (uten NAT og vanlige proxyer):

For å tvinge PuTTY til å fungere som socks proxy, må du endre SSH-sesjonsparameterne fra 192.168.0.2 til 192.168.0.3 som følger:

C:\>netstat -ano | finn "1080" TCP 127.0.0.1:1080 0.0.0.0:0 LYTTING 2392 C:\>oppgaveliste | finn /i "2392" putty.exe 2392 Console 0 5420 KB

Det vil si at kitt som kjører med PID 2392 begynner å lytte på port 1080 og venter på tilkoblinger. Deretter tar vi et hvilket som helst program som kan fungere med en SOCKS-proxy, for eksempel Firefox, og ber den bruke proxyen vår:

Nå vil alle forespørsler fra nettleseren gå gjennom server 192.168.0.3. Loggene til nettsidene som vi vil besøke på denne måten vil vise den eksterne IP-adressen til serveren vår - 111.111.111.111.

P.S. Fra Putty 0.58 hjelpefilen:

Spørsmål A.10.3: Hva betyr "PuTTY"?

Det er navnet på en populær SSH- og Telnet-klient. Enhver annen betydning er i betrakterens øye. Det har gått rykter om at "PuTTY" er antonymet til "getty", eller at det er tingene som gjør Windows-en din nyttig... :)

Vennligst aktiver JavaScript

© 2009–2019, nettsted - Når du bruker nettstedmateriale, er det tilrådelig å angi kilden. Takk skal du ha!

28. mars 2012 av Jayson Broughton
i HVORDAN-TOS SysAdmin

"Hvis du ser et lys i enden av en tunnel, er det lyset fra et tog som nærmer seg," Robert Lowell. Nok et godt sitat. Denne artikkelen handler om å bygge tunneler med bruker SSH, eller som jeg kaller dette emnet, "VPN-tunneler for de fattige." Til tross for den grunnleggende troen til systemadministratorer, kan SSH-tunneler faktisk være ganske nyttig ting både for teknikere og hjemmebruk. Jeg sier "til tross for systemadministratorenes tro" fordi omvendte tunneler eller nettrafikk pakket inn i SSH kan komme gjennom brannmurer og innholdsfiltre. Artikkelen handler imidlertid ikke om hvordan du kan undergrave bedriftens sikkerhetspolitikk, men om hvordan SSH-tunnelering kan gjøre livene våre litt mindre kompliserte.

Hvorfor SSH-tunneler i stedet for VPN? Ok, jeg bruker det og det hjemme. Hvis du har fulgt meg på jaysonbroughton.com, vet du at jeg har OpenVPN trefaktorautentisering (brukernavn, sertifikat og engangspassord) i arbeid. Men hvis jeg vil sjekke en av serverne under min kontroll via Android, eller se på en datamaskin som jeg ikke har administrative rettigheter på (og den bærbare OpenVPN-klienten trenger dem), eller til og med ønsker å fikse noen feil ved å bruke vnc-tilgang over SSH-tunnel, da er SSH mitt valg av måte å sikre trafikk på.

Vi vil diskutere det grunnleggende: hvordan bygge en tunnel, hva hver kommandosyntaks betyr, eksempler på omvendte tunneler og situasjoner der du bør bruke en eller annen tilnærming. Jeg gikk også kort gjennom strukturen til konfigurasjonsfilen.

Så åh Systemkrav. Jeg bruker Debian i et virtuelt miljø, så resultatene dine kan variere fra mine. Derfor gir jeg informasjon om verktøyene: OpenSSH_5.3p1-serveren og OpenSSH 5.X-klienter av forskjellige versjoner er i bruk. Før du dykker ned i dypet av ssh-tunnelering, må jeg si: før du stikker et hull i et selskaps sikkerhet ved å bruke en omvendt tunnel eller pakker inn http-trafikk, sørg for at du ikke bryter noen stabel med interne forskrifter, slik som policyen for akseptabel bruk av Internett. Det er klart at i dette tilfellet vil systemadministratorene umiddelbart jakte på deg og steke deg, spesielt hvis du bruker en tunnel for å komme deg til serveren på jobb hjemmefra. Som systemadministrator selv får jeg stor glede av å oppdage slike karakterer. Tro meg, med litt sjekk viser det seg at systemadministratorer ikke er idioter i det hele tatt.

Vel, ansvarsfraskrivelsen er kunngjort, du kan komme i gang.

Å bygge SSH-tunneler er en ganske enkel ting. Å forstå hva som skjer og læremetoder kan være litt vanskeligere. Så jeg skal gi noen typiske tilfellerå justere bevisstheten før vi går videre til detaljene i kommandoene. Før jeg fikk barn reiste jeg en del. I mine reiser har jeg funnet meg selv i veldig merkelige hoteller, rommene som hadde veldig merkelige Wi-Fi-punkter adgang. Vil du virkelig koble til et hotelltilgangspunkt hvis SSID er skrevet inn i uoversettelig gobbledygook? Eller på flyplassen, hvor flere åpne nettverk? Når jeg er et sted i omverdenen, foretrekker jeg å tunnelere nettrafikk til min rotfestede android via hjemmeserver. Når jeg har den bærbare datamaskinen i hendene åpner jeg en ssh-tunnel og omdirigerer nettrafikk gjennom socks5 slik at all trafikk som kommer til meg er kryptert. Jeg stoler bare på åpne WAP-er i den grad jeg kan navigere gjennom dem. Hva mer med klartekst? Jeg tunnelerer SMTP-trafikk på datamaskinen min gjennom hjemmeserveren min når jeg noen steder ser at utgående SMTP er blokkert. Situasjonen er lik med POP3. Et annet eksempel: du kan administrere X-applikasjoner gjennom en tunnel. Du kan pakke VNC-økter i en tunnel. En av teknikkene jeg begynte å bruke tidligere enn andre var omvendte tunneler. I dette tilfellet lager du en tunnel fra en server som er bak en brannmur. Når du logger på den SSH-serveren, kan du gjenopprette forbindelsen.

Eksempler

Før du ser på klientsiden, må du gjøre noen ting på serversiden ved å redigere konfigurasjonsfilen sshd.config, der jeg anbefaler å gjøre følgende endringer. Før du gjør endringer, kopier den opprinnelige konfigurasjonen for sikkerhets skyld i tilfelle noe går galt.

Hvis du har gjort endringer, må du starte sshd-serveren på nytt for å bruke dem.

La oss gå videre til tastene kommandolinje.

En typisk ssh-tunnel (uten X-protokolltunnel) ser omtrent slik ut:

Som du kanskje gjetter, tunnelerer -X-alternativet X. Husk imidlertid at kommandoen vil tunnelere applikasjonen din fra den eksterne maskinen til din Linux-klientmaskin. Hvis du er på Windows, installer bare Cygwin/X (http://x.cygwin.com/) på din gjestebil. Jeg har ikke prøvd dette selv, men som jeg forstår burde det hjelpe til med lanseringen ekstern X-applikasjon i Windows.

Når du skal etablere VNC-økter, må du være forsiktig. Hvis en ekstern VNC-server kjører på port 5900, sørg for at du ikke kobler til seg selv etterpå. Selve økten tunneleres som i andre tilfeller ved hjelp av en gjennomsiktig kommando:

Og nå har du det, en omvendt tunnel.

For klarhetens skyld slo daddoo og nerdboy4200 fra #linuxjournal seg sammen og skapte Mscgen, et program som analyserer en sekvens av meldinger og bygger et visuelt diagram over meldingsutveksling for forskjellige protokoller. Det er selvfølgelig åpen kildekode og ganske forferdelig å se på (http://www.mcternan.me.uk/mscgen/). For tilfellet med en reversibel tunnel, ved hjelp av produktet deres, bygde de et diagram (så la forfatteren inn et diagram i teksten sin, der ingenting er synlig - ca. trans.).

Konklusjon

Så hva du kan gjøre med tunneling er bare begrenset av fantasien din, vi har bare gitt noen få eksempler her. Kanskje i påfølgende innlegg vil jeg fortelle deg hvordan du konfigurerer SSH riktig på klientsiden.

Enhver systemadministrator må hele tiden jobbe eksternt, men det er situasjoner der du raskt trenger å koble til interne nettverksnoder som ikke er tilgjengelige fra utsiden. Det er bra hvis det er tilgang til andre noder i et gitt nettverk, men det skjer at tilgang fra globalt nettverk nei i det hele tatt, i disse tilfellene bruker de vanligvis TeamViewer eller lignende programvare, men hvis det er mulig å koble til et slikt nettverk via SSH eller etablere en forbindelse med en mellomliggende SSH-server, så kan du raskt og enkelt organisere tilgang uten å involvere tredje- partyprogramvare.

Svært ofte, når det gjelder ekstern tilgang til nettverk med lavt sikkerhetsnivå, er det første du tenker på en VPN, men av hensyn til administrative tilkoblinger er det ikke alltid tilrådelig å installere en VPN, spesielt når det kommer til outsourcing eller en "innkommende admin". I tillegg tillater ikke kommunikasjonsforholdene alltid en stabil VPN-forbindelse, spesielt hvis du må bruke mobilnettverk.

Dessuten, i nesten alle nettverk kan du finne en enhet eller server som kan nås via SSH, eller det er en slik mellomserver, for eksempel en VPS på det globale nettverket. I dette tilfellet flott løsning Det vil være SSH-tunneler som gjør det enkelt å organisere sikre kommunikasjonskanaler, blant annet gjennom mellomnoder, noe som eliminerer problemet med å ha en dedikert IP-adresse.

SSH-tunneler er strengt tatt ikke fullverdige tunneler og dette navnet bør betraktes som et stabilt navn som har utviklet seg i fagmiljøet. Det offisielle navnet på teknologien er SSH Port Forwarding er en valgfri funksjon i SSH-protokollen som lar deg overføre en TCP-pakke fra den ene siden av en SSH-forbindelse til den andre og under overføringsprosessen oversette IP-headeren i henhold til en forhåndsbestemt regel.

I motsetning til VPN-tunneler, som lar all trafikk overføres i alle retninger, har SSH-tunnelen et inngangspunkt og kan bare fungere med TCP-pakker. Faktisk ligner dette mest på portvideresending (som det offisielle navnet antyder), bare over SSH-protokollen.

La oss se på driften av SSH-tunnelen mer detaljert. Som et eksempel, la oss ta det klassiske tilfellet med å gi tilgang til en ekstern server via RDP-protokollen.

La oss si at det er en målserver med adressen 192.168.0.105 på det eksterne nettverket, men det er ingen tilgang til den fra det eksterne nettverket, den eneste enheten vi kan koble til er en ruter med adressen 192.168.0.1 som vi kan etablere en SSH-forbindelse.

La oss dvele ved veldig viktig poeng: setter alle SSH-tunnelparametere initiativtaker forbindelser, aka SSH klient, den andre enden av tunnelen er alltid serveren vi kobler til, aka SSH server. I i denne sammenhengen Klienten og serveren skal bare forstås som sider av forbindelsen, for eksempel kan en VPS-server fungere som en SSH-klient, og en administrators bærbare datamaskin kan fungere som en SSH-server.

Inngangspunktet kan ligge på hvilken som helst side tilkobling åpnes en TCP-kontakt der med spesifiserte parametere, som godtar innkommende tilkoblinger. Utgangspunktet kan ikke akseptere forbindelser, men ruter kun pakker i henhold til oversettelsesreglene.

La oss se på diagrammet ovenfor. Vi har etablert en SSH-tunnel fra den lokale maskinen til den eksterne ruteren, og spesifiserer lokal inngangspunkt 127.0.0.1:3389 Og oversettelsesregel 192.168.0.105:3389. Nok en gang gjør vi oppmerksom på at oversettelsesregelen ikke angir utgangspunktet, men bestemmer noden som pakker skal sendes til når de går ut av tunnelen. Hvis du spesifiserer en ugyldig adresse, eller verten ikke godtar tilkoblinger, vil SSH-tunnelen bli etablert, men det vil ikke være tilgang til målverten.

I henhold til det angitte inngangspunktet vil SSH-tjenesten opprette en lokal TCP-socket som vil lytte etter tilkoblinger på port 3389. Derfor spesifiserer vi i RDP-tilkoblingsvinduet som destinasjon lokal vert eller 127.0.0.1 , RDP-klienten åpner en dynamisk port og sender en pakke med destinasjonsadressen 127.0.0.1:3389 og kildeadresse 127.0.0.1:61256 , vet han ingenting om den virkelige destinasjonen til pakkemottakeren.

Fra inngangspunktet Gjeldende pakke vil bli sendt til den andre siden av SSH-tunnelen, og destinasjonsadressen i henhold til oversettelsesreglene vil bli endret til 192.168.0.105:3389 , og SSH-serveren vil ta en ytterligere avgjørelse i henhold til sin egen rutingtabell, og erstatte kildeadressen med sin egen, ellers vil målserveren prøve å sende en svarpakke til den lokale adressen.

Dermed fungerer RDP-klienten med en lokal socket og RDP-pakker går ikke utover denne noden; inne i tunnelen overføres de over SSH-protokollen i kryptert form, men det etableres en vanlig RDP-forbindelse mellom SSH-serveren og RDP-serveren på nettverket 192.168.0.0, V åpen form. Dette bør tas i betraktning når du bruker usikre protokoller, og husk at hvis oversettelsesregelen peker utover noden med utgangspunktet, så en slik forbindelse (mellom utgangspunktet og destinasjonsnoden) ikke forsvare seg via SSH.

Etter å ha funnet ut generell disposisjon hvordan SSH-tunneler fungerer, la oss gå videre til praktiske alternativer deres bruk, vil vi vurdere Linux-systemer av Debian/Ubuntu-familien som en plattform, men alt som er angitt nedenfor, med mindre endringer, vil være gyldig for ethvert UNIX-lignende system.

SSH-tunnel med lokalt inngangspunkt

Lokale inngangspunkttunneler brukes for å få tilgang til verter på et eksternt nettverk med muligheten til å etablere en SSH-forbindelse til en av vertene, som forutsetter at det eksterne nettverket har en dedikert IP-adresse.

Vi vil vurdere det samme alternativet, en RDP-tilkobling til en ekstern server, den oransje stiplede linjen i diagrammet indikerer en sikker SSH-tilkobling, og de blå pilene indikerer en vanlig TCP-tilkobling.

I selve enkel versjon vi oppretter ganske enkelt en forbindelse fra klient-PCen til ruteren på det eksterne nettverket, og spesifiserer målnoden i oversettelsesregelen:

Ssh -L 127.0.0.1:3389:192.168.0.105:3389 [e-postbeskyttet]

Nøkkel -L indikerer at inngangspunktet er lokalisert, deretter indikerer et kolon adressen og porten til inngangspunktet og adressen, porten til oversettelsesregelen. Utgangspunktet er noden som vi kobler oss til, dvs. rt.example.com.

Hvis nettverket ditt også har en ruter (eller annen Linux-server), kan du gjøre det til et inngangspunkt, som vil tillate enhver RDP-klient fra lokalt nettverk. I teorien, for å gjøre dette, bør du heve en tunnel som dette:

Ssh -L 192.168.31.100:3389:192.168.0.105:3389 [e-postbeskyttet]

I dette tilfellet vil SSH-tjenesten måtte åpne en TCP-socket på grensesnitt 192.168.31.100, men i praksis vil dette ikke skje. Dette skyldes implementeringsfunksjonene til OpenSSH, som er standarden for de aller fleste UNIX-lignende systemer.

Som standard åpner OpenSSH et inngangspunkt bare på lokalt grensesnitt. Det er enkelt å verifisere dette:

For å gi tilgang til en TCP-socket fra eksterne grensesnitt, bør du bruke nøkkelen -g, eller legg til i konfigurasjonsfilen /etc/ssh/sshd_config alternativ:

GatewayPorts ja

Etter dette vil imidlertid stikkontakten godta tilkoblinger fra noen initiator nettverksgrensesnitt:

Dette betyr at port 3389 vil være åpen på alle nettverksgrensesnitt, så hvis inngangspunktet er en kantenhet, bør tilgangen til stikkontakten begrenses, for eksempel ved bruk av iptables. La oss for eksempel blokkere tilgang fra det eksterne nettverket (eth0-grensesnitt):

Iptables -A INPUT -i eth0 -p tcp --dport 3389 -j DROP

Dermed bør arbeidstunnelen heves med kommandoen:

Ssh -L -g 3389:192.168.0.105:3389 [e-postbeskyttet]

Vær oppmerksom på en ting til: Hvis inngangspunktet samsvarer med det lokale grensesnittet, og for OpenSSH er dette alltid tilfelle, kan det utelates ved å umiddelbart starte kommandoen fra inngangspunktporten.

Vi anbefaler også å bruke nøkkelen hvis mulig -g, i stedet for å legge til alternativet i konfigurasjonsfilen, siden du i sistnevnte tilfelle risikerer, ved å glemme denne innstillingen, å åpne tilgang til ubeskyttede tjenester på det eksterne nettverket for omverdenen.

SSH-tunnel med eksternt inngangspunkt

En tunnel med et eksternt inngangspunkt tillater tvert imot å publisere enhver lokal tjeneste på et eksternt nettverk; en av de vanligste bruksområdene er tilgang til et nettverk uten en dedikert IP-adresse, men dette krever en "hvit" IP fra administratorens nettverk.

I det første alternativet etablerer den eksterne serveren selv en forbindelse med den lokale nettverksruteren. Dette kan gjøres med en enkel kommando:

Ssh -R 3389:127.0.0.1:3389 [e-postbeskyttet]

-R-tasten spesifiserer å åpne tilgangspunktet fra den eksterne siden av tunnelen, deretter spesifiserer vi porten for TCP-kontakten og oversettelsen, siden pakker som ankommer utgangspunktet skal behandles lokalt, spesifiserer vi også det lokale grensesnittet.

Den oppmerksomme leseren vil legge merke til at vi ikke har spesifisert nøkkelen -g, Ja, det er det. Faktum er at for tunneler med et eksternt inngangspunkt gitt nøkkel er ikke aktuelt og alternativet bør brukes

GatewayPorts ja

på SSH-serversiden.

Av sikkerhetsgrunner anbefaler vi å bruke denne innstillingen med standardpolicyen DROP for INPUT-kjeden, dette vil unngå utilsiktet publisering på eksternt grensesnitt interne tjenester og ressurser. I minimal konfigurasjon fire regler bør legges til helt i begynnelsen av INPUT-kjeden:

Iptables -P INPUT DROP
iptables -A INPUT -i eth0 -m stat --stat ETABLERET,RELATERET -j GODTAR
iptables -A INPUT -i eth1 -j GODTAR
iptables -A INPUT -i eth0 -p tcp --dport 22 -j GODKJENNER

Den første av disse setter standard avvisningspolicy for innkommende pakker, den andre tillater innkommende pakker initiert av verten selv (svar på utgående pakker), og den tredje tillater alle tilkoblinger fra det lokale nettverket. Til slutt åpner den fjerde regelen port 22 for innkommende SSH-tilkoblinger; på samme måte kan du åpne en hvilken som helst annen port for eksterne tilkoblinger.

Det andre alternativet presentert i diagrammet gir at SSH-tunnelen heves av nettverksrutere, i dette tilfellet vil kommandoen se slik ut:

Ssh -R 3389:192.168.0.105:3389 [e-postbeskyttet]

La oss igjen gjøre oppmerksom på at inngangspunktet vårt ligger på motsatt side av tunnelen, så sendingen er indikert for siden av tunnelinitiatoren, dvs. V i dette tilfellet SSH-klienten etablerer to tilkoblinger: en SSH med rt.example.com, og den andre RDP med 192.168.0.105, mens med en tunnel med et lokalt inngangspunkt etablerer initiativtakeren en enkelt tilkobling med SSH-serveren.

Dobbel SSH-tunnel

Ganske ofte oppstår situasjoner når du trenger å koble sammen to noder som ikke har dedikerte IP-adresser. I dette tilfellet bruker du vanligvis TeamViewer eller lignende tredjepartsprogramvare, men hvis du har en tilgjengelig server med en dedikert IP-adresse, kan du gjøre det enklere.

La oss ta hensyn til diagrammet ovenfor. SSH lar deg bygge hele kjeder av tunneler, og koble inngangspunktet til den neste til utgangspunktet til den forrige. For å få en tunnel fra admin-PCen til RDP-serveren, med begge noder med grå IP-adresser, må vi opprette to tunneler med mellomnode.

Tunnel med et lokalt inngangspunkt på admin-PCen:

Ssh -L 3389:127.0.0.1:3390 [e-postbeskyttet]

Og en tunnel med et eksternt inngangspunkt på RDP-serveren:

Ssh -R 3390:127.0.0.1:3389 [e-postbeskyttet]

Vi påpekte spesielt ekstern server ikke-standard port For større klarhet, la oss nå se hvordan det hele fungerer. La oss starte med RDP-serveren; den hever en tunnel med et eksternt inngangspunkt, åpner en TCP-kontakt på den mellomliggende serveren som vil akseptere tilkoblinger på port 3390; vi vil spesifisere selve RDP-serveren som en kringkasting - 127.0.0.1:3389, dvs. alle pakker som ankommer inngangen til denne tunnelen vil bli sendt til lokal port 3389.

En tunnel med et lokalt inngangspunkt på administratorens PC åpner en lokal kontakt på port 3389, der RDP-klienten kobles til; som en kringkasting spesifiserer vi inngangspunktet til den andre tunnelen - 127.0.0.1:3390.

Som vi allerede har sagt er det ingen begrensninger på antall tunneler i kjeden, men i praksis oppstår behovet for tunneler med mer enn én mellomnode ganske sjelden. Det bør huskes at med hver ny mellomnode vil påliteligheten til hele kretsen avta, og den endelige hastigheten vil være begrenset til hastigheten til den tregeste delen av banen.

Dynamisk SSH-tunnel

I motsetning til de som er diskutert ovenfor, fungerer en dynamisk tunnel annerledes; den åpner en lokal TCP-socket på verten, som kan brukes som en SOCKS4/SOCKS5-proxy for å få tilgang til Internett via en ekstern SSH-server. Dette kan være nyttig for å omgå noen begrensninger, når det ikke er behov for å installere en fullverdig VPN i en annen jurisdiksjon, og du ikke kan bruke offentlige proxyer eller VPN-er av sikkerhetsgrunner.

Denne typen tunneler er spesielt praktisk hvis du trenger engangstilgang til Internett fra en annen node. Et enkelt eksempel: en god venn av meg tok med to iPhone-er med operatørkontrakt fra USA og ba om å låse dem opp. Vanskeligheter denne operasjonen Ingen hemmelighet, hvis vilkårene i kontrakten ikke har blitt brutt, så bare gå til operatørens nettsted og fyll ut en søknad om opplåsing. Men problemet viste seg å være det operatør T-Mobile Tilgang til denne seksjonen Nettstedet var bare tilgjengelig for innbyggere i USA, og tilkoblinger fra offentlige fullmakter og VPN-er ble avvist som utrygge.

En dynamisk SSH-tunnel gjorde det mulig å raskt løse dette problemet ved hjelp av VPS i statene. For å lage en slik tunnel, skriv inn kommandoen:

Ssh-D 1080 [e-postbeskyttet]

Hvor 1080 er porten som vår SOCKS-proxy vil være tilgjengelig på. Alt som gjenstår er å konfigurere nettleseren til å bruke en lokal proxy-server.

En annen fordel med denne metoden er at proxy-serveren kun eksisterer lokalt på verten din, ingen ekstra porter trenger å åpnes til det eksterne nettverket, og det er kun en SSH-forbindelse mellom klienten og serveren.

Dette lar deg skjule innholdet til Internett-aktiviteten din for en ekstern observatør, noe som kan være nyttig i offentlige nettverk, der det er rimelig grunn til å tro at trafikk kan bli fanget opp og analysert av tredjeparter. I dette tilfellet gir SSH-tunnelen pålitelig kryptering av overførte data på et usikkert nettverk, men dette krever fullstendig tillit til serveren du får tilgang til Internett via.

Noen få ord om sikkerhet

Selv om dette er utenfor rammen av artikkelen, kunne vi ikke nevne en funksjon som kan bringe ganske ubehagelige overraskelser. Ved å heve SSH-tunnelen ved hjelp av en av kommandoene ovenfor, vil du også få, i tillegg til tunnelen, åpen konsoll på serveren du kobler til. Ta en nærmere titt på invitasjonslinjen i skjermbildet nedenfor.

Øverst ser vi en invitasjon fra den lokale verten, og nederst, etter å ha hevet tunnelen, ser vi invitasjonen fra den eksterne serveren. Dette er praktisk hvis du trenger å sjekke kommunikasjonskanalen eller utføre visse innstillinger fra den eksterne siden, men i hverdagen kan dette føre til alvorlige problemer hvis du glemmer eller ikke tar hensyn til hvilken server konsollen er koblet til og utfører kommandoer på den eksterne serveren beregnet for den lokale noden, spesielt hvis du kobler til superbruker rettigheter.

Derfor, etter at du har sjekket funksjonaliteten til tunnelen, bør du starte den med -N-bryteren, som forbyr utførelse av kommandoer på den eksterne serveren, for eksempel:

Ssh -N -L -g 3389:192.168.0.105:3389 [e-postbeskyttet]

Og selvfølgelig bør du ikke bruke en superbrukerkonto for å koble til serveren; det er best å opprette en vanlig konto for disse formålene.

SSH-tunneler på Windows

Gjennom hele artikkelen så vi på SSH-tunneler ved å bruke eksemplet med Linux-systemer og Windows-brukere man kan få inntrykk av at disse mulighetene ikke er tilgjengelige for dem. Men dette er ikke sant; det er mange SSH-klienter for Windows som støtter oppretting av tunneler. Vi vil vurdere den mest populære av dem - PuTTY. Du kan også kjøre en SSH-server under Windows, men dette krever visse kvalifikasjoner og er ikke alltid mulig å oppnå stabil drift, så vi vil ikke vurdere dette alternativet.

La oss åpne PuTTY og gå til venstre side av treet Tilkobling - SSH - Tunneler:

Følgende vindu åpnes foran oss, hovedinnstillingene til tunnelen er konsentrert nederst, og vi har markert dem med en rød ramme. Kildeport- er ment å indikere porten til inngangspunktet, som alltid er plassert på det lokale grensesnittet (127.0.0.1). Mål- kringkasting, dvs. hvor pakker vil bli sendt fra utgangspunktet. Radiobrytere Lokal - Ekstern - Dynamisk angi tunneltype og ligner på nøkler -L,-R Og -D.

Etter at du har fylt ut alle de obligatoriske feltene, kan du legge til en tunnel ved å bruke knappen Legg til. For å gi eksterne verter tilgang til den lokale inngangspunktkontakten, merk av i boksen Lokale porter aksepterer tilkoblinger fra andre verter. I dette tilfellet bør du også begrense tilgangen til åpne porter midler Windows brannmur eller en tredjeparts overspenningsvern.

Serveren vi kobler til er spesifisert i en annen seksjon - Økt, som er kjent for alle som noen gang har brukt PuTTY, hvor du kan lagre øktparametere for fremtidig bruk.

Som du kan se, gir SSH administratoren fleksibel og kraftig verktøy for trygt fjerntilgang uten behov for å åpne porter eller organisere VPN-kanaler. Vi håper at dette materialet vil være nyttig for deg og vil tillate deg å mestre nye evner til tilsynelatende kjente verktøy.

  • Tagger:

Vennligst aktiver JavaScript for å se

SSH-tunneling kan hjelpe ikke bare i saker der det er nødvendig å overføre ukryptert trafikk over en kryptert forbindelse, men også når du ikke har tilgang til en ressurs på nettverket, men tilgang er nødvendig.

La oss se på å lage og sette opp flere alternativer.

Og så, vi har en server, la oss kalle den vert-1. Til ham har vi full tilgang bare ved SSH- men vi må åpne Tomcat, som opererer på port 8082 - som de ikke kan slippe oss gjennom.

Vi vil vurdere alternativet med innstilling Windows Og Kitt.

Åpning SSH- tilkobling til til den nødvendige serveren, la oss logge inn.

Vi spesifiserer følgende parametere:

Kildeport: enhver ubrukt port på systemet ditt;
Destinasjonsport: 127.0.0.1:8082

Klikk Legg til, Deretter Søke om.

Gå til nettleserinnstillingene og still inn proxy-parametrene:

Nå gjenstår det bare å åpne siden http://localhost:3002 i nettleseren - så kommer vi til siden Tomcat på server vert-1.

Hvis tunnelen ikke fungerer, sjekk på serveren om pakkevideresending er aktivert. I filen /etc/ssh/sshd_config, finn og fjern linjen:

AllowTcpForwarding ja

Og starter SSHd på nytt:

# service sshd omstart Stopper sshd: [ OK ] Starter sshd: [ OK ]

Et annet eksempel - vi har den samme eksterne serveren som vi har normal tilgang til alle ressurser på Internett fra. Men fra arbeidsplassen har vi tilgang til og er stengt.

Vi gjennomfører lignende handlinger, men med mindre forskjeller. Innstillinger i Kitt:

Kildeport - la det være det samme, men i stedet Lokalt- velge Dynamisk. Klikk Legg til, Søke om.

La oss gå til nettleserinnstillingene:

Vær oppmerksom på at proxy-typen her ikke er HTTP, men SOCKS.

Nyt tilgang til favorittsidene dine.

Og en mer interessant sak.

Vi har det samme vert-1. I tillegg til den er det en andre server, la oss kalle den vert-2. I tillegg har vi en maskin med Windows, som må gis tilgang til ressursen TeamCity på server vert-1 på port 8111. I dette tilfellet, tilgang fra Windows-vi har kun maskiner til serveren vert-2, og bare til port 22.

Til å begynne med hever vi tunnelen mellom vert-1 Og vert-2. Vi gjennomfører vert-1:

$ ssh -f -N -R host-2:8082:localhost:8111 brukernavn@host-2

Så vi åpner en tunnel, som lokalt (på vert-1) ser på port 8111, og på den andre siden er maskinen vert-2, hvor port 8082 åpnes og venter på innkommende tilkoblinger. Når du mottar pakker på port 8082 (og kun via lo0-grensesnittet! dette er viktig) - vil det omdirigere dem til maskinen vert-1 port 8111.

Angående lo0-grensesnittet. Når den er installert SSH-tunnel, selv når den eksterne IP-en til maskinen spesifiseres - tilkoblingen heves kun fra localhost, dvs. 127.0.0.1.

La oss se på vert-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* LYTT -

For å endre dette, må du redigere sshd daemon-konfigurasjonsfilen - /etc/ssh/sshd_config og endre parameteren:

#GatewayPorts nr

Men det gjør vi ikke nå, dette er bare et notat.

La oss fortsette. La oss gå videre til oppsettet Kitt På vår Windows-bil. Alt er enkelt her - vi bruker eksempel 1 fra denne artikkelen, bare endre porten til ønsket (i skjermbildet er den forresten der). La oss koble til Kitt til verten vert-2, sette opp tunnel. Endre innstillinger i nettleseren proxy– og vi får det vi trenger, spesifiser adressen http://localhost:3002:

SSH er ganske følsom for pakketap, så tunneler kan slippes ofte.

For å unngå dette kan du enten leke med parameterne i sshd-innstillingsfilen - /etc/ssh/sshd_config:

#TCPKeepAlive ja #ServerAliveInterval #ServerAliveCountMax

Eller bruk autossh-verktøyet.

Artikkelen gir detaljert analyse teori og praksis for å bygge SSH-tunneler basert på PuTTY. Det er mye informasjon om denne saken på Internett, men den er ikke systematisk og representerer ofte bare et spredt sett med praktiske oppskrifter.

Terminologi

For å forenkle forståelsen av stoffet bruker artikkelen terminologi, som jeg forholder meg strengt til og som har en klar mening.

Klient— datamaskin-kilde for forespørsler. For eksempel en nettleser eller ssh-klient.
Server— forespørselsbehandlingsdatamaskin. For eksempel et skrivebord på et lokalt nettverk.
Grunnordning— et interaksjonsskjema der kun klienten og serveren deltar.
Utvidet ordning- Utvidelse grunnleggende krets, når klienten og serveren formidles av en proxy.
Fullmakt— en mellomliggende datamaskin mellom klienten og serveren i et utvidet opplegg.
Rett tunnel— en tunnel der retningen for å starte en SSH-økt og forespørsler sammenfaller.
Returtunnel— retningen for å starte en SSH-økt og klientforespørsler er motsatt.
Kildeport(kildeport) - porten i den ene enden av tunnelen der forespørselen fra klienten kommer.
Kan være for PuTTY lokal "Local" (i samme ende av tunnelen som PuTTY) og ekstern "Remote" (i motsatt ende).
Mål(destinasjonsadresse) - IP-adresse og port på datamaskinen som pakker som forlater tunnelen er beregnet på. I det utvidede opplegget er dette alltid selve serveren.

SSH-tunneler er laget for å løse 2 uavhengige problemer:

  1. Sikre konfidensialiteten til data som overføres over en sikker kanal
  2. Opprette en forbindelsesbro (eller flere broer) mellom klienten og serveren gjennom mellomliggende datamaskiner, siden klienten kanskje ikke har direkte adgang til serveren. I dette tilfellet er konfidensialitet sekundær eller ikke nødvendig i det hele tatt.

SSH-tunneler kan organiseres både i modusen for å omdirigere individuelle TCP-porter (Port forwarding), og i modusen for ekte VPN-tunneler gjennom virtuelle grensesnitt, når trafikk av alle protokoller og fra alle porter kan overføres. I denne artikkelen skal vi se på den første modusen.

Når du opererer i portvideresendingsmodus, må en pakke som ankommer en tunnels inngangsport overføres uendret til utgangsporten. Denne ordningen brukes i driften av Internett-gatewayer: pakker fra ett grensesnitt overføres til et annet uten endring eller analyse.

Dermed ligner en SSH-kanal i denne modusen med hele infrastrukturen en virtuell gateway med inngangs- og utgangsgrensesnitt, men bare for et spesifikt par TCP-porter:

Pilen indikerer retningen som SSH-økten startes i. I dette tilfellet er initiativtakeren til tilkoblingen klienten med PuTTY installert på den.

Opplegget ovenfor er en grunnleggende, der kun 2 deltakere samhandler: klient og server. I praksis kan det være flere mellomverter mellom klienten og serveren. Både før de når inngangen til en bestemt tunnel og etter å ha forlatt den, kan pakker sendes over ubeskyttede kanaler.

For å etablere kommunikasjon via SSH-protokollen trenger du Regnskap på en SSH-server, som kan være hva som helst, inkludert uten noen rettigheter og til og med uten et skall, hvis du åpner uprivilegerte porter fra 1024 og høyere for å lytte. Ellers kreves root-tilgang og direktivverdi PermitRootLogin lik ja eller uten passord.

Analyse av tilkobling og tilgjengelighet for interaksjonsdeltakere

Når du begynner å løse problemet med hvordan du gir tilgang fra klienten til serveren, er det nyttig å bygge et diagram over tilkoblingen til deltakere i interaksjon ved hjelp av SSH-protokollen, siden det er gjennom denne protokollen at tunneler opprettes, gjennom hvilke data fra en hvilken som helst annen protokoll kan deretter sendes.

For å gjøre dette må vi svare på spørsmålet om hvor SSH-serverne er plassert og om de er tilgjengelige ved å bruke SSH-klienter fra andre verter.

La oss se på disse trinnene basert på et utvidet opplegg som består av en klient, en mellomliggende proxy-server og en server. I praksis er slike ordninger mest vanlig.

Hvis du kobler til maskiner som er tilgjengelige via SSH-protokollen med piler, er følgende alternativer mulige:

Spesielt kobler vi klienten til proxyen med en pil hvis proxyen er tilgjengelig fra klienten på port 22. Etter å ha sortert gjennom alle interaksjonsdeltakerne i par, får vi et koblingsdiagram. For eksempel:

Tilkoblingsdiagrampilene viser hvor en tunnel til SSH-servermaskinen kan startes.

Etter å ha bygget tilkoblingsdiagrammet, må du sørge for at deltakerne i interaksjonen er tilgjengelige for hverandre via vilkårlige protokoller og porter, siden du på en eller annen måte må koble til den opprettede tunnelen, eller omvendt, videresende dataene videre. Du må med andre ord sjekke om de pinger eller ikke. I analogi med tilkoblingsordningen kan du bygge en tilgjengelighetsordning som i det minste faller sammen med tilkoblingsordningen, men som oftest er bredere enn den:

Tilgjengelighetsdiagrammet viser i hvilken retning data kan overføres over en kanal som ikke er beskyttet av en tunnel.

Kombinasjonen av begge ordningene bidrar til å svare på spørsmålet om det er grunnleggende mulig å etablere en forbindelse mellom klienten og serveren, og hvis den ikke er det, hva som må legges til for å få den.

I fremtiden vil vi bruke disse diagrammene til å bygge en kommunikasjonskanal.

Oppsettet ovenfor er veldig vanlig: klient og server (oftest på Windows basert) er plassert i forskjellige lokale nettverk bak NAT, har tilgang til Internett og "se" den eksterne proxy-serveren, mens de med en proxy er utilgjengelige enten via SSH eller andre protokoller. Proxyen har vanligvis en *nix-lignende operativsystem, som har en SSH-server som standard.

I ordninger basert på *nix-systemer er nesten alle koblinger fullstendig tilkoblet, siden alle maskiner har SSH-servere, og SSH-porter er vanligvis åpne for tilkoblinger.

Algoritme for å bygge en kommunikasjonskanal ved hjelp av SSH-tunneler

La oss analysere algoritmen for å bygge en kommunikasjonskanal ved hjelp av en SSH-tunnel ved å bruke eksempelet på diagrammet gitt ovenfor, der klienten og serveren er plassert på forskjellige lokale nettverk bak NAT-er, og bare kan kobles til via Internett ved hjelp av en proxy-server.

1) Tegning av et SSH-koblingsskjema

Vi har kun en SSH-server på proxyen, så vi kan starte 2 tunneler: fra klienten og fra serveren:

Dette er en krets med to enkelt koblede lenker.

2) Tegne et tilgjengelighetsdiagram

Klienten og serveren er bak NAT, så de er utilgjengelige fra utsiden med proxyen, men proxyen pinger fra både klienten og serveren

3) Velge en kobling for å lage en tunnel

For å sikre kommunikasjon mellom klienten og serveren, er én tunnel tilstrekkelig - enten klient-proxy eller proxy-klient, siden pakker i den resterende delen kan overføres over en usikret kanal.

Client-Proxy-tunnelen ser å foretrekke ut, siden vi i dette tilfellet kan utføre alle kommunikasjonsoperasjoner fra klienten, og fra den, i henhold til betingelsene for oppgaven, må vi jobbe med serveren.

Pakker som ankommer tunnelinngangen på klientens datamaskin blir overført til proxyen og må deretter omdirigeres til destinasjonsadressen, som er serveren. Imidlertid, i henhold til tilgjengelighetsordningen, er ikke serveren tilgjengelig fra proxyen via Internett:

Derfor, for å overføre pakker, kan du ikke gjøre uten å opprette en andre tunnel mellom proxyen og serveren:

Men den første tunnelen, som vi satt vårt håp til, vil være overflødig i et slikt opplegg - vi kan sende pakker fra klienten til proxyen direkte gjennom et ubeskyttet miljø uten å bruke en tunnel:

Client-Proxy-tunnelen kan bare forlates hvis den er viktig fra et konfidensialitetssynspunkt (noe overføres gjennom den i klartekst og så videre.).

4) Velge Proxy Server tunneltype: fremover eller bakover

Faktisk er typen tunnel allerede forhåndsbestemt. Klientforespørsler kommer til kildeporten, som er plassert på proxyen, og tunnelen startes fra serveren. Dette betyr at retningen for tunnelinitiering og klientforespørsler vil være motsatt. Derfor vil tunnelen bli reversert (alternativ -R).

5) Spesifisere tilkoblingsparametere og lage en tunnel

Følgende algoritme for å konstruere en kommunikasjonskanal dukker opp:

  1. Lag et SSH-tilkoblingsdiagram basert på plasseringen av SSH-servere
  2. Lag et tilgjengelighetsdiagram.
  3. Velg en lenke: Client-Proxy eller Proxy-Server (for et utvidet skjema)
  4. Velg tunnelinitieringsretningen hvis koblingen er fullstendig tilkoblet.
  5. Velg type tunnel basert på retningen til kundens forespørsler: direkte eller omvendt
  6. Skriv portvideresendingsformler i PuTTY (Kildeport, Destinasjon og flere alternativer) for hver tunnel

Forstå prinsippene beskrevet ovenfor, er det enkelt å sette riktige innstillinger både på SSH-Tunnels-fanen i PuTTY og på kommandolinjen til OpenSSH-klienten. Spesielt er følgende aksiomer sanne:

Kildeport— dette er tunnelporten som klientforespørsler mottas til.
Hvis retningen for tunnelinitiering og kundens forespørsler er den samme (direkte tunnel), er porten i samme ende som PuTTY og er lokal for PuTTY (alternativ -L, Local).
Ellers er kildeporten på motsatt side av returtunnelen og er ekstern for PuTTY (alternativ -R, Remote)
I 99 % av tilfellene åpnes kildeporten for lytting på loopback-grensesnittet til maskinen som forespørsler fra klienten mottas til, og blir derfor vanligvis utelatt. I PuTTY er det ikke engang et eget sted for IP-adressen til forespørselskilden - bare kildeporten.

Mål- dette er IP-adressen og porten til datamaskinen som data overføres til ved utgangen av tunnelen. Hvis PuTTY er på Destination, vil dette åpenbart være localhost.
I motsetning til en loopback IP-adresse ved inngangen til en tunnel, kan data ved utgangen av en tunnel sendes hvor som helst, inkludert til verter med forskjellige IP-adresser.

Dette er nok til å angi de riktige innstillingene for alle SSH-tunnelalternativer. De mest typiske av dem presenteres nedenfor ved hjelp av spesifikke eksempler.

Jeg vil også gi kommandolinjesyntaksen til OpenSSH-klienten når det gjelder PuTTY, hvis du vil starte en tunnel fra et *nix-system i henhold til det grunnleggende skjemaet:

ssh [-g] [-p port] : bruker@server

og i henhold til den utvidede ordningen:

ssh [-g] [-p port] : bruker@Proxy

Her under refererer til en port med nøkler, for eksempel: -L 5000 (fremover tunnel), -R 5000 (reversert tunnel) eller -D 5000 (dynamisk portvideresending; utelatt i dette tilfellet)
[-p port]— koble til serveren eller proxyen på en annen port enn 22.
[-g]— et alternativ som tillater tilkoblinger til en lokal (lokal) eller dynamisk (dynamisk) port, ikke bare fra localhost, men også fra eksterne adresser.

For å tillate en lignende mulighet til å koble til en ekstern (ekstern) port fra eksterne adresser, må du registrere deg i SSH-serverens konfigurasjonsfil /etc/ssh/sshd_config alternativ:

GatewayPorts-klienter spesifisert

takket være hvilken inkludering av denne funksjonen utføres på forespørsel fra klienten, eller

GatewayPorts ja

når dette alternativet alltid er aktivert.

Grunnordning

Det grunnleggende samhandlingsskjemaet involverer bare 2 datamaskiner koblet sammen med en tunnel.

I henhold til denne ordningen er 2 typer tunneler mulig - forover og bakover, avhengig av hvilken side SSH-økten startes fra. I følge dette er PuTTY alltid i enden av tunnelen der pilen begynner.

Utvidet ordning

En utvidelse av grunnskjemaet er et opplegg med en mellomliggende proxy-server som enten Klienten kobler seg til eller som det etableres en forbindelse med Serveren fra. Det er 4 alternativer her.

I prinsippet er alle fire alternativene for den utvidede ordningen like, hvis vi abstraherer fra den spesifikke implementeringen av SSH-klienten. Men siden vi vurderer å jobbe gjennom PuTTY i denne artikkelen, kan vi initiere tunneler kun fra Windows-baserte maskiner, dvs. oftest enten fra klienten eller fra serveren.

Situasjoner der en SSH-økt med PuTTY startes fra en mellomserver er ganske sjeldne, siden proxy-servere vanligvis er maskiner uten grafisk skall kjører *nix-lignende OS, og i stedet for PuTTY vil det være OpenSSH.

For å fullføre bildet, nedenfor er syntaksen til OpenSSH-klienten når det gjelder PuTTY, hvis du plutselig trenger å starte en tunnel ved hjelp av OpenSSH.

Praktiske eksempler på bruk av SSH-tunneler

1. Direkte tunnel etter grunnordningen

La oss se på å beskytte en åpen protokoll fra avskjæring ved å bruke POP3 som et eksempel.

I stedet for å motta e-post på den lokale datamaskinen direkte via Internett og utsette oss for risikoen for å miste passordet overført i klartekst, mottar vi det gjennom en tunnel med e-postserveren på port 110. E-postklienten må i dette tilfellet konfigureres for å motta brev fra den lokale vertsadressen:5000

Diagrammet er gitt for illustrative formål, siden alle e-postklienter Nå kan de jobbe med sikre protokoller, og valget av porter er strengt begrenset.

Klient# ssh -L 5000:Server:110 bruker@Server

Tilkoblings- og tilgjengelighetsskjema for et system med en server bak NAT:

Dette er tilfellet når du trenger å logge på fra en datamaskin (klient) til en annen (server) over et lokalt nettverk, men direkte kontakt ikke levert med det. Det er imidlertid tilgang til klienten fra serveren. For å gjøre dette startes en SSH-sesjon fra serveren, det vil si fra datamaskinen vi ønsker å koble til. Som et resultat opprettes det en returtunnel.

For å heve en omvendt tunnel til klienten, må du installere en SSH-server og spesifisere fra hvilken ekstern port (Remote Source-port) til hvilken lokal port for PuTTY videresendingen skal utføres.

Den tilsvarende kommandoen for OpenSSH-klienten er:

Server# ssh -R 5000:localhost:3389 bruker@klient

Tilkoblings- og tilgjengelighetsskjema for et system med en klient bak NAT:

Denne ordningen lar deg koble til Internett trygt gjennom ubekreftede kilder, for eksempel Wi-Fi-tilgangspunkter på kafeer og restauranter. All trafikk går gjennom tilgangspunktet i kryptert form fra den eksterne serveren.

Som du vet, sender nettleseren forespørsler til nettsteder på Internett fra vilkårlige porter på datamaskinens WAN-grensesnitt. I PuTTY er denne modusen gitt i form av alternativet Dynamic. Alle nettleserforespørsler gjennom tunnelen rutes fra en eller annen kildeport 5000 på maskinen som kjører SSH-klienten, og tilordnes dynamisk i den andre enden. Derfor er den endelige porten ikke spesifisert.

Siden nettlesere ikke kan fungere direkte gjennom SSH-tunneler, må du i tilkoblingsinnstillingene via en proxy-server velge en tilkobling via SOCKS (v5) til adressen localhost:5000 og fjerne localhost eller 127.0.0.1 fra "Ikke bruk proxy for: ”-feltet hvis det registreres der automatisk.

Den tilsvarende kommandoen for OpenSSH-klienten er:

Klient# ssh -D 5000 bruker@server

Ved å legge til -g-alternativet, som tilsvarer PuTTY "Lokale porter aksepterer tilkoblinger fra andre verter", kan du la andre datamaskiner koble til klienten på den angitte porten og dermed gjøre den om til et tilgangspunkt.

Ordningen ligner den forrige, bare med en omvendt tilkoblingsordning (kunden har forbud mot å få tilgang til Internett).

Dette betyr at vi kun kan starte en tunnel fra serveren. Det er klart at en SSH-server må distribueres på klienten. For Windows-baserte klienter godt valg Det vil være en Bitvise SSH-server på port 443. FreeSSHd-server med omvendte tunneler fungerte ikke for meg.

Så, for at ordningen skal fungere, må du lage en proxy fra Socks Server på port 5000, og lage en tunnel med seg selv:

Server# ssh -D 5000 bruker@server

Og deretter oppretter du en omvendt tunnel med klienten, der forespørsler på port XXXX blir omdirigert til port 5000 på Socks-proxyen vår:

Server# ssh -R XXXX:localhost:5000 bruker@klient

Det særegne ved denne ordningen er at reverserte tunneler langs kjeden kan videresendes videre til andre datamaskiner som ikke har tilgang til Internett.

Denne ideen er grunnlaget for en lignende krets fra denne artikkelen, men i den blir tunnelen initiert i motsatt retning av et uttrykk som dette:

Proxy# ssh -D 5000 -R XXXX:localhost:5000 bruker@server

Og først da kobler en datamaskin som ikke har tilgang til Internett til serveren ved hjelp av en omvendt tunnel:

Server# ssh -R YYYY:localhost:XXXX bruker@datamaskin

I dette tilfellet blir imidlertid Internett-forespørselen til serverport XXXX omdirigert via den omvendte tunnelen til datamaskinen som spiller rollen som proxy-serveren, og returnerer deretter til serveren for å bli servert på den:

Denne metoden bruker åpenbart en ekstra sløyfe som består av tunneler 2 og 3, som vi ekskluderte ovenfor ved å organisere distribusjonen av Internett direkte fra selve serveren.

5. Direkte tunnel til en mellomliggende SSH-server

I dette tilfellet opprettes en tunnel med en mellomliggende proxy-server, og fra den opprettes en tilkobling til den endelige eksterne serveren.

Denne ordningen hjelper når lokal datamaskin det er ingen direkte tilgang til Internett, men det er tilgang til en server innenfor det lokale nettverket som er koblet til Internett. Et eksempel på et tilkoblings- og tilgjengelighetsdiagram for tilfellet når klienten og proxyen står bak NAT, og serveren er tilgjengelig fra Internett:



I et annet tilfelle er serveren plassert på et eksternt lokalt nettverk og er ikke direkte tilgjengelig fra Internett, men du kan koble til den via en mellomfullmektig på det samme lokale nettverket. Mulig opplegg tilkobling og tilgjengelighet for tilfellet når proxyen er en gateway og klienten befinner seg bak NAT i sitt eget LAN:



I begge tilfeller må klienten koble seg til localhost:5000.

Den tilsvarende kommandoen for OpenSSH-klienten er:

Klient# ssh -L 5000:Server:3389 bruker@Proxy

Denne ordningen har allerede blitt diskutert i detalj helt i begynnelsen:

I dette tilfellet må vi gå med hjemmedatamaskin til en ekstern, som ikke er tilgjengelig fra Internett, men det er en mellomfullmektig, tilgjengelig for både klienten og serveren. Vi fant ut at kommunikasjon kun kan etableres ved å bruke en omvendt tunnel fra serveren til proxyen.

For tillatelse ekstern tilkobling Oppdragsgiver må også krysse av for alternativet . Dette alternativet fungerer bare hvis tilkoblingstillatelsen er satt til ekstern port på klientforespørsel er tillatt i proxy-serverens ssh daemon-konfigurasjonsfil /etc/ssh/sshd_conf:

GatewayPorts-klienter spesifisert

Etter dette skal serveren bli tilgjengelig fra klienten via RDP til proxy-adressen:5000

Den tilsvarende kommandoen for OpenSSH-klienten er:

Server# ssh -R 5000:localhost:3389 bruker@Proxy