Научете се да използвате SSH тунелиране за сигурно сърфиране. Протоколи за тунелиране - какви са те? Картографиране на достъпността

28 март 2012 г. От Джейсън Бротън
в HOW-TOs SysAdmin

„Ако видите светлина в края на тунел, това е светлина на приближаващ влак“, Робърт Лоуел. Още един добър цитат. Тази статия е за изграждането на тунели с използвайки SSH, или както аз наричам тази тема „VPN тунели за бедните“. Въпреки основните вярвания на системните администратори, SSH тунелите всъщност могат да бъдат доста полезно нещокакто за техници, така и за домашна употреба. Казвам „въпреки вярванията на системните администратори“, защото обратните тунели или уеб трафикът, обвит в SSH, може да премине през защитни стени и филтри за съдържание. Статията обаче не е за това как можете да подкопаете корпоративните политики за сигурност, а за това как SSH тунелирането може да направи живота ни малко по-малко сложен.

Защо SSH тунели вместо VPN? Добре, използвам това и това вкъщи. Ако ме следвате на jaysonbroughton.com, знаете, че разработвам OpenVPN трифакторно удостоверяване (потребителско име, сертификат и еднократна парола). Но ако искам да проверя един от сървърите под мой контрол чрез Android или да разгледам компютър, на който нямам администраторски права (и преносимият OpenVPN клиент се нуждае от тях), или дори искам да поправя някои грешки, използвайки vnc достъп през SSH тунел, тогава SSH е моят избор за начин за осигуряване на трафик.

Ще обсъдим основите: как да изградите тунел, какво означава синтаксисът на всяка команда, примери за обратни тунели и ситуации, в които трябва да използвате един или друг подход. Прегледах накратко и структурата на конфигурационния файл.

Така че о Системни изисквания. Използвам Debian в виртуална среда, така че вашите резултати може да се различават от моите. Затова предоставям информация за инструментите: използва се сървър OpenSSH_5.3p1 и клиенти OpenSSH 5.X от различни версии. Преди да се потопя в дълбините на ssh тунелирането, трябва да кажа: преди да пробиете дупка в сигурността на компанията, използвайки обратен тунел или обгръщайки http трафик, уверете се, че не нарушавате набор от вътрешни разпоредби, като например Правилата за приемлива употреба в Интернет. Ясно е, че в този случай системните администратори веднага ще ви издирят и изпържат, особено ако използвате тунел, за да стигнете до сървъра на работа от вкъщи. Самият аз като системен администратор получавам голямо удоволствие от откриването на такива знаци. Повярвайте ми, с малко проверка се оказва, че системни администраториизобщо не са идиоти.

Е, отказът от отговорност е обявен, можете да започнете.

Изграждането на SSH тунели е доста просто нещо. Разбирането на случващото се и подходите за учене може да бъде малко по-трудно. Така че ще дам няколко типични случаида настроим съзнанието, преди да преминем към детайлите на командите. Преди да имам деца, пътувах доста. В моите пътувания се озовах в много странни хотели, чиито стаи бяха много странни Wi-Fi точкидостъп. Наистина ли искате да се свържете с хотелска точка за достъп, чийто SSID е въведен на непреводим gobbledygook? Или на летището, където няколко отворени мрежи? Когато съм някъде във външния свят, предпочитам да тунелирам уеб трафик към моя руутнат андроид чрез домашен сървър. Когато държа лаптопа си в ръцете си, отварям ssh тунел и пренасочвам уеб трафика през socks5, така че целият трафик, който идва към мен, е криптиран. Вярвам на отворени WAP само дотолкова, доколкото мога да навигирам през тях. За какво друго обикновен текст? Тунелирам SMTP трафик на компютъра си през домашния си сървър, когато на някои места виждам, че изходящият SMTP е блокиран. Подобна е ситуацията и с POP3. Друг пример: можете да управлявате X приложения през тунел. Можете да обвиете VNC сесии в тунел. Една от техниките, които започнах да използвам по-рано от другите, бяха обратните тунели. В този случай създавате тунел от сървър, който се намира отзад защитна стена. Когато влезете в този SSH сървър, можете да възстановите връзката.

Примери

Преди да разгледате клиентската страна, трябва да направите някои неща от страна на сървъра, като използвате редактиране конфигурационен файл sshd.config, където препоръчвам да направите следните промени. Преди да направите промени, копирайте оригиналната конфигурация за безопасност, в случай че нещо се обърка.

Ако сте направили промени, трябва да рестартирате sshd сървъра, за да ги приложите.

Нека да преминем към превключвателите на командния ред.

Типичен ssh тунел (без тунелиране на X протокол) изглежда по следния начин:

Както можете да предположите, опцията -X тунелира X. Не забравяйте обаче, че командата ще тунелира вашето приложение от вашата отдалечена машина към вашата. клиентска машинас Linux. Ако сте на Windows, просто инсталирайте Cygwin/X (http://x.cygwin.com/) на вашия кола за гости. Не съм пробвал това лично, но доколкото разбирам, трябва да помогне за стартирането отдалечено X приложениев Windows.

Когато установявате VNC сесии, трябва да сте внимателни. Ако отдалечен VNC сървър работи на порт 5900, уверете се, че не се свързвате към него след това. Самата сесия се тунелира, както в други случаи, като се използва прозрачна команда:

И сега го имате, обратим тунел.

За по-голяма яснота, daddoo и nerdboy4200 от #linuxjournal обединиха усилията си и създадоха Mscgen, програма, която анализира поредица от съобщения и изгражда визуална диаграма на обмен на съобщения за различни протоколи. Той, разбира се, е с отворен код и е доста ужасен за гледане (http://www.mcternan.me.uk/mscgen/). За случая на реверсивен тунел, с помощта на техния продукт, те изградиха диаграма (тогава авторът вмъкна диаграма в текста си, на която нищо не се вижда - прибл. прев.).

Заключение

И така, това, което можете да правите с тунелиране, е ограничено само от вашето въображение, тук сме дали само няколко примера. Може би в следващите публикации ще ви кажа как правилно да конфигурирате SSH от страна на клиента.

Публикувано от: администратор на 17 октомври 2017 г

Как работи SSH тунелирането

SSH тунел или SSH Port Forwarding, както man(1) го нарича ssh, е незадължителна функционалност на протокола, която работи върху познатата обикновена SSH сесия. SSH тунел ви позволява да изпратите TCP пакет от едната страна на SSH връзка към другата страна и да излъчите IP хедъра според предварително определено правило по време на процеса на предаване.

Много е лесно да разберете как работи един SSH тунел: ако си го представите като връзка от точка до точка. Точно както при PPP, всеки пакет, който удари единия край на връзката, ще бъде изпратен и получен в другия край на тунела. Освен това, в зависимост от адреса на получателя, посочен в IP хедъра, пакетът или ще бъде обработен от приемащата страна на тунела (ако пакетът е предназначен директно за нея), или насочен по-нататък в мрежата (ако получателят е друга мрежа възел).

Основната разлика между SSH тунел и PPP връзка е, че само TCP трафик може да бъде обвит в SSH тунел. (Забележка: Има няколко хака за предаване на UDP през TCP сокет в SSH тунел, но това решение е извън обхвата на тази статия.)

Втората разлика е, че при връзка от точка до точка входящ трафикможе да се инициира от всяка страна, докато за SSH тунел е необходимо изрично да се зададе „входна точка“ за трафика. „Входна точка“ е параметър на формата<адрес>:<порт>, указвайки кой сокет да се отвори, за да влезете в тунела (от локалната или отдалечената страна на SSH сесията).

В допълнение към входната точка трябва допълнително да посочите правило на формуляра<адрес>:<порт>, според който хедърът (по-точно адресът и дестинационният порт) на TCP пакета трябва да бъдат пренаписани по време на предаване. Входната точка може да бъде зададена от двата края на тунела. Бутоните –L (локален) и –R (дистанционен) отговарят за този параметър. Под локално и отдалечено имаме предвид страните на тунела от гледна точка на първоначалната страна, тоест хостът, който установява SSH сесията.

Засега изглежда малко объркващо, така че нека го разгледаме с конкретен пример.

Директен SSH тунел - осигуряване на достъп до сървъра зад NAT

Алекс работи като системен администратор за малка компания за ябълков пай, наречена Qwerty Cakes. Цялата мрежа на компанията е разположена в един широко разпространен домейн 192.168.0.0/24. Използва се за достъп до интернет софтуерен рутербазиран на Linux, чийто адрес е 192.168.0.1 от страната на фирмената мрежа и 1.1.1.1 от страната на Интернет. OpenSSD демонът работи и работи на рутера, който е достъпен чрез сокет 1.1.1.1:22. Вътре в мрежата, вътрешен корпоративен портал, по който Алекс трябва да направи промени до утре сутринта Уеб интерфейс. Алекс обаче не иска да остава до късно на работа, той иска да има достъп до портала от дома си домашен компютърс адрес 2.2.2.2.

Алекс се прибира и след вечеря установява следната връзка с фирмения рутер:

Какво стана? Алекс установи SSH сесия между адреси 2.2.2.2 и 1.1.1.1, докато отваря локална „входна точка“ към тунела 127.0.0.1:8080 на домашния си компютър:

alex@Alex-PC:~$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (СЛУШАЙТЕ)

Всеки TCP пакет, който влезе в сокет 127.0.0.1:8080 от компютъра на Алекс, ще бъде изпратен през връзка от точка до точка вътре SSH сесии, в този случай целевият адрес в TCP хедъра ще бъде пренаписан от 127.0.0.1 на 192.168.0.2, а портът от 8080 на 80.

Сега, за да стигне до портала на своята компания, Алекс трябва само да напише в браузъра:

Как вървят мрежови пакетивътре в SSH тунел

Нека да разгледаме по-отблизо какво се случи с TCP пакета, докато преминаваше през SSH тунела:

1. TCP пакет с адрес на източник 127.0.0.1 и адрес на местоназначение и порт 127.0.0.1:8080 влезе в сокет 127.0.0.1:8080, отворен чрез процес ssh;

2. Процесът на ssh получи пакета в съответствие с правилото за транслация, пренаписа адреса и порта на местоназначението на 192.168.0.2:80 и го изпрати в рамките на SSH сесията до отдалечената страна 1.1.1.1;

3. Процесът sshd на рутер 1.1.1.1 получи пакета и след като погледна адреса на местоназначението, го изпрати до хост 192.168.0.2, докато пренаписа адреса на източника от 127.0.0.1 на адреса на собствения си интерфейс 192.168.0.1, така че получателят, който не знае нищо за съществуването на SSH тунел, е върнал пакета на рутера, а не го е изпратил до собствения си локален хост 127.0.0.1.

alex@Alex-PC:~$ ssh -L

127.0.0.1:8080:192.0.0.2:80 [имейл защитен]

IN в този пример, ако порталът или всеки друг ресурс, до който Алекс трябва да има достъп, се намира на самия рутер (например на 192.168.0.1:80), тогава командата ще изглежда така:

Ако услугата е налична на localhost (например локален SQL сървър), можете да получите достъп до нея:

alex@Alex-PC:~$ ssh -L

127.0.0.1:13306:127.0.0.1:3306 [имейл защитен]

Конструкции като -L 127.0.0.1:80:127.0.0.1:80 може да изглеждат доста странни на пръв поглед. Но в тях няма нищо сложно, ако помните, че решението за маршрутизиране на пакети се взема от отдалечената страна на тунела. Трябва да запомните основното правило: втора двойка<адрес>:<порт>обработени от отдалечената страна на тунела.

Следователно пакет с адрес на местоназначение 127.0.0.1 в правилото за превод ще бъде обработен от втората страна на SSH сесията и нищо друго.

Както вероятно вече се досещате, входната точка на тунела може да бъде създадена не само на интерфейса за обратна връзка. Ако тунелът трябва да бъде направен достъпен не само за локалния хост, но и за други участници в мрежата, тогава можете да посочите реален адресинтерфейс.

alex@Alex-PC:~$ ssh -L

10.0.0.5:8080:192.0.0.2:80 [имейл защитен]

Компютърът на Алекс Alex-PC има два мрежов интерфейсс адреси 2.2.2.2 и 10.0.0.5. По време на процеса на установяване на сесия, ssh ще отвори сокет 10.0.0.5:8080 на компютъра Alex-PC. Алекс вече има достъп до портал 192.168.0.2:80 от лаптопа си с адрес 10.0.0.4 и всички негови домашна мрежа 10.0.0.0/24.

Обратен SSH тунел - изложете вашите ресурси на интернет

Както вече казах, входната точка на тунела може да бъде отворена не само от страната на инициатора на ssh сесията, но и от отдалечената страна, тоест от тази, към която установяваме ssh сесия. За да направите това, използвайте опцията -R вместо опцията -L. За какво е?

Например, за да можете да публикувате локална услуга за отдалечен достъп.

Мрежата работи на лаптопа на Алекс apache сървърдостъпен на 127.0.0.1 с тестово копие на фирмения портал. Алекс трябва да получи достъп уеб сървърна вашите колеги, за да тестват интерфейса. Като цяло за такива цели би било хубаво Алекс да внедри по-надежден тестов пясъчник. Но тъй като нашият Алекс не е нищо повече от виртуален герой в тази статия, за да демонстрира работата на SSH тунела, той установява сесия между своя лаптоп и Linux рутера. И използвайки параметъра -R, отваря порт 8080 на вътрешния интерфейс на рутера с адрес 192.168.0.1, който препраща към сокет 127.0.0.1:80 на неговия тестов уеб сървър.

Както можете да видите, на рутера sshd процесът отвори локален сокет 8080

alex@Router:~$

sudo lsof -nPi | grep 8080

sshd

17233 Алекс 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (СЛУШАЙТЕ)

Нека да видим какво се случва с TCP пакет, изпратен от компютър 192.168.0.200 към тестов портал, публикуван на 192.168.0.1:8080:

1. TCP пакет с адрес на източник 192.168.0.200 и адрес на местоназначение и порт 192.168.0.1:8080 ще завърши на сокет 192.168.0.1:8080, отворен от процеса sshd;

2. Процесът на sshd, след като получи пакета, в съответствие с правилото за транслация, ще пренапише адреса и порта на местоназначението от 192.168.0.1:8080 на 127.0.0.1:80 и ще го изпрати в рамките на SSH сесията до първоначалната страна. 2.2. 2.2;

3. Ssh процесът на лаптопа на Алекс, след като е получил пакета и е видял адреса на местоназначението му, ще пренапише адреса на изпращача от 192.168.0.200 на неговия обратен адрес и ще го изпрати до локалния сокет 127.0.0.1:80, отворен от apache процес.

един важна забележка, което оставих за края на статията.

Ако при отваряне на входна точка на тунел се използва localhost вместо адреса на реалния интерфейс, тогава той може да бъде пропуснат, като по този начин командата се съкращава с

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [имейл защитен]

преди

alex@Alex-PC:~ssh -L

8080:192.0.0.1:80 [имейл защитен]

Това важна характеристикасинтаксис ще ни бъде полезен в следния пример.

Двойно тунелиране

Нека да разгледаме малко повече сложен пример. Потребител на SQL-Tester, намиращ се зад NAT, трябва да има достъп до базата данни на SQL сървър, който също стои зад NAT. SQL-Tester не може да установи връзка директно със сървъра, тъй като няма съответни преводи в мрежата на NAT сървъра. Въпреки това и от двата хоста можете да установите SSH сесия с междинния сървър 3.3.3.3.

Инсталирайте от SQL сървър SSH връзкасъс сървър 3.3.3.3 и отворен порт 13306 на интерфейса за обратна връзка на сървър 3.3.3.3, който се отнася до локалната SQL услуга, работеща на локалния сокет 127.0.0.1:3306 на SQL сървъра:

dbuser@SQL-сървър:~$ ssh -R 13306:127.0.0.1:3306

[имейл защитен]

Сега, от клиентския хост на SQL-Tester, ние установяваме връзка с 3.3.3.3 и отваряме порт 3306 на клиентския loopback интерфейс, който от своя страна препраща към 127.0.0.1:13306 на сървър 3.3.3.3, който... препраща към 127.0.0.1:3306 на SQL сървъра. Просто е.

тестер@SQL-тестер:~$ ssh -L

3306:127.0.0.1:13306 [имейл защитен]

Динамичен тунел - SSH като Socks прокси

За разлика от тунелите с изрично указание на правилата за превод, динамичният тунел работи на напълно различен принцип. Вместо да зададете адрес едно към едно:портово съпоставяне за всеки целеви адрес и порт, вие отваряте сокет от локалната страна на SSH сесията, което превръща вашия хост в SOCKS4/SOCKS5 прокси сървър. Нека да разгледаме

Пример:

Създайте динамичен тунелен сокет 127.0.0.1:5555 на клиентския хост в SSH сесия към сървър 2.2.2.2

потребител@клиент:~$ ssh -D 5555 [имейл защитен]

Проверка дали портът е отворен

потребител@клиент:~$ sudo lsof -nPi | grep 5555

7284 потребител 7u

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (СЛУШАЙТЕ)

И регистрираме проксито в настройките на браузъра или всеки друг софтуер, който поддържа SOCKS прокси.

Сега целият трафик на браузъра ще минава през прокси SOCKS в криптирана SSH връзка между хостове 1.1.1.1 и 2.2.2.2.

Как да използвам SSH на Microsoft Windows?

След като прочетете статията, може да решите, че всички предимства на SSH тунелите са достъпни само за потребители на Unix-подобни системи. Обаче не е така. Почти всички терминални клиенти за Windows, работещи по SSH протокола, имат поддръжка за тунелиране.

От известно време Windows е възможно да се използва не само като SSH клиент. Възможно е да инсталирате SSH сървър на Windows.

Кога да използвате SSH тунели?

Разбира се, за да създадете постоянни тунели на бойни сървъри, трябва да използвате специален софтуер. Но за бързо решениезадачи за пренасочване на портове, отстраняване на проблеми, получаване на бърз отдалечен достъп и решения като цяло конкретна задача„тук и сега“ използването на SSH тунели често е добра помощ.

С тяхна помощ можете да изграждате цели мрежи, тунели в тунелите и да комбинирате видове тунели. Това може да ви позволи бързо да получите достъп до места, до които изглежда невъзможно да стигнете.

В допълнение към основната си функция, SSH протоколът предоставя на администратора много полезни инструменти, в тази статия ще говорим за създаване VPN тунел с помощта на SSH.
SSH тунелиране- най-простият и бърз начинполучите тунел към Linux сървъра, защото Пакетът OpenSSH най-вероятно вече е инсталиран на него и полученият тунел няма да има проблеми с NAT.

Такъв тунел е прост, но не е надежден, защото използва TCP връзка и не съдържа вградени механизми за възстановяване на връзка след прекъсване.
SSH тунел най-добре се използва за тестване(например, ако трябва да предавате UDP пакети към отдалечен сървър, препращането на портове чрез SSH няма да помогне в този случай), а за постоянни тунели използвайте протоколи, специално предназначени за това, като OpenVPN, PPTP, L2TP, IPSec, GRE и др. .d. (Всички примери за команди в статията са правилни за CentOS 6)

Монтаж и конфигурация

Инсталирайте пакета OpenSSH от хранилищата, ако вече не е инсталиран:

yum инсталирайте openssh openssh-сървър openssh-клиенти

За да може сървърът да разреши използването на тунели, трябва да активирате опцията PermitTunnel във файла с настройки на OpenSSH сървъра (обикновено /etc/ssh/sshd_config) и да рестартирате OpenSSH сървъра (рестартиране на услугата sshd).

PermitTunnel да

В края на файла с настройки на сървъра може да има секции с настройки за конкретни хостове, потребители, потребителски групи и т.н.
Подобни секции ще започнат с линиите

домакин...
или
Съвпада...

Опцията PermitTunnel трябва да се добави преди описаните секции.

Използване на SSH тунели

За всички примери ще се използва OpenSSH сървърът, наличен на 192.168.1.100.

Прост SSH тунел

За да създадете най-простия SSH тунел, можете да изпълните командата

sudo ssh -w 7:7 -l корен 192.168.1.100

Опцията е отговорна за създаването на тунел

У<номер_локального_интерфейса>:<номер_удалённого_интерфейса>

Вместо номера на локалния и/или отдалечения интерфейс, можете да използвате стойността „всеки“, тогава ще бъде създаден следващият незает TUN интерфейс.

След преминаване на sudo и SSH удостоверяване на локалните и отдалечените хостове, трябва да се появи деактивиран интерфейс tun7.

За да използвате тунела, трябва да активирате интерфейсите и да ги конфигурирате с IP адреси от същата подмрежа, например по следния начин:

# на локален хост
# на отдалечения хост

Сега локалният хост ще има достъп до отдалечения хост на адрес 10.255.255.1 чрез криптиран тунел (при условие, че защитните стени на локалния и отдалечения хост позволяват тези връзки).

Големият недостатък на тази схема е необходимостта от достъп към отдалечен сървърчрез SSH с права на суперпотребител (тъй като правата на суперпотребител са необходими за създаване на TUN интерфейс), докато много системни администратори предпочитат да отказват root достъп чрез SSH за по-голяма сигурност. Отстраняването на този недостатък е описано в следващия параграф.

SSH тунел с непривилегировани потребителски права

За да създадете SSH тунел с правата на непривилегирован потребител, първо трябва да създадете TUN интерфейс, принадлежащ на този потребител (за да създадете TUN интерфейс, във всеки случай ще ви трябват права на суперпотребител на отдалечения хост).
За да създадете TUN интерфейс в по-стари Linux дистрибуцииИзползва се инструментът tunctl (трябва да е достъпен от хранилищата на дистрибуцията), в по-новите дистрибуции тази функционалност е включена в пакета iproute2. За да определите как да създадете TUN интерфейс на вашия хост, изпълнете командата

Ако командата дава грешка

Обектът "tuntap" е неизвестен, опитайте с "ip help".

Това означава, че трябва да използвате инструмента tunctl, като сте го инсталирали преди това (yum install tunctl), в противен случай командата трябва да изведе списък с TUN/TAP интерфейси на хоста.

Да преминем към настройката.

Създайте непривилегирован потребител на отдалечения хост:

useradd ssh_tunnel

Създайте TUN интерфейс, принадлежащ на този потребител

Използване на tunctl:

tunctl -n -t tun7 -u ssh_тунел -g ssh_тунел

Използване на iproute2:

ip tuntap добави dev tun7 режим tun потребител ssh_tunnel група ssh_tunnel

Свързването на SSH тунел е подобно на предишния пример:

# на локален хост
sudo ssh -w 7:7 -l ssh_tunnel 192.168.1.100
ifconfig tun7 нагоре 10.255.255.2 pointopoint 10.255.255.1
# на отдалечения хост
ifconfig tun7 нагоре 10.255.255.1 pointopoint 10.255.255.2

Създаване на потребител само за SSH тунелиране

IN в този моментЩе бъде взето предвид предотвратяването на използването на конзолата от непривилегирован потребител, като същевременно се разреши SSH тунелиране за този потребител. Няма да работи да зададете обвивката „/bin/false“ или „/sbin/nologin“ за потребителя, защото в този случай потребителят изобщо няма да може да установи SSH връзка.

За да въведете описаните ограничения, трябва да добавите следните редове в края на файла с настройки на OpenSSH сървъра (/etc/ssh/sshd_config) и да рестартирате OpenSSH сървъра (услуга sshd рестартиране)

Съвпадение на потребител ssh_tunnel
X11 Препращане №
AllowTcpForwarding да
AllowAgentForwarding №
GatewayPorts бр
ForceCommand echo "Този акаунт може да се използва само за тунелиране"; котка

Ограничението в този пример е наложено върху предварително създадения потребител ssh_tunnel. Параметърът ForceCommand кара потребителя автоматично да изпълни командата „echo „Този акаунт може да се използва само за тунелиране“; котка" веднага след свързването. Това ще попречи на потребителя да използва конзолата нормално, защото ако cat процесът бъде убит чрез натискане на Ctrl+C, SSH връзката ще бъде затворена.

SSH-тунелирането може да помогне не само в случаите, когато е необходимо да се предаде некриптиран трафик през криптирана връзка, но и когато нямате достъп до ресурс в мрежата, но достъпът е необходим.

Нека да разгледаме създаването и настройката на няколко опции.

И така, имаме сървър, да го наречем домакин-1. Към него имаме пълен достъпсамо от SSH- но трябва да отворим котка, работещ на порт 8082 - до който не могат да ни пуснат.

Ще разгледаме опцията с настройка WindowsИ Замазка.

Отваряне SSH- връзка с към необходимия сървър, нека влезем.

Посочваме следните параметри:

Порт източник: всеки неизползван порт на вашата система;
Целеви порт: 127.0.0.1:8082

Кликнете Добавете, Тогава Приложи.

Отидете в настройките на браузъра и задайте параметрите на прокси сървъра:

Сега остава само да отворим страницата http://localhost:3002 в браузъра - и стигаме до страницата коткана сървъра домакин-1.

Ако тунелът не работи, проверете на сървъра дали препращането на пакети е разрешено. Във файла /etc/ssh/sshd_config намерете и разкоментирайте реда:

AllowTcpForwarding да

И рестартиране на SSHd:

# service sshd restart Спиране на sshd: [ OK ] Стартиране на sshd: [ OK ]

Друг пример - имаме същия външен сървър, от който имаме нормален достъп до всякакви ресурси в интернет. Но от работното място имаме достъп до и е затворено.

Ние изпълняваме подобни действия, но с малки разлики. Настройки в Замазка:

Изходен порт - оставете същото, но вместо това Местен- избирам Динамичен. Кликнете Добавете, Приложи.

Да преминем към настройките на браузъра:

Моля, обърнете внимание, че типът прокси тук не е HTTP, а SOCKS.

Насладете се на достъп до любимите си сайтове.

И един по-интересен случай.

Имаме същото домакин-1. В допълнение към него има втори сървър, да го наречем домакин-2. Освен това разполагаме с машина с Windows, който трябва да получи достъп до ресурса TeamCityна сървъра домакин-1на порт 8111. В този случай достъп от Windows-имаме само машини за сървъра домакин-2и само до порт 22.

Като начало издигаме тунела между домакин-1И домакин-2. Ние извършваме на домакин-1:

$ ssh -f -N -R хост-2:8082:локален хост:8111 потребителско име@хост-2

Така че отваряме тунел, който локално (на домакин-1) гледа към порт 8111, а от другата страна е машината домакин-2, на който порт 8082 се отваря и чака входящи връзки. При получаване на пакети на порт 8082 (и само през lo0 интерфейс! това е важно) - ще ги пренасочи към машината домакин-1порт 8111.

Относно интерфейса lo0. При инсталиране SSH-tunnel, дори при посочване на външния IP на машината - връзката се повдига само от localhost, т.е. 127.0.0.1.

Нека да разгледаме домакин-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* СЛУШАЙТЕ -

За да промените това, трябва да редактирате конфигурационния файл на sshd демон - /etc/ssh/sshd_config и да промените параметъра:

#GatewayPorts №

Но няма да го правим сега, това е само бележка.

Да продължим. Да преминем към настройката ЗамазкаНа нашия Windows-кола. Тук всичко е просто - използваме пример 1 от тази статия, просто сменете порта на желания (на екранната снимка, между другото, той е там). Нека се свържем Замазкакъм домакина домакин-2, настройвам тунел. Променете настройките в браузъра прокси— и получаваме това, от което се нуждаем, посочете адреса http://localhost:3002:

SSHе доста чувствителен към загуба на пакети, така че тунелите могат да бъдат изпускани често.

За да избегнете това, можете или да си поиграете с параметрите във файла с настройки на sshd - /etc/ssh/sshd_config:

#TCPKeepAlive да #ServerAliveInterval #ServerAliveCountMax

Или използвайте помощната програма autossh.

От редактора на AnswIT:

В този пример, ако порталът или който и да е друг ресурс, до който Алекс трябва да има достъп, се намира на самия рутер (например на 192.168.0.1:80), тогава командата ще изглежда така:

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [имейл защитен]

Ако услугата е достъпна на localhost (например локален SQL сървър), тогава достъп до нея
може да бъде достъпен:

alex@Alex-PC:~$ ssh -L
127.0.0.1:13306:127.0.0.1:3306 [имейл защитен]

Конструкции като -L 127.0.0.1:80:127.0.0.1:80 може да изглеждат доста странни на пръв поглед. Но в тях няма нищо сложно, ако помните, че решението да
маршрутизиране на пакета се получава от отдалечената страна на тунела. Трябва да запомните основното правило: втора двойка
<адрес>:<порт>обработени от отдалечената страна на тунела.
Следователно пакет с адрес на местоназначение 127.0.0.1 в правилото за превод ще бъде обработен от втората страна на SSH сесията и нищо друго.

Както вероятно вече се досещате, входната точка на тунела може да бъде създадена не само на интерфейса за обратна връзка. Ако тунелът трябва да бъде направен достъпен не само за локалния хост, но и за други участници в мрежата, тогава истинският адрес на интерфейса може да бъде указан като адрес на сокета.

alex@Alex-PC:~$ ssh -L
10.0.0.5:8080:192.0.0.2:80 [имейл защитен]

Компютърът на Алекс Alex-PC има два мрежови интерфейса с адреси 2.2.2.2 и 10.0.0.5. По време на процеса на установяване на сесия, ssh ще отвори сокет 10.0.0.5:8080 на компютъра Alex-PC. Сега Алекс има достъп до портала 192.168.0.2:80 от своя лаптоп с адрес 10.0.0.4 и от всички
вашата домашна мрежа 10.0.0.0/24.

Обратен SSH тунел - изложете вашите ресурси на интернет

Уеб сървърът Apache работи на лаптопа на Алекс и е достъпен
на 127.0.0.1 с тестово копие на фирмения портал. Алекс трябва да даде достъп до уеб сървъра на своя
колеги да тестват интерфейса. Като цяло за такива цели би било хубаво Алекс да внедри по-надежден тестов пясъчник. Но тъй като нашият Алекс не е нищо повече от виртуален герой в тази статия, той
демонстрация на това как работи SSH тунелът
сесия между вашия лаптоп и Linux рутер. И използването на параметъра -R отваря порт 8080
вътрешния интерфейс на рутера с адрес 192.168.0.1, който препраща към сокет 127.0.0.1:80 на неговия тестов уеб сървър.

Както можете да видите, на рутера sshd процесът отвори локален сокет 8080

alex@Router:~$
sudo lsof -nPi | grep 8080

sshd
17233 Алекс 9u IPv4
95930 0t0 TCP 192.168.0.1:8080 (СЛУШАЙТЕ)

Нека да видим какво се случва с TCP пакет, изпратен от компютър 192.168.0.200 към тестов портал, публикуван на 192.168.0.1:8080:
1. TCP пакет с адрес на източник 192.168.0.200 и адрес на местоназначение и порт 192.168.0.1:8080 ще завърши на сокет 192.168.0.1:8080, отворен от процеса sshd;

Както можете да видите, правилата за излъчване са много прости. Хостът, който отваря сокета за тунела, превежда адреса и порта на местоназначението според правилото за превод. Хостът от противоположната страна на тунела променя адреса на източника и порта според своята таблица за маршрутизиране. Таблицата за маршрутизиране е необходима, първо, за да изпрати пакета в правилната посока и, второ, за да произведе
замяна на адреса на източника с адреса на интерфейса, от който ще бъде изпратен пакетът.
Една важна забележка, която оставих в края на статията.
Ако при отваряне на входна точка на тунел се използва localhost вместо адреса на реалния интерфейс, тогава той може да бъде пропуснат, като по този начин командата се съкращава с

alex@Alex-PC:~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [имейл защитен]

alex@Alex-PC:~ssh -L
8080:192.0.0.1:80 [имейл защитен]

Тази важна синтактична функция ще бъде полезна в следния пример.

Двойно тунелиране

Нека разгледаме един малко по-сложен пример. Потребител на SQL-Tester, разположен зад NAT, трябва да получи достъп до базата данни на SQL сървър, който също се намира зад NAT. SQL Tester не може да се инсталира
връзка директно към сървъра, тъй като няма съответни преводи в мрежата на NAT сървъра. Въпреки това можете да установите SSH сесия и от двата хоста с междинен
сървър 3.3.3.3.

От SQL сървъра установяваме SSH връзка към сървър 3.3.3.3 и го отваряме на интерфейса за обратна връзка на сървъра
3.3.3.3 порт 13306, отнасящ се до локалната SQL услуга, работеща на локалния сокет 127.0.0.1:3306 на SQL сървъра:

dbuser@SQL-сървър:~$ ssh -R 13306:127.0.0.1:3306
[имейл защитен]

Сега от клиентския хост SQL-Tester установяваме връзка към 3.3.3.3 и отваряме порт 3306 на интерфейса за обратна връзка на клиента, който от своя страна препраща към 127.0.0.1:13306 на сървъра
3.3.3.3, което... препраща към 127.0.0.1:3306 на SQL сървъра. Просто е Дж

тестер@SQL-тестер:~$ ssh -L
3306:127.0.0.1:13306 [имейл защитен]

Динамичен тунел - SSH като Socks прокси

За разлика от тунелите с изрично указание на правилата за превод, динамичният тунел работи на напълно различен принцип. Вместо да указвате едно към едно адрес: порт съпоставяне за всеки целеви адрес и порт, вие
отворете сокет от локалната страна на SSH сесията, което превръща вашия хост в прокси сървър, работещ с помощта на протокола SOCKS4/SOCKS5. Нека да разгледаме
пример:

Създайте динамичен тунелен сокет 127.0.0.1:5555 на клиентския хост в SSH сесия към сървър 2.2.2.2

потребител@клиент:~$ ssh -D 5555 [имейл защитен]

Проверка дали портът е отворен

потребител@клиент:~$ sudo lsof -nPi | grep 5555

ssh
7284 потребител 7u
IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (СЛУШАЙТЕ)

И регистрираме прокси в настройките на браузъра или който и да е
друг софтуер, който поддържа SOCKS проксита.

Сега целият трафик на браузъра ще преминава през SOCKS прокси вътре в криптирана SSH връзка
между хостове 1.1.1.1 и 2.2.2.2.

Как да използвам SSH на Microsoft Windows?

След като прочетете статията, може да решите, че всички предимства на SSH тунелите са достъпни само
потребители на Unix-подобни системи. Обаче не е така. Почти всичко за Windows, което използва SSH протокола, има поддръжка за тунелиране.

От известно време е възможно да се използва Windows като нещо повече от SSH клиент. Имам възможност.

Кога да използвате SSH тунели?

Разбира се, за да създадете постоянни тунели на бойни сървъри, трябва да използвате специален софтуер. Но за бързо решаване на проблема с пренасочване на портове, отстраняване на неизправности, получаване на бърз отдалечен достъп и като цяло решаване на конкретен проблем „тук и сега“, използването на SSH тунели често е добра помощ.