VPN - она какая?

Програмы vpn делают тунель, на концы вешаются виртуальные сетевые интерфейсы. По большому счету, кроме того кто к кому подключается, разницы между клиентом и сервером нет. И остальном не отличается от маршрутизации между lan и wan без vpn. В твоем случае тебе вообще может хватить туннелирования и проброса через него с порта на порт, без возни с маршрутизацией на более низких уровнях.

А еще прокси стали называть vpn.

По большому счету, кроме того кто к кому подключается, разницы между клиентом и сервером нет.

Значит, VPN таки 2-сторонний? Если так, то это радует, потому что есть возможность маневра.
Мне было бы удобнее пользоваться, если VPN-сервер будет на удаленном конце.

В твоем случае тебе вообще может хватить туннелирования

Это как - что-то типа SSH-туннеля или ShadowSocks?
Но они дают только Socks-прокси, который не все прилодения «понимают», а мне надо ганять любой трафик, неважно от какого приложения.

что-то типа SSH-туннеля Socks

Нет. То, что я имел в виду, для ssh -L или -R.

А еще прокси стали называть vpn.

LOL, кто?)

А, ну да, что-то припоминаю о таких SSH_туннелях, их привлекательность - чрезвычайная простота.

Когда-то давно долго пытался пользоваться этими SSH-туннелями, но сколько не старался, так и не смог победить их досадное свойство - периодическая потеря коннекта, причем довольно частая - несколько раз в час.
Ни удаленный VPS, на котором поднят туннель, ни что-то другое здесь виноваты не были, потому что если просто зайти по SSH на VPS, то коннект держится сутками, а SSH-тоннель рвется на раз.

Да, я пытался использовать различные скрипты для автоподъема коннекта, но толком ни один из них так и не помог, так что пришлось забросить тему SSH-туннелей из-за их неустойчивости :-(

То, что называется VPN в Opera и куче дополнений к браузерам, разве это не прокси?

То, что называется VPN в Opera и куче дополнений к браузерам,

Понятия не имею: никогда этим не пользовался.

Если VPN, как водопроводная труба

VPN это как твоя локалка. Только виртуальная, поверх инета.

Хомячки частенько используют VPN-клиент, чтобы ходить на сайты, которые заблокировал любимый РКН

Потому что в этой виртуальной локалке гейтвей находится «там», на удалённой машине.

другая задачка: понадобилось вынести доступ к веб-серваку, который крутится на домашнем NAS, куда-нибудь подальше от IP своего провайдера, в какую-нибудь Гвинеа-Бисау

Пажжи ЯННП, ты хочешь чтобы «вход» на твой сервак был из оттуда? Так конечно можно, но зачем?

Тебе вообще по большому счету VPN тут не нужен. Ставишь на удаленный сервер http reverse proxy, настраиваешь tls, профит.

Вот этот VPN, эта «труба», она какая - 2-сторонняя или односторонняя?

Проорал

Хомячки частенько используют VPN-клиент, чтобы ходить на сайты, которые заблокировал любимый РКН.

запрос в трубу, ответа жду письмом, пристегнутым к сове, ловко облетающей РКН.

Нормально работают ssh-тоннели. Удобно на ноуте, которым подключаешься где угодно, в любом сортире с открытым вайфаем. На некоторых провайдерах да, ssh регулярно падают, как при маскарадинге. Для этого есть небольшой лайвхак - рядом с тоннелем форвардится какой-нибудь ненужный порт, и ставится опции:

ExitOnForwardFailure yes ServerAliveInterval 20

Падающий тоннель можно поднимать из systemd.

Ставишь на удаленный сервер http reverse proxy,

Самое смешное, что сейчас у меня оно так и работает :) Через реверсный nginx, но:

Нормально работают ssh-тоннели... etc.

Ну, у меня тогда не получилось, сколько не пытался. Может, по вашим новым советам оно и получилось бы, но:

Ни nginx, ни ssh-тоннели подходят плохо, и вот почему.

Дело в том, что веб-сервер представляет собой проприетарную хреновину (ессно, с закрытым кодом), обслуживающую одну специфическую железяку. Соответственно замены этому веб-серваку нет.

И получилось: по удаленке через реверсный прокси http проходит прекрасно, но этот сервак выдает еще какие-то фиг-знает телеметрические пакеты, уходящие на чужой центр обслуживания.
Если эти пакеты до центра не доходят, то управление железякой получается неполное.

Пытался выяснить по каким портам ходят эти пакеты, но толком так и не понял, похоже, они даже скачут.
И вот поэтому прокси и ssh-туннели тут не помогут.

Поэтому вижу один выход: замутить VPN-канал, по которому будут ходить ЛЮБЫЕ пакеты по ЛЮБЫМ портам.

ssh умеет port forwarding и tonnel L2/L3. Последнее создает обычные интерфейсы с двух сторон tun, через которые ходят все пакеты.

PS Правильно говорить не столько о VPN, сколько о тоннеле.

Вот этот VPN, эта «труба», она какая - 2-сторонняя или односторонняя?

VPN — Virtual Private Network.

Можно, как хомячки, на NAS поставить VPN-клиент, а VPN-сервер поставить в Гвинеа-Бисау. Но тот же возникает сомнение - а будет ли такая схема работать?

Можно, будет.

всезнающие

Я вообще мимокрокодил. ☺

Ну да, правильнее тоннель. Ок, давайте еще разок попробую SSH.
Чтобы долго не вспоминать, подскажите плиз, законченную команду для поднятия ssh-тоннеля - такого, чтобы по нему могли бегать любые порты/пакеты.

ssh умеет как проброс порта с созданием socks так и настоящее туннелирование с маршрутизацией и поднятием виртуальных интерфейсов. но почему не openvpn?

Команда простая # ssh myhost

Что надо сделать:

1. Пару ключей для root. Засунуть публичный ключ на удаленный хост, например, с ssh-copy-id. Не забыть разрешить логин руту через ssh. Можно запретить руту выполнение команд по этому ключику.

2. Конфиг для ssh, например в ~/.ssh/myhost/config:

#
# Tunnel to my host
#
Host myhost
HostName <myhost_IP_address>
Port 22
User root
# Private key for my host
IdentityFile ~/.ssh/myhost/id_myhost
IdentitiesOnly yes
Batchmode yes
Tunnel point-to-point
TunnelDevice 10:10
ExitOnForwardFailure yes
ServerAliveInterval 20
PermitLocalCommand yes
LocalCommand ip link set %T up && ip a add 192.168.50.2/32 peer 192.168.50.1 dev %T
RemoteCommand ip link set tun10 up && ip a add 192.168.50.1/32 peer 192.168.50.2 dev tun10

В строке HostName поставить ip адрес вашего хоста.

3. Добавим в ~/.ssh/config:

...
include myhost/config
...

4. При запуске команды из первой строки, поднимается тоннель. С обоих сторон появляются интерфейсы tun10 с настроенными адресами. Проверяем тоннель ping -n 192.168.50.1

Следующим этапом можно сделать автозапуск.

но почему не openvpn?

Потому что чукча :) Двести раз брался за него, но так и не справился с настройкой, чересчур сложен для меня.
Да и не только для меня, он вообще такой изначально.

Пробовал L2TP, но он какой-то неродной для Linux, пришлось ставить со всякими уловками, так что не понравилось.

Сейчас думаю поставить PPTP, большая криптоустойчивость для моей затеи неважна.
Ну или снова попробовать SSH-туннель, если напомните команду для пропуска всех портов.

А, уже напомнили :), спасибо, вникаю

Следующим этапом можно сделать автозапуск.

Автозапуск сделаю, важнее костыль для автоподъема при обрыве канала.

Автозапуск сделаю, важнее костыль для автоподъема при обрыве канала.

И так автозапуск через systemd, а не какой-то там костыль :)

1. Создаем файл /etc/systemd/system/ssh-tun@.service (без названия хоста!!!) следующего содержания:

[Unit]
Description=Setup a secure tunnel to %I by vop
After=network.target

[Service]
ExecStart=/usr/bin/ssh -NT %i

# Restart every >2 seconds to avoid StartLimitInterval failure
RestartSec=5
Restart=always

[Install]
WantedBy=multi-user.target

2. Делаем команду systemctl --now enable ssh-tun@myhost

Да собственно говоря, все. Если есть несколько тоннелей в разные стороны, то удобно из так же запускать, не создавая новых сервис-юнитов.

Вариант с ssh удобен тем, что тоннель ставится «из подручных средств», без установки дополнительного софта. Но в любом случае, кому как удобно.

Спасибо, Oleg_Iu! И как, по вашему опыту, насколько часто рвался тоннель у вас?

У меня специфический прожектик, который очень не любит реконнекты, возникают ненужные проблемы.

Это зависит от причины разрыва соединения (от провайдера, через который работаешь). У меня постоянно несколько тоннелей с рабочего ноута в разные концы мира, разрывы бывают редко, если только не совсем убитый пров попадается где-нибудь в кафе.

А насколько быстро происходит реконнект?
Если считать, что причина обрыва была короткая, доли секунды.

В настройках systemd стоит 5 секунд. Реконнект - не большая проблема, поднимается достаточно быстро. Возможно, есть какие камни, но где их не бывает.

Кстати, на дальнем конце в /etc/sshd_config не забыть добавить PermitTunnel yes.

Спасибо, спасибо! Завтра займусь внедрением ваших советов в жизнь :)

Откровенно говоря, ssh-туненль мне тоже нравится больше ввиду простоты и из-за того, что он всегда под рукой.

Лишь бы только коннект оказался устойчивым...

Там systemd файле надо вместо -NT указать просто -T. Если сеть с удаленной стороны настраивать не через RemoteCommand, а как hotplug интерфейс, тогда можно и -NT.

А вот еще, чуть не забыл самый главный вопрос - по айпишникам, которые будет «видеть» веб-сервер.

Например так: в локалке стоит веб-сервер, на который заходят снаружи по SSH- или VPN-туннелю:

[Юзер: 45.45.45.45] ----> [Удаленный VPS: 85.85.85.85] <=== тоннель ===> [WebServer: 192.168.1.5]

Юзер=45.45.45.45 заходит по тоннелю на локальный веб-сервер.

Какой IP будет «видеть» веб-сервер?

Если WebServer сидит на приватных адресах, а ходить надо через VPS на реальных, то там, на VPS надо настраивать порт-форвардинг - тогда WebServer будет видеть дальний от него конец тоннеля. Можно поставить прокси, тогда WebServer может увидеть адрес клиента. Если, конечно, WebServer это умеет делать.

Oleg_Iu, не понял ваш ответ. Можно еще раз - какой IP будет «видеть» веб-сервер?
Конкретно в цифрах.

Что касается реверсного прокси, который сейчас использую вместо тоннеля в вышеприведеной схеме, то веб-сервер показывает, увы, не реальный IP Юзера=45.45.45.45, а только IP VPS=85.85.85.85.
И это очень плохо :(

Если шифрование не нужно - самым простым вариантом будет поднять Gre ил IpIp. Буквально в две строчки.

Oleg_Iu, не понял ваш ответ. Можно еще раз - какой IP будет «видеть» веб-сервер? Конкретно в цифрах.

Если вы поднимите туннель прямо от юзера до вебсервра, то будут те ip клиента, которые вы выберите на конце туннеля со стороны юзера. При хождении через прокси, разумеется, будут IP прокси.

Если вы поднимите туннель прямо от юзера до вебсервра

Вы опять не поняли :-(

К примеру, допустм я поднял вот такой конкретный туннель:

[Юзер: 45.45.45.45] ----> [Удаленный VPS: 85.85.85.85] <=== туннель ===> [WebServer: 192.168.1.5]

- какой IP будет «видеть» веб-сервер. Не словами - в цифрах!

Если шифрование не нужно - самым простым вариантом будет поднять Gre ил IpIp. Буквально в две строчки.

Ширование действительно не очень нужно, главное, чтобы это был туннель, передающий реальные IP юзеров на локальный веб-сервер (ну и не медленный, как некоторые).

По Gre пока не нашел «буквально две строчки», зато нашлось вот это:

Проблема NATа
Так как GRE является протоколом сетевого уровня и не использует порты (в отличие от протоколов TCP и UDP), а одним из необходимых условий работы механизма PAT является наличие «открытого» порта, то работа протокола GRE через межсетевой экран может быть затруднена.

По ipip (у вас почему-то lplp) вообще не нашлось полезной информации, так, одни отголоски.
Если она только на английском, то я его не разумею.

К примеру, допустм я поднял вот такой конкретный туннель:

[Юзер: 45.45.45.45] —-> [Удаленный VPS: 85.85.85.85] <=== туннель ===> [WebServer: 192.168.1.5]

• какой IP будет «видеть» веб-сервер. Не словами - в цифрах!

Ну, я как бы об этом и писал. Если на VPS форвардинг/прокси/nat/masquarad - то сервер увидит адрес VPS. Если там настроен роутинг - то увидит юзера. Если у вас юзер сидит в реальном интернете, а туннель на локальных адресах - вряд ли у вас получится роутинг. Если между 45 и 85 поднимите второй туннель, тогда у вас получится именно VPN и сервер увидит адрес юзерского конца туннеля.

Вообще, это все не про туннель история, а про обычный ip networking.

Блин! Ну вы и непонятливый! Дважды спросил - и всякий раз мимо :-(

Ладно, сам разобрался. Вот нужный ответ:

45.45.45.45

а без форвардинга -

85.85.85.85

Мне цифрами сразу понятнее, чем вникать в слова.
А цифры я потом перевожу в нужные слова :-)

Но в любом случае - громадное спасибо! :-)

ip tunnel add tun0 mode ipip remote <remote_ip_address> local <local_ip_address>
ip addr add <ip_address>/24 dev tun0
ip link set tun0 up

Вот это и всё. Использую ipip, т.к. в последнее время провайдеры частенько блокируют GRE (не пойму зачем).

Как там через NAT - не знаю, не сталкивался. Всегда есть или белый IP, или возможность его получить.

Ширование действительно не очень нужно, главное, чтобы это был туннель, передающий реальные IP юзеров на локальный веб-сервер (ну и не медленный, как некоторые).

Я когда-то делал такую задачу на Mikrotik CHR (Cloud Hosted Router). Суть была в том что в цепочке NAT нужно было выполнять действие netmap вместо dnat, и тогда Web-сервер «видел» интернетовские IP пользователей, а не адрес с ipip-туннеля.

В «обычном» Linux тоже должно быть что-то похожее, так как Mikrotik RouterOS, по сути, обвертка над Linux.

Xoomoh
Вот спасибо!!! Эти 3 строки мне очень понравились. Особенно если они заработают :-)

А как в ipip насчет устойчивости туннеля и реконнекта при его обрыве?

Xoomoh а куда, собственно, пихать эти волшебные строки?

Ведь есть два места - удаленный VPS, и локальный сервер с локальным же веб-сервером.

а куда, собственно, пихать эти волшебные строки?

С обеих сторон, симметрично.

А как в ipip насчет устойчивости туннеля и реконнекта при его обрыве?

ipip и gre это stateless-протоколы. То есть у них нет состояния «подключено» или «отключено». Есть связь - пройдет пакет. В некоторых случаях это очень удобно.

Xoomoh

Симметрично, т.е. видимо, так, уж извините за непонятливость -

на десктопе:

ip tunnel add tun0 mode ipip remote <85.85.85.85> local <192.168.1.100>
ip addr add <ip_address>/24 dev tun0
ip link set tun0 up

ip tunnel add tun0 mode ipip remote <192.168.1.100> local <85.85.85.85>
ip addr add <ip_address>/24 dev tun0
ip link set tun0 up

С одной стороны:

ip tunnel add tun0 mode ipip remote 45.45.45.45 local 85.85.85.85

С другой зеркально:

ip tunnel add tun0 mode ipip remote 85.85.85.85 local 45.45.45.45

Вот собственно туннель и создан. Появился новый интерфейс tun0. Нужно назначить IP-адрес интерфейсу туннеля:

ip addr add 192.168.1.1/24 dev tun0

И с другой стороны:

ip addr add 192.168.1.2/24 dev tun0

/24 маска сети. Сокращенная запись от 255.255.255.0. Но тут полная свобода выбора. Можно /30, например. Ну и адреса любые.

Третья строка это активация интерфейса.

PS: Прошу прощения что долго отвечаю, на сайте не частый гость. Если что можно спросить в Telegram. Ник такой как и тут.

Xoomoh

Вот теперь куда понятнее :)

PS: Прошу прощения что долго отвечаю

Ну что вы! Наоборот. спасибо вам, что так подробно рассказываете, и теперь у меня появился реальный шанс широко применять очень простой в настройке туннель.

С OpenVPN, L2TP, PPTP, WireGuard нахлебался вдоволь. Какие-то удалось запустить, и то с большим трудом, какие-то нет.
Сложные они в настройке, их разработчики не заморачиваются созданием удобных инструментов для настройки, а сторонние скрипты-установщики не всегда работают корректно.