Pull to refresh

Comments 28

здорово!!! но громоздно — нельзя ли попроще без прописи интерфейсов конфигов итд?
если проще и только для браузера то можно ssh -C user@host -D port и прокси прописать в браузере (сокс 127.0.0.1:port) боян конечно, но зато не так сложно :)
hamachi, remobo
спасибо автору, теперь я знаю что они мне не нужны.
UFO just landed and posted this here
есть роутер с линуксом и реальным ip
я поэтому и сказал, что мне не нужны, а не нужны вовсе
Я правильно понимаю, что всё это можно организовать без логина под рутом, а через sudo?
скажем заменить command="/sbin/ifdown tun1;/sbin/ifup tun1" на command=«sudo /path/to/some/script.sh» в котором уже делать всякие гадости от рута?

п.с. к сожалению самому ковыряться в этом лень, а необходимость логиниться от рута кажется необоснованной.
Там ничего от юзерского рута не выполняется, кроме как при настройке. Никакиз костылей в виде судо не надо.
srsly?
гугл кстати показал оригинал статьи и обсуждение на счёт того как люди пытаются обойти необходимость использовать логин через root'а
www.debian-administration.org/articles/539#comment_20
очевидный минус VPN-over-SSH — это требование root-доступа к «серверу». Кроме того, UDP будет тормозить потому что идет по TCP-каналу. Если уж есть root-доступ, то эффективнее поднять openvpn по UPD. А если нет root-доступа, и UDP форвардить не обязательно — то лучше воспользоваться transocks_ev, с ним можно использовать любой «сервер» (=машина с обычным пользовательским аккаунтом, например на работе/в институте) для NAT своего TCP-трафика.
а без рута как вы собираетесь вносить изменения в таблицу маршрутизации?
реализация интересна, но бестолкова… тот же ipsec давно поддерживается на уровне ядра, а если не требуется шифрование — тот же gre.
ммм, openvpn на мой взгляд проще и понятней, отказоустойчивость нативно реализована, автопроверка линка и прочие удобства. Но все равно спасибо, добавил в избранное, альтернативу никогда не помешает на заметке держать.
tun/tap как правило, нет на vps
tun/tap как правило подключают по запросу, где-то бесплатно, где-то за 3-5 баксов.
Гораздо чаще встречается проблема, когда доступ в Интернет только HTTP 80,443; никаких 22 портов (крупная корпоративная сеть, например). Тут openvpn замечательно помогает.
Мне кажется, или для всего этого есть OpenVPN?
для всего это есть два десятка технологий, а конкретно этот способ вполне может кому-то пригодиться ;)
Предлагаю версию для параноиков, в туннеле OpenVPN сделать ipsec канал, через который сделать вот это самое ssh-шаманство.
ipsec, gre… А если вам открыт только 22-ой порт на сервер, то что вы там городить то собрались? С таким апломбом, как-будто человек не в курсе технологий 10 летней давности. В одном месте использовал, так как настраивал VoIP, а из доступа как раз только ssh и был, с рутовым доступом к серверу, естественно.
чувак, прости, но как-то не вяжутся «вам открыт только 22й порт на сервер» и «из доступа только ссш с рутовыми правами» :)
Я не «чувак», и на брудершафт с вами не употреблял, прошу учитывать. Все вяжется, если ты настраиваешь и обслуживаешь один сервис для компании, на отдельном сервере.
Опечатка там где «генерируем ключ», наверное все-таки 4 Кбайта
Точно 4 килобита.
en.wikipedia.org/wiki/RSA за эту версию и man ssh-keygen говорит про -b
Specifies the number of bits in the key to create.
4096 бит, в килобитах измеряется скорость соединения, все остальное в килобайтах
1. Хочется придираться — придирайтесь по делу (только вот зачем, на смысл ведь не влияет?). Правильно киби-, а не кило- (потому что в основании 2-ка, а не 10-ка). И как уже сказали бита, а не байта.
2. Ваше последнее утверждение сродни следующему: «в сантиметрах — только деления на линейке, а все остальное измеряется в метрах». На самом же деле, ничего не мешает все измеряемое в байтах измерять и в битах, и наоборот.
3. Если же Вы про традиции, намекая на боды (бит/с), в которых на самом деле измеряют только скорость, то в шифровании использование битов, а не байтов — не менее классический случай.
Круто. У меня в свое время не получилось, так как я хотел обойтись без логина рутом и без судо.
Спасибо, понравилось.
Сначала подумал громоздко, потом посмотрел на свою гору «простых» скриптов с пробросом портов на все случаи жизни и… в обще ваш способ наверное будет аккуратнее.
Для разовых/временных решений само то. Хотя временно обхожусь пробросом портов через SSH. А на постоянку делаю IPSEC.

К тому же не люблю слоёных пирожков из протоколов (TCP-IP-PPP-SSH-TCP-IP). Хотел было сказать что нужно почитать «Why TCP Over TCP Is A Bad Idea». Но тут же нашёл вменяемое опровержение www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf

ИМХО, основной минус у таких тунелей — они не симметричны. Т.е. они должны быть всегда поднятыми, если со стороны сервера (SSH) создаются TCP соединения. В IPSEC же оба конца тунеля «равноправны».
Sign up to leave a comment.

Articles