- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Гугль не помог, может тут гуру подскажут...
Существует ли в Linux такое понятие, как права доступа на интерфейс?
Конкретная цель:
десктопная машина с CentOS, при запуске стартует OpenVPN-клиент и маршрут по дефолту перестраивается - идёт через недоверенную сеть в туннель. Хотелось бы сделать так, чтобы этим туннелем мог пользоваться только рут и еще один пользователь, а остальные (гости) ходили "штатным" образом (через прокси в той же сети, где сама машина). Права на машину полные, на прокси и внутреннюю сеть - никаких (только сетевые реквизиты).
Никто не подскажет как сделать, чтобы при логине гостя туннель либо падал, либо просто маршруты перестраивались без участия туннеля?
В NetworkManager видел что-то типа "только для этого пользователя", но через него настроить не получилось (не жрёт key на в какую) и его пришлось erase...
Как-то через iptables метить пакеты по uid/gid - и затем делать для них с tc отдельные правила роутинга.
>
при запуске стартует OpenVPN-клиент и
Может просто убрать запуск у остальных юзеров? То есть, чтобы подключение запускалось при логине у нужных пользователей.
Как-то через iptables метить пакеты по uid/gid - и затем делать для них с tc отдельные правила роутинга.
Насколько я понял - это единственное идеологически правильное, но самое сложное решение.
Из беглого чтения манов iptables понятно: можно дропать пакеты от определённого юзера, но как строить маршруты в зависимости от UID - пока даже идеи нет :(
Непонятно главное: если одновременно залогинены оба - какая таблица маршрутизации будет работать? Разве их может быть две одновременно?
Может просто убрать запуск у остальных юзеров? То есть, чтобы подключение запускалось при логине у нужных пользователей.
А он как служба стартует еще до логина.
И, далее, что получится, если залогинен "привелигированный" пользователь, для которого нужен туннель и временно зашёл гость (без выхода предыдущего пользователя). У гостя туннель будет доступен в таком случае?
Или может еще какие варианты есть?
Задачу можно сформулировать еще проще - не пускать в туннель гостей (т.е фактически чтобы они случайно туда не попали). Гости не продвинутые, они максимум потыкают видимые иконки, но глубко никто не полезет (т.е шибко шифроваться смысла нет)
А он как служба стартует еще до логина.
Ну так измените тип запуска :) или правила маршрутизации меняйте при логине нужных пользователей.
У Вас пользователи в систему локально заходят?
Тип запуска менять идеологически неправильно, имхо.
Если с локальными пользователями еще можно как-то разрулить (не без шансов сломать мозг), то как быть с системными? Хотелось бы весь системный фоновой трафик (ntp, обновления и пр.) тоже через туннель гнать...
У Вас пользователи в систему локально заходят?
Да, только локально. Вход по сети перекрыт напрочь.
Тут сейчас пошаманил с iptables, правило
даёт результат: перекрывает кислород пользователю user напрочь. Добавить туда адрес vpn-сервера тоже не вопрос, ес-но.
Вот теперь думаю, как будет вести себя система в этом случае... Тут надо глубоко понять идеологию, а с этим тяжко :(
Если я перекрою юзеру доступ к туннелю - установит ли она для него свои маршруты, как были до поднятия туннеля? При том, что в это же время всем остальным пользователям (в т.ч системным) будут доступны туннель и, соответстственно, default gateway совсем другой.
Разве могут существовать две соверешенно разные таблицы маршрутизации одновременно?
Сделайте алиас для сетевого интерфейса и направляйте через него не доверенных пользователей.
🙅
За "левый" айпишник в сети могут вздрючить
Отвечая на вопрос относительно нескольких таблиц — это возможно. Список таблиц указывается в файле /etc/iproute2/rt_tables, но это не особо важно.
Вы можете настроить iptables таким образом, чтобы до интерфейса доходили пакеты только определенных пользователей. Что-то вроде
Точно ведь, чего я парюсь...
Пусть туннель будет поднят постоянно, просто гостям к нему доступ запрещу iptables.
Тем более, что они должны ходить в инет через корпоративную проксю, которую я им в браузере и пропишу заранее. Если и уберут прокси - то вообще ничего не будет работать, как и в штатной винде.
До кучи пойду погуглю, как защитить настройки браузеров от изменения... Хотя, наверное, в линуксах достаточно на их конфиги права 400 поставить...
Вы можете настроить iptables таким образом, чтобы до интерфейса доходили пакеты только определенных пользователей. Что-то вроде
Нет. Даже близко не "вроде". Нужно, чтобы пакеты не просто "доходили" - а доходили именно туда, куда нужно. Для этого правилами iptables не обойтись: нужно на основе маркировки пакетов в подобных правилах - менять роутинг. Примерно как опиали выше #2.
Пусть туннель будет поднят постоянно, просто гостям к нему доступ запрещу iptables.
Тем более, что они должны ходить в инет через корпоративную проксю, которую я им в браузере и пропишу заранее. Если и уберут прокси - то вообще ничего не будет работать, как и в штатной винде.
Если это вариант - то, конечно. Выражайтесь яснее в следующий раз. Чтобы люди не думали, что вам каждому пользователю требуется организовать полноценное соединение с интернет.