Маршрутизация локальной сети через прозрачный socks-прокси

Потребовалось пустить трафик со всех домашних устройств, включая смартфоны, через ssh tunnel.

Имелось:

  • маршрутизатор TP-LINK, подключенный к провайдеру.
  • смартфоны и ноутбук подключенные к беспроводной точки доступа маршрутизатора.

Ноутбук находился далеко от маршрутизатора (в другой комнате) и регулярно использовался, поэтому пришлось искать решение маршрутизации трафика с помощью встроенного беспроводного интерфейса (и без всяких там eth0).

Инструментарий:

openssh-client — стандартный ssh клиент для linux.
autossh — позволяет проверять соединение с ssh сервером, и подключаться при разрыве.
redsocks — прозрачный socks-прокси сервер.
isc-dhcp-server — dhcp сервер.
iptables — думаю, комментарии излишне.

Итак, приступим. Первым делом поднимем DHCP сервер на беспроводном интерфейсе ноутбука.

Установка:

apt install isc-dhcp-server

Настроим нужный интерфейс:

nano /etc/network/interfaces

# Назначаем статический IP адрес для DHCP сервера на wlan0:
auto wlan0
iface wlan0 inet static
    address 192.168.1.100
    netmask 255.255.255.0
    broadcast 192.168.1.255
    gateway 192.168.1.1

Узнать название необходимого интерфейса можно командой:

ip a

Назначим DNS:

nano /etc/resolv.conf

# Публичные DNS сереверы Google:
nameserver 8.8.8.8
nameserver 8.8.4.4
# (или DNS серверы провайдера)

Далее настроим сам dhcp сервер:

nano /etc/default/isc-dhcp-server

Должен содержать строчку с указанием необходимого интерфейса:

INTERFACESv4="wlan0"

Настройка демона:

nano /etc/dhcp/dhcpd.conf

option domain-name "mydebian";
# Публичные DNS сереверы Google (или DNS серверы провайдера):
option domain-name-servers 8.8.8.8, 8.8.4.4;
# Настройки подсети:
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.101 192.168.1.254;
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.100;
    option domain-name-servers home;
}
default-lease-time 600;
max-lease-time 7200;

Пробежимся по главным параметрам:

option domain-name-servers — адреса DNS серверов, которые получат клиенты при подключении. В случае наличия локального DNS сервера (как у меня), необходимо указать адрес интерфейса 192.168.1.100.

range — диапазон присваиваемых IP адресов.

option routers — этот адрес будет служить шлюзом для клиентов.

Настройка завершена, необходимо перезапустить службу командой:

service isc-dhcp-server restart

Проверить состояние можно командой:

service isc-dhcp-server status


Осталось только настроить маршрутизатор на использование нашего DHCP сервера, а именно, переключить режим DHCP, в настройках LAN на «Relay» и указать там, IP адрес нашего DHCP сервера — 192.168.1.100.

Теперь все устройства, подключающиеся к точке доступа роутера, будут получать сетевые настройки от сетевого интерфейса ноутбука, но сам доступ в интернет необходимо настроить. Напомню, что задача состоит в том, чтобы трафик всех устройств, включая ноутбук заворачивал в ssh-туннель. На мой взгляд ssh туннель разумней запускать в качестве службы, которая будет принимать перенаправления от прокси сервера redsocks.

Установим необходимый инструментарий:

apt install openssh-client autossh 

Если мы хотим иметь постоянный ssh туннель, который активируется при загрузки системы, необходимо создать службу systemd и включить ее. Так как мы будем использовать autossh, нужно заметить, что параметр -f (работа в фоне) включающий в себя параметр AUTOSSH_GATETIME=0, не поддерживается в systemd. Поэтому нужно указать использование параметра AUTOSSH_GATETIME=0 явно. Вот так выглядит базовая конфигурация сервиса:

nano /etc/systemd/system/ssh-tunnel.service

[Unit]
Description=AutoSSH tunnel on dynamic port 1080
After=network.target

[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -o "ServerAliveInterval 30" -o  "ServerAliveCountMax 3" -ND 1080 user@server -p 22

[Install]
WantedBy=multi-user.target

Разберем содержание:

After=network.target — Запуск службы при наличии сетевого подключения.
Environment=«AUTOSSH_GATETIME=0» — указывает systemd работу ssh в фоне.

Отдельно следует рассмотреть параметр ExecStart:

 /usr/bin/autossh -M 0 -o "ServerAliveInterval 30" -o  "ServerAliveCountMax 3" -ND 1080 user@server -p 22 -

Запуск autossh со следующими параметрами:

-M — порт мониторинга. С этим параметром autossh будет непрерывно посылать запросы на сервер через указанные порты, если от сервера не приходит ответ, autossh подключается заново. Указанный порт мониторинга и порт порядком выше (+1) должны быть свободными в системе. Так как это делает такой мониторинг не практичным, мы отключаем эту функцию указывая значение 0.

"- o ServerAliveInterval" и "-o ServerAliveCountMax" — две опции, указывающие ssh клиенту отправлять запросы серверу непосредственно через туннель (то что нам нужно), чтобы поддерживать соединение, когда оно не активно. Также, если от сервера не следует ответа, соединение будет считаться разорванным и autossh подключается заново.

-N — не отправлять команд на сервер.
-D 1080 — открываем динамический порт на localhost.
user@server — здесь следует указать пользователя и адрес(доменное имя) сервера.
-p 22 — указываем порт подключения.

Перезагружаем демон:

systemctl daemon-reload

Запускаем службу:

systemctl start ssh-tunnel

Включаем запуск во время загрузки:

systemctl enable ssh-tunnel

Итак, запущены DCHP сервер на беспроводном интерфейсе ноутбука и стабильный ssh туннель в системе, осталось только завернуть в него трафик со всех устройств в локальной сети. Сделаем это с помощью redsocks и iptables.

Установка:

apt install redsocks

Настройка:

nano /etc/redsocks.conf

Редактируем секцию:

redsocks {
        /* Адрес и порт для входящих соединений */
        local_ip = 0.0.0.0;
        local_port = 12345;

        // Адрес и порт ssh туннеля.
        ip = 127.0.0.1;
        port = 1080;
}

Сохраняем конфиг и перезагружаем службу:

service redsocks restart

Остался, последний трюк с использование iptables. Предлагаю сразу создать скрипт со следующим содержанием:

#!/bin/bash
iptables -t nat -N REDSOCKS # Создается новая цепочка
iptables -t nat -A REDSOCKS -d 192.168.1.1 -j RETURN # Указанные адреса и под-сети, например 192.168.0.0/24, не будут перенаправляться .
iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345 # Перенаправлять все исходящие подключения хоста.
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner user -j REDSOCKS # Перенаправлять исходящие подключения пользователя "user".
iptables -t nat -A PREROUTING --in-interface wlan0 -p tcp -j REDSOCKS # Перенаправлять все входящие соединения с интерфейса wlan0.

Теперь все запросы с локальной сети, включая хост, будут направляться в ssh туннель.
Поделиться публикацией
Ммм, длинные выходные!
Самое время просмотреть заказы на Фрилансим.
Мне повезёт!
Реклама
Комментарии 19
  • 0
    Зачем здесь вообще redsocks?
    Можно же переадресовывать напрямую на 127.0.0.1 на 1080.
    • 0
      Вы правы, можно напрямую.
      • 0

        А с какой версией openssh это заработало?

        • 0
          Честно говоря, не пробовал без redsocks.
      • +2

        Да. И использование sshpass тоже как-то напрягает. Как будто использование авторизации по ключам вдруг кто-то запретил.

        • 0
          Поясните, пожалуйста, что значит переадресовывать напрямую? На порту 1080 фактически висит socks5. Как можно обернуть трафик в socks5 без redsocks?
          • 0

            Задача redsocks — спросить у ядра IP_ORIGDSTADDR и передать его в openssh на этапе установления socks5-соединения. Судя по коду, openssh-7.2p2 из коробки этого делать не умеет. Ну а в 2007-ом точно не умел :-)

          • +2
            Зачем sshpass, если есть ключи?
            • 0
              В моем случае аутентификация по ключам не доступна.
              • 0
                а в каких случаях такое бывает?
                • 0
                  Например, если на сервере — 'PubkeyAuthentication no' и терминал не доступен?
            • +2
              range — ранг раздаваемых IP адресов.

              *facepalm*
              • +1
                Ну, нарисуйте вменяемую, читаемую и однозначную графическую схему…
                • –2

                  Судя по примерам команд, на ноутбуке стоит ubuntu или debian. В ubuntu предустановлен dnsmask, который легко раздаёт ip-адреса.


                  Что там должно гореть зелёным чтобы можно было понять, что оно работает? Я не понял — это оборот речи?


                  И, да, обмен ключами и никакой подстановки паролей не нужно. Допускаю ситуации, когда использовать ключи невозможно, но придумать такую ситуацию не могу. Поясните, пожалуйста.


                  Ещё меня очень смутило использование пользовательского cron. Я вообще не понял сути этого действия.

                  • 0
                    Debian, чем плох isc?
                    Публичный ssh сервер.
                    С помощью cron применяются правила iptables (соглашусь, есть более изящный способ).
                    • 0

                      Ничем не плох. Просто, если уже есть один инструмент, зачем ставить другой? Правда, debian давно не использую, поэтому не знаю предустановлен или нет dnsmasq.
                      А публичный ssh не позволяет подключиться и получить доступ к консоли? Зачем он тогда нужен? ssh-copy-id не получается использовать?
                      Не, с iptables Вы однозначно не правы. :-)

                      • 0
                        Случай частный и возможно, идея не совсем ясна, но это своего рода ssh tunnel, в который заворачивает весь трафик.
                  • –1
                    Зачем autossh, если есть mosh?
                    • 0

                      Зачем здесь ноутбук? Нельзя было туннель на роутере поднять?

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.