Прокинуть в машину внешний IP-адрес с VPS-ки

Вот так: GRE tunnel/IP-in-IP tunnel (комментарий).

Вместо PPTP можешь использовать WireGuard.

Нет, ну маскарад+DNAT я допустим и сам написать могу. Интересно, можно ли как-то красивее (можно ли вообще без лишнего stateful NAT на машине с внешним концом туннеля?) + тема split routing вообще не раскрыта.

Тоже не совсем понял. Передний НАТ пробиваешь каким-нибудь туннелем, ip прокидываешь в него DNATом. Локальным трафиком рулишь как пожелаешь, тут только ты можешь задаться целью исходя из своих хотелок. Никаких глубин lartc тут не требуется же.

Да у меня весь вопрос про «придумайте за меня, чего я хочу, и расскажите мне же». Башка совсем не варит, а сделать надо. Вся суть же именно в управлении локальным трафиком.

Типа, хотелка номер раз: отсутствие stateful NAT на внешнем конце туннеля (так вообще можно? хочу, чтобы порты маппились 1:1, но при этом оставить какую-нибудь дырку для management-трафика).

Хотелка номер два: хочу, чтобы часть исходящего трафика (определённые приложения) уходила через туннель, а оставшееся — напрямую. Или наоборот. А входящие соединения принимать и так, и так.

Хотелка номер три: хочу обойтись без SNAT, чтобы видеть истинные входящие IP.

Хотелка номер четыре: по возможности, хочу сделать это даже не на самой машине, а вообще на роутере с OpenWRT.

хотелка номер раз:

Да, это одно правило iptables -t nat -A PREROUTING -d your_ip -j DNAT –to-destination your_vpn_ip. Ну, для менеджмент-трафика оставь 22 порт для ssh.

Хотелка номер два

Тут pbr, определяешь что такое «приложение», на основе этого расставляешь fwmark и пргокидываешь в нужную таблицу маршрутизации.

Хотелка номер три

Оно само-собой так и будет. Каким боком SNAT к входящему трафику? О_о

Хотелка номер четыре

Очень сомнительно, что OpenWRT все это не умеет.

Оно само-собой так и будет. Каким боком SNAT к входящему трафику? О_о

На первый взгляд кажется, что в противном случае ответные пакеты пойдут другим путём, потому что default-то смотрит не в туннель, а в локальный шлюз. Обычно против этого советуют тупо хреначить SNAT, чтобы у пакетов был IP шлюза на другом конце туннеля, но я так не хочу.

Не, пакеты уйдут туда откуда пришли. Иначе интернеты вообще б не работали )))

А при чём тут интернеты? Если это и работает так, как ты говоришь, то это что-то через conntrack, но кажется, что в больших интернетах conntrack вообще не используется, потому что такое ни одна железка не вывезет априори.

А, понял. Ты хочешь сохранить ip адрес входящий до локальной машины? Нетривиальная задача, тут да, надо лезть в lartc как-то хитро матчить входящие пакеты с интерфейсами.

UPD. Ну или на локальной машине поднять второй интерфейс, DNAT на него и ответ через pbr в тоннель. Дефолт оставить, естественно через основной. Вобщем, мудрить по разделению трафика.

Ты можешь схему нарисовать, того, что ты хочешь?

Anoxemian - телепат!

тупо хреначить SNAT

Либо маскарад.

Здесь без DNAT никак. Делаешь туннель каким-нибудь wireguard'ом, потом DNAT'ишь необходимые порты, роутинг здесь вообще ни при чём, и ни чем тебе не поможет.

С DNAT всё понятно. Фишка в том, что 1) хотелось бы обойтись без SNAT, 2) уметь открывать исходящие соединения по выбору и в туннель, и напрямую и 3) в идеале вообще сделать это не на самой машине, а на рядом стоящем роутере.

Если честно, я не админ и никогда не рисовал схемы сетей, поэтому в душе не представляю, что должно на ней быть и в чём их обычно рисуют (не от руки же).

в чём их обычно рисуют

drawio-desktop.

хотелось бы обойтись без SNAT

Так можно, если твой VPS будет дефолт гейтвеем для хоста за двойным нат.

уметь открывать исходящие соединения по выбору и в туннель, и напрямую

А вот тут нужен policy based routing

в идеале вообще сделать это не на самой машине, а на рядом стоящем роутере.

Тогда и VPN должен быть на роутере, и роутинг там.

Создаёшь несколько таблиц маршрутизации, с разными шлюзами в каждой. В зависимости от критериев помещаешь пакет в нужную таблицу. Можно в iptables маркировать пакеты, а затем принимать рещение о маршруте исходя из метки.

drawio-desktop.

Эээ…

yEd!

А почему нельзя на VPS сделать vpn сервер, из локальной сети к нему подключиться и указать что локальная сеть за адресом выданным клиенту vpn?

Я через ssh делал. Просто в цикле запускал. Он соединения форвардил. Ну через системд можно с рестартом. Минимум телодвижений.

Потому что это в другую сторону.

Молодец. Ты ещё через браузер предложи порты прокидывать.

Честно говоря, не понял. На VPS ставим nginx, при обращении перенаправляем 80 и 443 на нужные внутренние адреса, для остальных портов на VPS делаем «проброс портов» (nat) и обращаемся из дикого интернета к внутренним адресам.

Или у тебя там ещё есть nat, например за ним виртуалки? Так от него надо просто избавиться.

См. самое начало треда. Вешать на VPS второй nginx я не хочу от слова совсем, а DNAT я и сам знаю, как сделать — вопрос не в этом.

Есть, и много. По условию задачи избавляться ни от чего нельзя — надо сделать так, чтобы вся сеть вела себя в точности так, как если бы на роутере был «нормальный» белый IPv4.

А нафига это нужно? Зачем в 23 году публичный ipv4? Есть же tailscale, zerotier и подобное

Потому что это селфхостед сервер публично доступных сервисов.

Как правильнее всего сделать

Вариантов реализаций есть много, рекомендовать тот или иной можно, хорошо понимая твои потребности (и возможности).

Начинается всё с организации тоннеля между VPS и OpenWRT.

Далее, получаются 2 задачи:

• выход локальных ресурсов в интернет
• обеспечение доступа к локальным ресурсам из интернет

Выход в интернет можно обеспечить:

• snat’ом в VPS
• snat’ом в OpenWRT (либо добавить маршрут в VPS до локальной подсети через OpenWRT)
• разруливаним в OpenWRT - что через какой шлюз пойдёт (что через провайдера, что через VPS)
• момент: не забываем про MTU

Доступ к локальным ресурсам можно обеспечить так:

• dnat’ом 1:1 с VPS до OpenWRT (исключая порт для SSH и порт для WireGuard)
• dnat’ом нужных портов с OpenWRT до нужных локальных ресурсов

Создай тоннель с помощью Wireguard. Я с OpenWRT не работал; по идее, там каких-то особых сложностей не должно быть. См. инструкции.

В общем виде это выглядит так:

• генерируешь ключи
• Поднимаешь wg0 на VPS
• Поднимаешь wg0 на OpenWRT
• назначаешь IP-адреса (например, 10.0.0.1/30 — wg0 в VPS, 10.0.0.2/30 — wg0 в OpenWRT).
• Проверяешь сетевую доступность (ping в обе стороны).

Дальше можешь настраивать nat и маршрутизацию.

https://github.com/ValdikSS/nat-traversal-github-actions-openvpn-wireguard

Делал такое на OpenVPN, который уже был в наличии, за оптимальность схемы не ручаюсь. Понадобилось только два правила на VPS

iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 10000:10010 -j DNAT --to-dest 10.8.0.3
iptables -t nat -A POSTROUTING -d 10.8.0.3 -p tcp --dport 10000:10010 -j SNAT --to-source 10.8.0.1

Можно сделать для UDP точно так же.

Интесно, является ли OpenVPN адекватным выбором, если нужно минимальное латенси.

Как правильнее всего сделать так, чтобы на машину можно было достучаться снаружи по этим адресам?

DNAT на нужный адрес на VPS настроить. Ну, это самое банальное.

Если до самой машины доступ нужен с VPS(там будут DNAT-правила на какие-то определенные порты например или вообще будет отдельный белый IP смаплен один-к-одному), тогда всё просто(это всё на машине за NAT-ами):

# ip rule
0:      from all lookup local
1000:   iif eth0 lookup prov
2000:   iif tun0 lookup vps
32766:  from all lookup main
32767:  from all lookup default

# ip route show table prov
default via your_provider_gateway dev eth0

# ip route show table vps
default dev tun0

где eth0 - интерфейс к провайдеру, tun0 - туннельный интерфейс до твоей VPS-ки (туннельный протокол выбирай по вкусу).

В таблице main ничего трогать не надо, там маршрут по умолчанию должен через провайдера идти.

Правила с -j MASQUERADE на eth0 и tun0 - само собой нужны.

rp_filter скорее всего придется выключить, учти это.

-----------------------------------------------------------

Самое потное начинается если тебе надо форвардить с этой машины за NAT-ом трафик куда-то дальше(например она шлюз для еще одной локальной сети и туда что-то пробрасывается через DNAT-правила). Тут придется долго и вдумчиво приседать с CONNMARK-ами(--set-mark, --restore-mark, вот этой вот всё).

1000: iif eth0 lookup prov
2000: iif tun0 lookup vps

Можно тебя попросить чуть подробнее пояснить, как это работает и почему это работает? ip-rule(8) прочитал — понятнее не стало. (Что за «incoming device»? Какое отношение «incoming device» имеет к исходящим пакетам, ну если это не форвард, конечно?)

rp_filter скорее всего придется выключить, учти это.

Спасибо за напоминание, учту.

Самое потное начинается если тебе надо форвардить с этой машины за NAT-ом трафик куда-то дальше(например она шлюз для еще одной локальной сети и туда что-то пробрасывается через DNAT-правила

Да, всё так :) Я очень хочу всё-таки в конечном итоге сделать туннель не до самой машины, а до моего же роутера (который уже за провайдерским NAT’ом), поскольку «сама машина» ­это на самом деле не одна машина, а пачка ВМ-ок в бридже.

хочешь впс юзать для чего? ради чего ты задумал это?

чтобы до роутера был туннель нужно чтобы роутер поддерживал wireguard sever \ wireguard client(то-есть была в нем утилита wireguard) после тянешь туннель от vps к роутеру, после с vps начинаешь прокидывать порты на ip туннеля, в роутере уже пробрасываешь порты на VirtaulMachines, как-то так(ну это не точно т.к не имел опыта с этим опыта, делал только туннель от vps до самой виртуальной машины через wireguar, через nginx на vps доставлял трафик до виртуальной машины через туннель)

Можно тебя попросить чуть подробнее пояснить, как это работает и почему это работает?

Всё очень просто - в кишках ядра(тут я не спец, точный атрибут не скажу) incoming device считается в том числе и для ответных пакетов(логично же, что в ответных пакетах будет заполняться явно поле для outgoing device, да? ну так вот фича в том, что incoming при этом не сбрасывается)

Да, всё так :) Я очень хочу всё-таки в конечном итоге сделать туннель не до самой машины, а до моего же роутера (который уже за провайдерским NAT’ом), поскольку «сама машина» ­это на самом деле не одна машина, а пачка ВМ-ок в бридже.

Ну тогда запотеть придется изрядно. DNAT на PBR-aware устройствах - это веселье.

Тогда имеет смысл не заморачиваться с iif, а сразу хреначить маркировку пакетов на входе через CONNMARK. И в ip rule уже вставлять правила с fwmark

хочешь впс юзать для чего? ради чего ты задумал это?

Например, для базовой защиты сервера от DoS- и DDoS-атак. Интернет-провайдеры физическим лицам (т. н. домашняя сеть) не предоставляют никакой защиты от DoS-атак, а хостинг-провайдеры VDS её предоставляют. Причём даже самые дешёвые VDS-серверы зачастую неплохо защищены (на уровнях L3-L4 модели OSI) не только от DoS-атак, но и DDoS-атак.

Ну если сайт домашний то почему не поставить CloudFlare? Почему ты решил что нельзя своими усилиями защититься от DoS DDoS atack? Ну знаю что домашний интернет тем плох что его канал легко забить UDP флудом, а насчет решений по типу умных ботов то такие боты ложат сайты даже те что на vds за 2000RUB.

Ну если сайт домашний то почему не поставить CloudFlare?

CloudFlare проксирует только HTTP-трафик, т. е. подходит только для web-сервисов.

Почему ты решил что нельзя своими усилиями защититься от DoS DDoS atack?

Ты ничего не сделаешь, если канал забили ещё до твоей железки. Автоматическая система провайдера отправит твою сеть в null route, чтобы атака не мешала нормальной работе сети провайдера.

Фильтрация трафика от DDoS-атак осуществляется на уровне uplink'а. От твоих танцев вокруг роутера не будет пользы. Ты же не станешь от лавины защищаться сапёрной лопаткой?

ложат

«Вы по процедурному вопросу? А то ложат и ложат».

Не удержался.

HTTPS тоже проксирует, потому что с чего ты взял что порт 443 он не защищает?

редко когда канал забивают кагбы, в основном другие методы атаки так что твой спор не к месту

HTTPS тоже проксирует

HTTPS — частый случай HTTP, т. е. лишь его расширение.

с чего ты взял что порт 443 он не защищает?

Ты уже перестал пить коньяк по утрам?

Кстати, не только 80 и 443 порты. Так, например, проксирование CloudFlare доступно по 8080, 21 и некоторым другим портам.

редко

Что значит «редко» в данном контексте? Статистику можно? Канал домашней сети очень просто забить.

в основном другие методы атаки

1. Какие именно?

2. Забитие канала является не методом атаки, а одной из возможных задач атаки.

причем тут коньяк? ты в себе? и причем тут домашний провайдер и CF? как ты собрался домашний интернет ложить который накрыт CloudFlare? Какая разница какие порты он может проксировать? зачастую 443\80 достаточно от него т.к редко когда нужны еще другие http\https порты.

Например метод: флуд протоколом версий 1.0/1.1 ( распространено у фри стрессеров) Например загнать куча ботов на сайт от чего у сайта вырастет нагрузка на CPU / ram, не обязательно ботам что либо делать на сайте.

причем тут коньяк?

Просвещайся.

причем тут домашний провайдер и CF?

Тебя спросить надо. Это ведь ты рекламировать услуги этой компании стал, когда речь зашла про защиту домашней сети. Вспоминай.

как ты собрался домашний интернет ложить который накрыт CloudFlare?

Способов много.

Какая разница какие порты он может проксировать?

Вот именно. Это ты начал про порты писать. Речь шла не о портах, а о том, что Cloudflare может проксировать только web-трафик.

флуд протоколом версий 1.0/1.1

Не надо так смешить. Предупредил бы хоть. Так и поперхнуться можно.

Кстати, на хецнере можно взять маршрутизируемую подсеть и просто раздавать впн-клиентам айпишки.

по чем там один ipv4 стоит?