Debian.pro/

Про Debian


Извращенные методы туннелирования трафика: часть 2. openssh-клиент и сервер.

Дисклеймер: если вы не умеете администрировать линуксы, не знаете слов «nat», «/sbin/ip», «маска подсети» и «роутинг в Linux» (и их значений, само собой) — то для вас есть статья про sshuttle

Поговорим про ещё один прекрасный способ завернуть весь трафик с вашего ноутбучка через ssh. В стандартном openssh-сервере/клиенте есть возможность создавать связанные между собой tun-устройства в Linux-ах. Ну вроде тех, которые создаются в censored/pptp и прочей гадости. Весь трафик, завернутый через этот туннель будет зашифрован ssh-ем.
Задумываемся на 5 секунд, вспоминаем про NAT и… Заворачиваем весь свой трафик через ssh за несколько минут. Оговорюсь ещё раз — НЕНАДО, БЛЯТЬ, КОПИПАСТИТЬ то, что здесь написано — ничего не заработает. Читайте внимательно пояснения, все команды даны только для примера. Если вы любите копипастить — apt-get install sshuttle; man sshuttle.

Нам понадобится:
1) рут на удаленном сервере
2) рут на локальной машине
3) openssh-server на удаленном сервере, openssh-client на локальной (в принципе openssh-client есть и под винду, и даже умеет туннели, но я не возьмусь описывать, как настроить туннель на винде)
4) благословение на изменения конфигурации на удаленном сервере от его владельца.
5) голова на плечах, минимальные навыки настраивания linux-шлюза, понимание того «как вернуть всё взад».

Погнали. Первым делом разрешим туннели на нашем сервере (в файле /etc/ssh/sshd_config, если у нас debian-based):

PermitTunnel point-to-point

Не забываем перезапустить ssh-сервер.
Теперь коннектимся по ssh на сервер с опцией -w (важно — от рута):

root@laptop:~# ssh -w 14:14 root@remote-server

Циферки 14:14 — это номера tun-устройств, которые будут созданы на клиенте/сервере. Через эти tun-устройства мы потом и пустим зашифрованный трафик.
Теперь поднимаем tun-ы. Само собой, выберите себе незанятую в локалке (или в других сетях) подсеть. Здесь я взял 192.168.0.0/30 для примера. На сервере:

root@server:~# ifconfig tun14 192.168.0.1 netmask 255.255.255.252 up

На локальном тазике:

root@laptop:~# ifconfig tun14 192.168.0.2 netmask 255.255.255.252 up

Теперь с лаптопа попингуйте сервер внутри туннеля. Если получилось — продолжайте, если не получилось — дебажьте, почему туннели не поднялись. И да, RTT в туннеле и мимо него до сервера должен быть примерно одинаковый. Если он сильно меньше ожидаемого — вы сделали херню.

Теперь на сервере нужно поднять NAT. У меня на сервере сетевуха eth2 наружу на сервере смотрит.

root@server:~# iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE

Не забываем про ipv4-forwarding:

root@server:~# echo 1 > /proc/sys/net/ipv4/ip_forward


Теперь самое веселое — разламываем к чертям роутинг у себя на лаптопе. Смотрим, что у нас там понаписано сейчас:

user@laptop:~$ ip ro sh
default via 192.168.3.1 dev wlan3
192.168.0.0/30 dev tun14 proto kernel scope link src 192.168.0.2
192.168.3.0/24 dev wlan3 proto kernel scope link src 192.168.3.15

Трезвым взглядом смотрим на то, что у нас написано в default, и делаем отдельный маршрут до нашего сервера через default-gate (чтобы у нас всё не навернулось, когда мы завернем default в tun-устройство):

root@laptop:~# ip ro add remote_server_ip/32 via 192.168.3.1 dev wlan3

Если у вас немножко плохо с головой и вы используете DNS-резолверы провайдера — то добавьте такой же маршрут и до них (только тогда dns-трафик зашифрован не будет).

Теперь самое вкусное — меняем default-route на тот ip, который мы вешали на tun14 на сервере:

root@laptop:~# ip ro replace default via 192.168.0.1 dev tun14

Всё, теперь трафик у нас ходит зашифрованным через туннель. Ну только учтите, что трафик до самого сервера через его внешний IP не зашифрован (если же ходить на IP внутри туннеля — то зашифрован) — но это актуально для любых censored.
И да — мы сделали всё настолько криво, что при падении ssh-коннекта, трафик вообще ходить не будет. Что и хорошо — не прольётся лишнее в DPI.
По скорости — на разгруженных CPU на обоих концах туннеля — 50 mbps.


Комментарии (1):

  1. nefr :

    Get-WindowsCapability -Online | ? Name -like ‘OpenSSH.Ser*’
    namo : openssh.serever***0.0.1.0
    state: installed

    Set-Service -Name sshd -StartupType ‘Automatic’
    Start-Service sshd
    Для корректной работы «SSH-сервера», нужно добавить разрешающие правила в Windows Defender Firewall
    Авторизуемся под учетными данными нашей виртуальный машины и переходим по пути «Control Panel» -> «System and Security» -> «Windows Defender Firewall»
    Открываем параметр «Windows Defender Firewall» и кликаем по пункту «Advanced Settings»

    Выбираем пункт «Inbound Rules» и создаем новое правило при помощи кнопки «New Rule»
    Выбираем тип правила «Port»
    Указываем протокол «TCP» и порт «2222»
    Разрешаем подключение к выбранному порту «Allow the connection»
    Выбираем тип сетей, где будет доступен протокол
    Называем правило «SSH» и нажимаем кнопку «Finish» для завершения создания правила
    Открываем конфигурацию «SSH-сервера» для редактирования
    изменяем port 2222

    открываем
    start-process notepad C:\Programdata\ssh\sshd_config

    permitRootLogin yes
    PasswordAuthentication yes
    permitEmptyPassword no

    restart-service sshd

    открываем hq-r
    iptables -t nat -A PREROUTING —dst 1.1.1.100 -p tcp —dport 22 -j DNAT —to-destination 192.168.0.60:2222

    ip6tables -t nat -A PREROUTING —dst 1110:a::100 -p tcp —dport 22 -j DNAT —to-destination 192:168:d::6:2222

    dpkg-reconfigure iptables-persistent
    [ Виртуальная машина HQ-SRV ]
    Авторизуемся под учетными данными нашей виртуальный машины и переходим по пути «Control Panel» -> «System and Security» -> «Windows Defender Firewall»
    Открываем параметр «Windows Defender Firewall» и кликаем по пункту «Advanced Settings»
    Выбираем пункт «Inbound Rules» и создаем новое правило при помощи кнопки «New Rule»
    Выбираем тип правила «Custom»
    Выбираем тип «All Programs»
    Выбираем тип протокола «TCP» и указываем локальный порт «2222»
    Указываем IP-адреса, которые будут заблокированы к SSH-сервису
    Запрещаем подключение к выбранному порту «Block the connection
    Называем правило «BlockCLI-SSH» и нажимаем кнопку «Finish» для завершения создания правила

Написать комментарий