Debian.pro

Блог для пользователей и администраторов Debian


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

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

Поговорим про ещё один прекрасный способ завернуть весь трафик с вашего ноутбучка через ssh. В стандартном openssh-сервере/клиенте есть возможность создавать связанные между собой tun-устройства в Linux-ах. Ну вроде тех, которые создаются в openvpn/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 внутри туннеля — то зашифрован) — но это актуально для любых VPN.
И да — мы сделали всё настолько криво, что при падении ssh-коннекта, трафик вообще ходить не будет. Что и хорошо — не прольётся лишнее в DPI.
По скорости — на разгруженных CPU на обоих концах туннеля — 50 mbps.


Комментариев пока нет.

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