Дисклеймер: если вы не умеете администрировать линуксы, не знаете слов «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):
Не забываем перезапустить ssh-сервер.
Теперь коннектимся по ssh на сервер с опцией -w (важно — от рута):
Циферки 14:14 — это номера tun-устройств, которые будут созданы на клиенте/сервере. Через эти tun-устройства мы потом и пустим зашифрованный трафик.
Теперь поднимаем tun-ы. Само собой, выберите себе незанятую в локалке (или в других сетях) подсеть. Здесь я взял 192.168.0.0/30 для примера. На сервере:
На локальном тазике:
Теперь с лаптопа попингуйте сервер внутри туннеля. Если получилось — продолжайте, если не получилось — дебажьте, почему туннели не поднялись. И да, RTT в туннеле и мимо него до сервера должен быть примерно одинаковый. Если он сильно меньше ожидаемого — вы сделали херню.
Теперь на сервере нужно поднять NAT. У меня на сервере сетевуха eth2 наружу на сервере смотрит.
Не забываем про ipv4-forwarding:
Теперь самое веселое — разламываем к чертям роутинг у себя на лаптопе. Смотрим, что у нас там понаписано сейчас:
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-устройство):
Если у вас немножко плохо с головой и вы используете DNS-резолверы провайдера — то добавьте такой же маршрут и до них (только тогда dns-трафик зашифрован не будет).
Теперь самое вкусное — меняем default-route на тот ip, который мы вешали на tun14 на сервере:
Всё, теперь трафик у нас ходит зашифрованным через туннель. Ну только учтите, что трафик до самого сервера через его внешний IP не зашифрован (если же ходить на IP внутри туннеля — то зашифрован) — но это актуально для любых censored.
И да — мы сделали всё настолько криво, что при падении ssh-коннекта, трафик вообще ходить не будет. Что и хорошо — не прольётся лишнее в DPI.
По скорости — на разгруженных CPU на обоих концах туннеля — 50 mbps.
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» для завершения создания правила