Comments 38
Убедитесь в том, что никто кроме вас не получит доступа к агенту, а также что на агенте четко написаны координаты владельца — вы же не хотите подставить чужую сеть под опасность.
Вот этого не понял. Для какой сети появляется опасность — в которой находится агент или сервер? И в чём эта опасность заключается? И вообще что значит «доступ к агенту» в данном контексте?
Вот есть у меня сервер у хетцнера и потенциальный агент дома за провайдерским НАТом. В чём я должен убедиться и какую опасность для чьей сети (хетцнеровской? провайдерской?) представляет реализация такой схемы?
Вот этого не понял. Для какой сети появляется опасность — в которой находится агент или сервер? И в чём эта опасность заключается? И вообще что значит «доступ к агенту» в данном контексте?
Вот есть у меня сервер у хетцнера и потенциальный агент дома за провайдерским НАТом. В чём я должен убедиться и какую опасность для чьей сети (хетцнеровской? провайдерской?) представляет реализация такой схемы?
опасность — это если вы ставите этого агента в чужую локальную сеть, а потом кто-то третий получил доступ к агенту. Получается, что вы прорубили дырку в корпоративной секьюрити, и если что, проблемы будут у вас, а не у злоумышленника
Может это проблема «корпоративной секьюрити», что она не может обеспечить свою безопасность? Что принципиально может сделать третье лицо, чего не могу сделать я, имея полный физический и «логический» доступ к своей машине?
ну всё же предполагается, что вы — не злоумышленник и поставили агента для рабочих надобностей с ведома местного IT :)
к сожалению, в 100% сетей где я проверял, исходящий ssh открыт. Только в одной сети была регистрация всех MAC'ов и автоматический шатдаун портов на свиче, если подсоединился кто-то чужой.
к сожалению, в 100% сетей где я проверял, исходящий ssh открыт. Только в одной сети была регистрация всех MAC'ов и автоматический шатдаун портов на свиче, если подсоединился кто-то чужой.
В моём договоре с провайдером нет требований извещать его о каких либо действиях на своём компе, запрета на проброс портов тоже нет. А блокировку исходящего ssh я бы счёл нарушением сетевой нейтральности и поискал бы другого провайдера. Но регистрация MACов есть у него, да, собственно с незарегистрированным маком ни один байт не отправить и не получить дальше модема.
вообще-то в посте речь о корпоративных сетях в основном :)
Задача: разместить линуксовый компьютер в сети за NATом, и иметь к нему доступ из внешнего мира. Например, вы траблшутите или поддерживаете что-то у клиента, и чтобы не сидеть у него в офисе, нужно быстро соорудить удаленный доступ. Или, например в 3G-сетях клиенты как правило получают приватные адреса, а нам нужен доступ к компьютеру, где другой связи нет.
Ни одного намёка на это не увидел :( Сорри. А задача в точности моя.
Ни одного намёка на это не увидел :( Сорри. А задача в точности моя.
Может проще openvpn поднять?
Согласен, единожды разобраться с openvpn — и все компьютеры за натом доступны — как в локалке.
Воспользуюсь случаем и спрошу — кто как поборол такие неприятные особенности openvpn (при промышленной эксплуатации к этим проблемам нужно отнестись серьёзно):
1. Чтобы запретить доступ клиенту (например сотрудник уволился, но сделал копии user1.crt и user1.key) нужно явно прописать сертификат пользователя в список отозванных.
Т.е. доступ разрешен всем имеющим сертификат (кому явно не запрещен). Нет уверенности, что кто-то не сделал себе «запасной» сертификат.
2. Не ограничивается повторное подключение с одним и тем же сертификатом.
3. Нет привязки сертификат — IP-адрес.
Воспользуюсь случаем и спрошу — кто как поборол такие неприятные особенности openvpn (при промышленной эксплуатации к этим проблемам нужно отнестись серьёзно):
1. Чтобы запретить доступ клиенту (например сотрудник уволился, но сделал копии user1.crt и user1.key) нужно явно прописать сертификат пользователя в список отозванных.
Т.е. доступ разрешен всем имеющим сертификат (кому явно не запрещен). Нет уверенности, что кто-то не сделал себе «запасной» сертификат.
2. Не ограничивается повторное подключение с одним и тем же сертификатом.
3. Нет привязки сертификат — IP-адрес.
Не будет ли забиванием гвоздей микроскопом использование vpn для задачи «получить свободный доступ к одному сервису(порту) на хосте за натом, над которым нет контроля, с произвольного хоста вне его»?
Даже по вашим вопросам видно, что разбираться много с чем нужно и некоторые вещи (ограничение доступа) явно для этой задачи не актуальны.
Даже по вашим вопросам видно, что разбираться много с чем нужно и некоторые вещи (ограничение доступа) явно для этой задачи не актуальны.
п.1 — есть альтернативный вариант, использовать настройку ccd-exclusive, которая требует обязательного наличия файла настроек клиента. В этих настройках можно зашить ip-адрес клиента, тем самым ограничив кол-во одновременных подключений (п.3 и п.2)
Насчет повторного подключения не знаю, не сталкивался, но дополнительно ограничить доступ (помимо отзывных сертификатов) и привязать IP к сертификату можно с помощью client-config-dir.
А в чём принципиальные плюсы? Не нужен хост с глобальным адресом? Не нужно инициировать соединение изнутри НАТа? Или, может, меньше ресурсов потребляет чем ssh?
всё зависит от задач, в моем случае ssh достаточен для всего. я в другой ветке дал пару примеров
В моем представлении в пробросе единичного порта, доступ к которому нужно получать с любых других хостов и без аутентификации (средствами проброса, аутентификация, если вообще нужна, осуществляется средствами приложения порт слушающего) очень мало общего с VPN. Мне нужно чтобы мой хост (вернее хост: порт) стал частью не частной сети, а публичной, частью всего Интернета. Просто способ не покупать глобальный IP у провайдера, а более экономно (прежде всего) и безопасно (практически без снижения удобства) решить проблему доступа к домашнему компу извне и не только для себя.
ну если это ваша домашняя сеть, то dynamic DNS и статический port forwarding решают проблему легко
У меня статический внутренний IP и статический внешний у шлюза (NAT) провайдера. По-моему способ в посте оптимально подходит для того, чтобы, например, получить доступ по ssh к локальной ФС c произвольной машины, или, скажем, показывать по http заказчикам поднятый локально сайт перед помещением на production. Собственно внешний IP нужен только для этих целей.
в моем случае не нужна связь между всеми компьютерами, а нужен быстрый способ поставить линуксовый ящик, где можно запускать tcpdump, snmpwalk, а то и скриптец какой (например, в лабе для тестирования IPTV я сделал скрипт, который присоединяется последовательно к нескольким мультикастным потокам)
openvpn требует больше усилий по настройке, но в целом вы правы, в некоторых случаях он удобнее. В моем случае удобнее ssh
openvpn требует больше усилий по настройке, но в целом вы правы, в некоторых случаях он удобнее. В моем случае удобнее ssh
>> Если агент — ноутбук под убунтой, начиная с убунты 12.04 невозможно отключить засыпание от закрытия крышки…
i45.tinypic.com/308h4kl.png
i45.tinypic.com/308h4kl.png
То есть съездить к клиенту и установить у него оборудование, инициирующее соединение изнутри — это называется «быстро» и «бэкдор»?
Вот и нашлось применение для picotux
за те же деньги можно купить Alix с pcengines.ch — там всё же полноценный компьютер с достаточным количеством памяти, чтобы запустить нормальный дебиан
Да и RaspberryPI подходит.
Я о том, вообще, что из подобных мини-РС можно делать конечные устройства, бэк-доры, и продавать их на каждом углу.
Некий бэг-дор по-быстрому в блистерной упаковке.
Я о том, вообще, что из подобных мини-РС можно делать конечные устройства, бэк-доры, и продавать их на каждом углу.
Некий бэг-дор по-быстрому в блистерной упаковке.
Sign up to leave a comment.
Удаленный доступ к компьютеру за NAT'ом через SSH-туннель