Comments 39
Открытый порт можно было проверять netcat'ом ('nc -z'), тогда бы всё уместилось в один скрипт.
Чем принципиально отличается коннект VNC от коннекта TeamViewer/Radmin/NX/RDP?
Принципиально — ничем.
Это один из протоколов доступа к рабочему столу. Выбирайте любой. VNC в статье взят для примера.
Это один из протоколов доступа к рабочему столу. Выбирайте любой. VNC в статье взят для примера.
А при коннекте, используя RDC. как задать отличный от TCP 3389 порт на который надо коннектиться?
Написать в поле адреса [адрес]:[порт], например, 127.0.0.1:6689.
А как сделать чтобы серверная часть слушала на отличном от 3389 порту?
Если применительно к статье, то просто указать порт при вызове SSH:
и коннектся на порт 2002.
Если вообще — то 3389 — порт прописанный в стандарте. Нужно копать в сторону port redirect.
ssh -R 2002:127.0.0.1:3389и коннектся на порт 2002.
Если вообще — то 3389 — порт прописанный в стандарте. Нужно копать в сторону port redirect.
Это к виндовым спецам, я не знаю.
С другой стороны, зачем? Ведь совсем не обязательно, чтобы оба конца тунеля были на одинаковых портах.
С другой стороны, зачем? Ведь совсем не обязательно, чтобы оба конца тунеля были на одинаковых портах.
разные методы шифрования при почти одинаковом функционале
> Использовать TeamViewer & Co. — не наш путь.
Однако…
> Использовать промежуточный сервер для организации соединения.
Это какое-то деление на ноль. Откройте для себя logmein.com, хотя бы.
Однако…
> Использовать промежуточный сервер для организации соединения.
Это какое-то деление на ноль. Откройте для себя logmein.com, хотя бы.
Не согласен.
1) Я не хочу, чтобы в организации канала принимали участие сервера третьих фирм.
2) Фишка статьи в организации callback вызова штатными средствами. Logmein хорош, но я не стал бы ставить его на рабочие машины.
1) Я не хочу, чтобы в организации канала принимали участие сервера третьих фирм.
2) Фишка статьи в организации callback вызова штатными средствами. Logmein хорош, но я не стал бы ставить его на рабочие машины.
Ну это как-то не секьюрно. Поднимите ВПН хотя бы.
Между W и VDS — зачем? Там SSH. Между VDS и H — да, можно, но тема статьи проброс портов.
Я еще пропустил момент идентификации по ключам, но это только «утяжелило» бы статью.
Я еще пропустил момент идентификации по ключам, но это только «утяжелило» бы статью.
Статья неплохая. И хорошо, что вы понимаете. Но проблема в том, что кто-то прочитает, и сразу решит сделать точь в точь. А в результате будет пользоваться таким не очень безопасным решением. Я считаю, что стоит немножко думать и за читателя, предостерегать как-то. Но воля Ваша :)
А ssh не считаю панацеей. Юзаю ВПН и сплю спокойней, паранойя спасет мир.
А ssh не считаю панацеей. Юзаю ВПН и сплю спокойней, паранойя спасет мир.
Хотите фокус? Внешний сервер не нужен!
Используйте PWNAT — http: // samy.pl / pwnat /
(посмотрите как оно работает — весьма интересно!).
Используйте PWNAT — http: // samy.pl / pwnat /
(посмотрите как оно работает — весьма интересно!).
Этот «фокус» пройдет только с IP-NAT, т.е. только если внешний порт останется таким же как внутренний — 2222.
Через PNAT (коих 99%) фокус не пройдет — если только случайно порт не оттранслируется в те же 2222.
Собственно промежуточный хост в STUN в основном и нужен для того, чтобы внешние порты друг друга сторонам сообщить, IP и через какой-нибудь фокус (вроде этого) можно было протолкнуть.
Через PNAT (коих 99%) фокус не пройдет — если только случайно порт не оттранслируется в те же 2222.
Собственно промежуточный хост в STUN в основном и нужен для того, чтобы внешние порты друг друга сторонам сообщить, IP и через какой-нибудь фокус (вроде этого) можно было протолкнуть.
Спасибо. Обязательно посмотрю внимательно.
Но эта штука точно сможет соединить 2-е машины, и обе за firewall-ом, без промежуточного сервера?
Но эта штука точно сможет соединить 2-е машины, и обе за firewall-ом, без промежуточного сервера?
Прочитайте внимательно описание на указанном сайте.
Надо запускать две копии pwnat — в каждой сетке одну — одну как сервер, другую как клиент.
У меня нет кармы даже для того, чтобы вывешивать URL, так что переведу своими словами принцип действия:
1) Запускаем на машине в сетке А сервер — он будет просто слушать (не секьюрно — он будет слушать всех! — о безопасности заботьтесь сами).
2) Запускаем клиента в сетке B.
Что происходит?
— когда сервер запускается, он начинает отправку фиксированных ICMP «эхо
Запрос» пакетов на фиксированный адрес 3.3.3.3. Мы ожидаем, что эти пакеты
не будут возвращены.
— Теперь 3.3.3.3 НЕ есть тот хост, с которым мы хотим связаться! Но мы его ЗНАЕМ!
— Когда клиент хочет подключиться — он послылает ICMP «Время истекло» пакет якобы с информацией 3.3.3.3 от своего IP.
на адрес роутера сети А
И они попадают серверу в сети А, как якобы ответы на отлуп от 3.3.3.3! Но с дополнительным полезным содержимым (а именно IP адресом клиента и клиентской сети) внутри.
Таким образом, сервер получил IP клиента и его сетки.
Далее
3) Cервер начинает бомбить IP роутера клиента UDP пакетами, скажем, на порт 2222. Его роутер сети А замечает это и открывает обратный маршрут для ответов на этот же порт. Что нам и нужно.
Таким образом, мы получили двусторонний канал UDP пакетов, в который далее можно упихать что угодно — TCP сессии и т.д.
Дублирую источник информации — http: // samy.pl / pwnat /
Надо запускать две копии pwnat — в каждой сетке одну — одну как сервер, другую как клиент.
У меня нет кармы даже для того, чтобы вывешивать URL, так что переведу своими словами принцип действия:
1) Запускаем на машине в сетке А сервер — он будет просто слушать (не секьюрно — он будет слушать всех! — о безопасности заботьтесь сами).
2) Запускаем клиента в сетке B.
Что происходит?
— когда сервер запускается, он начинает отправку фиксированных ICMP «эхо
Запрос» пакетов на фиксированный адрес 3.3.3.3. Мы ожидаем, что эти пакеты
не будут возвращены.
— Теперь 3.3.3.3 НЕ есть тот хост, с которым мы хотим связаться! Но мы его ЗНАЕМ!
— Когда клиент хочет подключиться — он послылает ICMP «Время истекло» пакет якобы с информацией 3.3.3.3 от своего IP.
на адрес роутера сети А
И они попадают серверу в сети А, как якобы ответы на отлуп от 3.3.3.3! Но с дополнительным полезным содержимым (а именно IP адресом клиента и клиентской сети) внутри.
Таким образом, сервер получил IP клиента и его сетки.
Далее
3) Cервер начинает бомбить IP роутера клиента UDP пакетами, скажем, на порт 2222. Его роутер сети А замечает это и открывает обратный маршрут для ответов на этот же порт. Что нам и нужно.
Таким образом, мы получили двусторонний канал UDP пакетов, в который далее можно упихать что угодно — TCP сессии и т.д.
Дублирую источник информации — http: // samy.pl / pwnat /
Буквально 20 минут назад решал эту задачу, как попасть на свой собственный же сервер, который стоит на работе и доступ к которому имеют только другие сервера, которые стоят на работе.
Пришлось через сервер клиента зайти и уже через него на маршрутизаторе разрешить вход для себя с удалённого компьютера. Задача проста, но заставлять подумать.
Пришлось через сервер клиента зайти и уже через него на маршрутизаторе разрешить вход для себя с удалённого компьютера. Задача проста, но заставлять подумать.
для простоты все машины работают под Linux.Ну в таком случае даже VDS не нужен, да и без скриптов в кроне вполне можно обойтись.
Прибить к домашней машине домен с dyndns не составляет никаких трудностей (не все же берут статику), так что подцепиться можно напрямую к дому. А чтобы при разрыве соединение само восстанавливалось, коннектимся не с помощью ssh, а autossh, который вешаем в screen/tmux. При желании можно даже в автозагрузку кинуть.
openvpn (который умеет работать через прокси, поддерживающие метод connect) + realip на удалённом сервере рулит =)
а ещё есть несколько техник типа icmp/dns-тоннелей xgu.ru/wiki/Firewall_Piercing
через ssh всё таки изврат обратный коннект делать, но тоже идея. идея главная в том, что не висит постоянного коннекта.
с точки зрения обезопашивания себя от корпоративных безопасников — это тру.
а ещё есть несколько техник типа icmp/dns-тоннелей xgu.ru/wiki/Firewall_Piercing
через ssh всё таки изврат обратный коннект делать, но тоже идея. идея главная в том, что не висит постоянного коннекта.
с точки зрения обезопашивания себя от корпоративных безопасников — это тру.
Объясните мне, молодому и неопытному, почему использование Logmein — это плохо и атата (еще причины, кроме наличия третьей стороны). Мне правда интересно.
Однозначного ответа нет. Каждый для себя решает сам. Даже в этом топике есть люди, которые «лучше спят» — если поверх поднят еще и VPN. Все зависит от конкретных обстоятельств и конкретных требований.
Посмотри с точки зрения сисадмина сети. Приходит сотрудник, и начинает на комп ставить всякие программы, которые «дырявят» его систему обороны… Какова будет его реакция? «Запрещено корпоративной политикой!».
Посмотри с точки зрения пользователя. Для того, чтобы установить удаленный стол тебе надо, как минимум, доказать своему сисадмину, что это действительно необходимо. И опять же «запрещено корпоративной политикой».
Но самым главным недостатком подобных программ является их закрытость. Серверную часть тебе все равно прийдется поставить, и что там внутри, знает только разработчик. А чем больше ответственность — тем больше должна быть паранойя. Тогда лучше спится. :)
Вывод такой: если по быстрому соседу поправить антивирус, то logmein — то, что надо! Если серьезно, и там, где хоть теоретически, возможны какие-либо потери — лучше строить доступ самому, и используя проверенные стандарты и протоколы.
Кстати. В описанном способе действительно есть большая дыра. Это момент подключения к VDS серверу клиентом. Здесь вас фактически защищает только пароль VNC протокола. А он, в силу спецификации, — ну очень несекьюрный.
Посмотри с точки зрения сисадмина сети. Приходит сотрудник, и начинает на комп ставить всякие программы, которые «дырявят» его систему обороны… Какова будет его реакция? «Запрещено корпоративной политикой!».
Посмотри с точки зрения пользователя. Для того, чтобы установить удаленный стол тебе надо, как минимум, доказать своему сисадмину, что это действительно необходимо. И опять же «запрещено корпоративной политикой».
Но самым главным недостатком подобных программ является их закрытость. Серверную часть тебе все равно прийдется поставить, и что там внутри, знает только разработчик. А чем больше ответственность — тем больше должна быть паранойя. Тогда лучше спится. :)
Вывод такой: если по быстрому соседу поправить антивирус, то logmein — то, что надо! Если серьезно, и там, где хоть теоретически, возможны какие-либо потери — лучше строить доступ самому, и используя проверенные стандарты и протоколы.
Кстати. В описанном способе действительно есть большая дыра. Это момент подключения к VDS серверу клиентом. Здесь вас фактически защищает только пароль VNC протокола. А он, в силу спецификации, — ну очень несекьюрный.
Я не слишком в теме (правда, пробовал и Logmein и TeamViewer) но есть мнение, что VNC довольно неоптимально (в сравнении с последними) передает изменения с экрана.
>Итак, договоримся, что для простоты все машины работают под Linux.
Хм… и в чем же простота?
Хм… и в чем же простота?
Sign up to leave a comment.
Еще раз о пробросе портов из-за firewall-a