Прокси вместо VPN.
Рассматриваю вариант использования HTTPS-прокси на входном гейтевее для доступа к ресурсам локальной сети вместо VPN.
В принципе, все протоколы кроме HTTP(S) и ssh нужны при доступе к офисным машинам крайне редко. При условии что IMAP-сервер, SMTP-сервер и сервер видеоконференций торчат наружу и для доступа к ним VPN все равно не используется.
Ну да, раз в сто лет мне надо бывает на консоль какой-нибудь виртуалки сходдить. По RDP или spice (ксрати почти все qemu у меня все равно spice только на localhost слушают, так что без проброса порта по SSH не обойтись все равно).
Как пробросить все что угодно через SSH все и так знают. А кто не знает, пусть здесь читает.
Рассмотрим противоположный подход - все через https. Допустим, у нас на гейтвее локальной сети стоит http proxy. Ну например nginx или apache с mod_proxy или squid. Естественно с авторизацией. Очевидно, что админы сети могут открыть проксирвоание http-методом CONNECT любых портов, которые сочтут нужным. Хоть 22, хоть 3389. Оно конечно менее надежно чем авторизация по сертификатам или ключам ssh/wireguard, но все-таки приемлемо. (особенно если иметь какой-нибудь автоблэклист, который блочит на пару суток IP-адрес с которого пришло более десяти попыток логина с разными неправильными именами и паролями).
Кстати вот тут есть смысл использовать пароли, отличные от тех, которые использует корпоративный LDAP и с которыми можно логиниться на внтуренние сайты вроде JIRA. Получится два уровня защиты от брут-форса. и их уже должно хватить.
Как ходить на внутренние сайты - понятно. А как ходить на машины?
Ну у SSH есть ProxyCommand и она может делать все что угодно. Естественно, есть куча программ, которые рассчитаны именно на хождение по ssh через корпоративную прокси. Все они создавались в основном для хождения изнутри наружу. Но при правильной настройке прокси для хождения снаружи внутрь их тоже можно использовать.
В man ssh_config приведен пример с использованием netcat. К сожалению, netcat обладает большихм недостатком - она не умеет пароль получать откуда-нибудь из файла или там агента. А работать с ssh и при каждом коннекте вводить пароль руками - ну крайне неудобно (опять же будешь ошибаться. и тебя заблеклистят как описано выше)
В дистрибутиве нашлись сходу следующие вариатны
Из них всех https умеет только proxytunnel. Полезным свойством http прокси является то, что имена хостов резолвятся на той стороне. Недостатком этого является то что CanonicalizeHostname в .ssh/config работать не будет, а оно удобное и сильно сокращает размеры этого конфига.
xfreerdp судя по документации умеет http proxy из коробки. Вот умеет ли он https? Не пробовал. Надо что-ли где-нибудь настроить и попробовать. Хотя через proxytunnel можно пустить любую софтину, оно умеет работать в режиме standalone server, аналогично ssh port forwarding.
Утверждается что формат файлла паролей у proxytunnel совпадает с .wgetrc. Хоя я бы, конечно предпочел .netrc Ну или работу с сессионным keyring (gnome-keyring, kwallet, windows credential locker). Написать что ли свой? На питоне. Поскольку и netrc у питона в стандартной библиотеке, а keyring - на pypi. можно, наверное в полсотни строк уложиться, даже без aio, на банальном select.
X-Post from DW
Ну да, раз в сто лет мне надо бывает на консоль какой-нибудь виртуалки сходдить. По RDP или spice (ксрати почти все qemu у меня все равно spice только на localhost слушают, так что без проброса порта по SSH не обойтись все равно).
Как пробросить все что угодно через SSH все и так знают. А кто не знает, пусть здесь читает.
Рассмотрим противоположный подход - все через https. Допустим, у нас на гейтвее локальной сети стоит http proxy. Ну например nginx или apache с mod_proxy или squid. Естественно с авторизацией. Очевидно, что админы сети могут открыть проксирвоание http-методом CONNECT любых портов, которые сочтут нужным. Хоть 22, хоть 3389. Оно конечно менее надежно чем авторизация по сертификатам или ключам ssh/wireguard, но все-таки приемлемо. (особенно если иметь какой-нибудь автоблэклист, который блочит на пару суток IP-адрес с которого пришло более десяти попыток логина с разными неправильными именами и паролями).
Кстати вот тут есть смысл использовать пароли, отличные от тех, которые использует корпоративный LDAP и с которыми можно логиниться на внтуренние сайты вроде JIRA. Получится два уровня защиты от брут-форса. и их уже должно хватить.
Как ходить на внутренние сайты - понятно. А как ходить на машины?
Ну у SSH есть ProxyCommand и она может делать все что угодно. Естественно, есть куча программ, которые рассчитаны именно на хождение по ssh через корпоративную прокси. Все они создавались в основном для хождения изнутри наружу. Но при правильной настройке прокси для хождения снаружи внутрь их тоже можно использовать.
В man ssh_config приведен пример с использованием netcat. К сожалению, netcat обладает большихм недостатком - она не умеет пароль получать откуда-нибудь из файла или там агента. А работать с ssh и при каждом коннекте вводить пароль руками - ну крайне неудобно (опять же будешь ошибаться. и тебя заблеклистят как описано выше)
В дистрибутиве нашлись сходу следующие вариатны
Из них всех https умеет только proxytunnel. Полезным свойством http прокси является то, что имена хостов резолвятся на той стороне. Недостатком этого является то что CanonicalizeHostname в .ssh/config работать не будет, а оно удобное и сильно сокращает размеры этого конфига.
xfreerdp судя по документации умеет http proxy из коробки. Вот умеет ли он https? Не пробовал. Надо что-ли где-нибудь настроить и попробовать. Хотя через proxytunnel можно пустить любую софтину, оно умеет работать в режиме standalone server, аналогично ssh port forwarding.
Утверждается что формат файлла паролей у proxytunnel совпадает с .wgetrc. Хоя я бы, конечно предпочел .netrc Ну или работу с сессионным keyring (gnome-keyring, kwallet, windows credential locker). Написать что ли свой? На питоне. Поскольку и netrc у питона в стандартной библиотеке, а keyring - на pypi. можно, наверное в полсотни строк уложиться, даже без aio, на банальном select.
X-Post from DW