Как сделать объединение двух сетей, две сети со своим белым IP?

Question

[praiden]

Как сделать проброс ipv4 в другую сеть?
у vds есть 4 внешних IPV4, эти 4 внешних IPV4 надо прокинуть в другую сеть которая имеет свой 1 внешний IPV4.
Куда рыть? какие мануалы читать?(если жалко подсказать какие команды вводить)

Comments

[praiden]

2utm, у меня GRE tunnel рабочий так что не думаю что vpn tunnel обязателен

Answer 1

[Drno]

Включаешьnat на впс
С помощью iptables прокидывангь с нужного ип нужный порт на другую сеть

Comments

[praiden]

в другой сети всего-лишь один внешний IPV4 там запущена виртуальная машина, как в нее пробросить IPV4 которая приходит из vds?

[Alexey Dmitriev]

praiden, вам же ответили. Нужно использовать технологию NAT и в частности DNAT. Например организовать VPN отсюда "там запущена виртуальная машина" сюда "vds есть 4 внешних IPV4" и транслировать нужные вам адреса по всем или нужным портам.

[Drno]

praiden, у этой задачи есть несколько вариантов решений. Например
использовать reverse proxy - nginx \ haproxy
объединить сети посредством ВПН и делать проброс порта внутри ВПН сети
просто заюзать NAT на ВПС и пробросить нужный порт.

исходя из того что на клиенте есть внешний IP, я бы делал так -
пробрасываем порт

sudo iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 8080 -j DNAT --to-destination 192.168.0.2:80

где 1.2.3.4 - IP VPS
192.168.0.2 - IP клиента (да, он может быть и внешним)
включаем NAT для интернет интерфейса VPS(т.к. я не знаю как настроена сеть на VPS включаю NAT для ВСЕГО интерфейса)

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

где eth0 - интерфейс инета на VPS
включаем и применяем NAT в ядре системы(предполагаю что у Вас убунту \ дебиан)

sudo echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf
sudo sysctl -p

На клиенте делаем проброс нужного порта на нужный локальный адрес.
ну и вешаем сервисы на разные порты, тогда на 1 внешний IP ты сможешь прокинуть 100500 разных сервисов таким образом

[Drno]

praiden,
исходя из того что ты зачем то задаешь новый вопрос, вместо уточнения в этом - ты можешь указать хоть ВСЕ порты и он их прокинет

но раз у тебя куча виртуалок к которым надо цеплять эти адреса - тогода делать надо это внутри ВПНа

на ВПС ставишь опенВПН
на каждой виртуалке ставишь клента опенВПН и подключаешься к серверу

далее прокидывашь нужные порты как я выше уже указал. можно не указывать порты - тогда ВСЕ запросы будут проброшены
не забываем включить NAT и для VPN интерфейса на VPS

sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

таким образом всё что придет на внешний IP VPS - прокинется на указанный адрес в правиле

[praiden]

Drno, твой вариант с openvpn не катит, виртуальной машиной не я один пользуюсь, так же клиент может снести случайно ее и ему что по новому настраивать openvpn? да он тупо уйдет от такого хостинга лучше, так что надо сделать чтобы не приходилось что то в виртуальной машине что то крутить каждый раз при переустановке.

[Drno]

praiden, хостинги дома не делаются.
У тебя есть вариант поставить клиент опенвпн на хост машину. Но тогда пробросить можно будет только ограниченное количество портов

[Drno]

praiden, upd
Я кстати не совсем прав. Если назначить нескольно ип на клиента опенвпн, или неск раз плдключиться с разными логинами, тогда можно прокидывать порты 1к1
Vps>>опенвпн на хосте>> виртуалка

[shurshur]

praiden, можно анонсировать arp этого IP на серваке хостера (чтобы хостер присылал пакеты этого IP, несмотря на его отсутствие на виртуалке), но IP выдать другому серваку, а у хостера сделать статический роутинг до этого IP через VPN. Ещё потребуется source routing на другом серваке. В общем, очень много телодвижений, которые лучше делать достаточно опытному специалисту, чтобы не сломать всё вообще полностью и не страдать с множеством каких-нибудь странных глюков. В реальности намного проще и надёжнее и быстрее у хостера поднимать прокси и прокидывать всё что надо.

[praiden]

shurshur, виртуалки работают в сети домашнего провайдера а домашний провайдера не продают доп ipv4, поэтому такой огород городить придётся чтобы был доступ к виртуалкам через IP адреса vds

[shurshur]

praiden, это неважно.

Например, у хостера IP 11.12.13.* (внешние), делаем у хостера 11.12.13.2, а ещё три адреса .3,.4,.5 лишь анонсируем в arp во внешний интерфейс. Хостер начинает думать, что IP на нашем хосте, и шлёт трафик на них на наш порт. Но у нас vpn с адресами 10.0.0.1 и 10.0.0.2, мы делаем статические роуты до 11.12.13.{3,4,5} через 10.0.0.2. Сами адреса поднимаем на домашнем серваке хоть на интерфейсе loopback.

Это реально работает, я так делал. Но есть всякие тонкости и нюансы. И чаще всего нет никакого смысла, проще и надёжнее прокинуть конкретный порт через прокси.

[praiden]

shurshur, у vds один внешний IPV4, получается у vds должно быть 2 минимум внешних IPV4 для данного фокуса?
"arp" у домашней машины включать или на vds?
"Proxy ARP" у домашней машины включать или на vds?
Прокси не подходит т.к прокси подменяет src ip, тем самым на сервере у игроков IP ставится от прокси тем самым у всех игроков на сервере"10.0.0.1".

[shurshur]

praiden, насколько я понял предыдущую переписку, у неё 4 IP. Если это не так, то, конечно, такой финт ушами не прокатит.

Можно сделать nat но придётся делать policy routing, чтобы ответные пакеты с конечного сервера летели в VPN. Либо, как вариант, этому серверу весь трафик наружу завернуть в VPN.

[Drno]

shurshur, да. 4 на впс и 1 дома на сервере.
Хз че они воду мутят - достаточно впн построить , дать 4 впн адреса клиенту(хосту с виртуалками) и просто переадресовать весь трафф по этим ip

[praiden]

Drno, не подходит мне VPN tunnel, потому что я не хочу после переустановки виртуальной машины снова на виртуальную машину ставить VPN.

[praiden]

shurshur, так два белых внешних IPV4 не подходит? с чего ты взял что надо 4 IPV4?

[Drno]

praiden, ненадо ставить впн на виртуалку. Поставь на хост.
И переадресуй vps>>хост>>виртуалка

По другому ты всеравно не сделаешь

[praiden]

Drno, Для этого вирт машина должна работать с сетью "сетевой мост"?
vpn wireguard не подходит для этого?
чем gre tunnel(либо другие туннели) не угодил?
предлагаешь делать через iptables проброс при помощи DNAT или SNAT?

[shurshur]

praiden, я ничего не взял, 4 IP упоминались в вопросе и переписке.

[praiden]

shurshur, поэтому ты написал что надо 4 IP а на самом деле надо 2 похоже?

[shurshur]

praiden, откуда я знаю сколько тебе нужно?

Я так понимаю у тебя какой-то игровой сервер, который слишком тяжёлый, чтобы его ставить у хостера, но дома нет внешнего IP? Тогда достаточно одного IP, реально. Пробросить нужный порт или несколько через VPN, на стороне домашнего сервера или (сложный вариант) сделать policy routing для посылки ответных пакетов через VPN, или (гораздо проще) весь трафик с этого сервера завернуть в VPN (но потребуется не забыть отдельный статический маршрут до внешнего сервера, чтобы VPN работал). Второй вариант может быть плох, если по какой-то причине трафик не нужно пускать через VPN. Например, если дома свой собственный интернет ходит через этот же сервер.

В общем, если будет больше подробностей задачи, то будет и больше целенаправленных советов.

[praiden]

shurshur, да игровые сервера у меня дома а что?
надо пробросить IP адреса в домашнюю сеть, чтобы по этим IP адресам попадали в домашнюю сеть а не в сеть vds.

[shurshur]

praiden, ну вот предлагаю по порядку обсуждать.

Игровые сервера могут работать на разных портах одного IP? Если да, то можно их на одном IP навесить на разные порты.

Дома обычный интернет работает через этот сервер или сервер "параллелен" остальным пользователям (например, всё ходит через роутер)?

На сервере винда, Linux или ещё что-то (BSD, Solaris, Android... да, конечно, вряд ли, но уточнить надо)?

Будет ли нормально, если весь исходящий трафик с сервера будет ходить через vds?

[praiden]

shurshur, Да игровые сервера могут работать на разных портах на том же IP.
Ведущий кабель подключен в роутер в слот wan, игровой сервер работает на компьютере, компьютер подключен к роутеру в слот lan.
Игровой сервер запущен на debian 11 / на vds тоже установлен debian 11.
Будет ли нормально, если весь исходящий трафик с сервера будет ходить через vds? - да нормально будет.

[Drno]

praiden, для этого сеть должна быть NAT либо отдельная. Мост не подойдет.
Впн можно использовать любой, просто опенвпн годами проверен и настраивать удобно.

Хоть dnat хоть snat - без разницы
Я обычно использую dnat

[shurshur]

praiden, тогда на домашнем сервере поднимаем VPN. Делаем статический роут мимо VPN до внешнего сервера, чтобы при поднятии VPN он не начинал пускать трафик VPN внутрь VPN:

ip route add IP_ВНЕШНЕГО_СЕРВЕРА via IP_ДОМАШНЕГО_РОУТЕРА

Затем убираем роутинг по умолчанию через домашний роутер и поднимаем через VPN:

ip route del default via IP_ДОМАШНЕГО_РОУТЕРА
ip route add default dev ИНТЕРФЕЙС_VPN
# или так:
#ip route add default via IP_ВНЕШНЕГО_СЕРВЕРА_ВНУТРИ_VPN

После этого весь трафик сервера будет идти в интернет через VPN. Можно с помощью tracepath убедиться.

Это, конечно, работает до перезагрузки или перезапуска VPN. Надо отдельно обеспечить, чтобы всё это поднималось автоматически. В некоторых VPN можно маршруты задавать прям в конфиге. Например, в openvpn есть ключ route конфига, который позволяет это сделать. Можно сделать отдельный скрипт, который всё настраивает, и как-то запускать его при поднятии VPN (например, в openvpn для этого тоже есть специальная инструкция).

После обустройства домашнего сервера перейдём к внешнему.

Там надо настроить SNAT/DNAT через iptables. На входе пакеты на нужные порты должны получать изменение IP получателя, чтобы они летели в VPN (DNAT - Destination NAT), а на выходе сервер должен подменять адрес отправителя на свой, чтобы пакеты летели от имени сервера (SNAT - Source NAT).

# снаружи прилетает пакет - заменяем ему получателя на домашний сервер
iptables -t nat -A PREROUTING -p tcp --dport 12345 -d ВНЕШНИЙ_IP_СЕРВЕРА -j DNAT --to IP_ДОМАШНЕГО_ВНУТРИ_VPN:12345
# от домашнего сервера прилетает пакет - в конце маршрутизации меняем ему IP источника,
# чтобы казалось, что его отправил внешний сервер
iptables -t nat -A POSTROUTING -s IP_ДОМАШНЕГО_ВНУТРИ_VPN -o ВНЕШНИЙ_ИНТЕРФЕЙС_СЕРВЕРА -j SNAT --to ВНЕШНИЙ_IP_СЕРВЕРА

Также надо разрешить форвард пакетов (по умолчанию выключен): в файл /etc/sysctl.conf добавляем

net.ipv4.ip_forward=1

Затем вызываем sysctl -p, чтобы применить без перезагрузки.

Настройки iptables могут быть плохо совместимы с сторонними средствами управления iptables, в частности, с всякими firewalld/ufw, так что их надо будет отключить, ну или адаптировать под них приведённые примеры правил.

[Drno]

shurshur, все это в баш скрипт и в крон при перезагрузке)

[praiden]

shurshur, iptables -t nat -A PREROUTING -p tcp --dport 12345 -d ip vds -j DNAT --to 192.168.168.2:12345
iptables -t nat -A POSTROUTING -s 192.168.168.2 -o ip vds -j SNAT --to ip vds - правильно?

[shurshur]

praiden, в значении параметра -o указывается интерфейс, а не IP. В принципе, в данном случае можно опустить - всё равно в POSTROUTING другой трафик не попадёт...

[praiden]

shurshur, iptables -t nat -A POSTROUTING -s 192.168.168.2 -o ens3 -j SNAT --to ip vds - правильно?

[shurshur]

praiden, да (если ens3 это интерфейс, которым сервак смотрит в интернет).

[praiden]

shurshur,

iptables -t nat -A PREROUTING -p tcp -m tcp -d 91.206.14.207 --d port 12345 -j DNAT --to-destination 192.168.168.10:12345

iptables -t nat -A POSTROUTING -p tcp -m tcp -s 192.168.168.10 --sport port -j SNAT --to-source 91.206.14.207:12345

- правильно ли?

[shurshur]

praiden, да

[praiden]

shurshur, " IP_ДОМАШНЕГО_ВНУТРИ_VPN" указывать IP конечного туннеля или IP начального туннеля?
начальный IP "192.168.168.1"
конечный IP "192.168.168.2"

[shurshur]

praiden, в pointopoint-туннеле два IP-адреса: один адрес одного конца туннеля, другой - другого. Один адрес внешнего сервера, другой домашнего. На такой адрес можно даже по ssh ходить, например, но только с одного сервера на другой.

[praiden]

shurshur,

iptables -t nat -A PREROUTING -p tcp --dport 25565 -d 91.206.14.207 -j DNAT --to 192.168.168.10:25565

iptables -t nat -A POSTROUTING -s 192.168.168.10 -o inet0 -j SNAT --to 91.206.14.207

интерфейс vds:

inet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 2c:f0:5d:04:d6:0d brd ff:ff:ff:ff:ff:ff
    inet 91.206.14.207/24 brd 91.206.14.255 scope global inet0
       valid_lft forever preferred_lft forever
    inet6 fe80::2ef0:5dff:fe04:d60d/64 scope link
       valid_lft forever preferred_lft forever

- правильно ли всё?

[shurshur]

praiden, пока всё выглядит хорошо.

[praiden]

shurshur, не знаешь почему не робит:

sysctl: cannot stat /proc/sys/net/netfilter/nf_conntrack_events_retry_timeout: No such file or directory

sysctl: cannot stat /proc/sys/options nf_conntrack hashsize: No such file or directory

?

[shurshur]

praiden, а зачем эти параметры нужны в текущей задаче?

[praiden]

shurshur, ты про эти параметры спрашиваешь?:

spoiler

net.ipv4.ip_local_port_range = 8192 65535

net.netfilter.nf_conntrack_generic_timeout = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 45
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_checksum=0 
net.netfilter.nf_conntrack_max = 3145728 
options nf_conntrack hashsize=1572864

[shurshur]

praiden, эти параметры были в sysctl.conf по умолчанию? Обычно их менять руками не нужно. Достаточно было ip_forward разрешить.

И в последней строке хрень какая-то, откуда пробелы в имени параметра?

Реально эти параметры соответствуют файлам в /proc/sys.

[praiden]

shurshur, параметры были взяты от сюда

spoiler

https://habr.com/ru/articles/501234/

а что?

[shurshur]

praiden, вряд ли это имеет смысл, если сервер не будет обрабатывать гигантский трафик с безумными требованиями по латенси. Обычная практика такая: открываем файл, находим там закомментированную строчку net.ipv4.ip_foward, раскомментируем и выставляем нужное значение. Что-либо менять без ясного понимания необходимости этого не имеет смысла. Вот если появятся какие-то реальные проблемы, то будет смысл пытаться их порешать.

[praiden]

shurshur, ну как раз проблемы есть, при DDoS атаке сервер зависает/то-есть блоки не ломаются пока атака идёт в течений 30сек, атака на IP "dedicated" исходит от сервиса:

spoiler

"https://mcstorm.is/" - сервис предоставляет бесплатный тариф.

Ответ тп от хостинга:

spoiler

Вероятно, сервер не справляется с нагрузкой.
Наш комплекс базовой защиты от DDoS не фиксирует никаких атак на ваш сервер. И соответственно, ничего не блокирует.

В целом, можно видеть, что трафик на этот сервер не превышает 30 Мбит/с (25kpps), подобные значения не похожи на DDoS-атаку, которая может влиять на работу сервера.

На примере out.log — тут TCP пакеты (в основном), общий объем – 856 пакетов за 7 секунд. Ничего подозрительного, объем минимальный.

Рекомендуем смотреть на потребление ресурсов на самом сервере (потребление памяти, загрузка CPU и т.д.).

В работе сетевой инфраструктуры проблем не наблюдаем.

[shurshur]

praiden, решать эти проблемы лучше отдельно от настройки прокидывания доступа. Можно даже отдельный вопрос завести тут, если будут сложности.

[Drno]

praiden, так тебе ж хостинг ясно ответил что ддоса нет.
Ты уверен что у тебя оперативки хватает?

[praiden]

Drno, ram целых 32gb + (2 × 480 GB SSD SATA)

[Drno]

praiden, включи htop и посмотри. В момент этого лага. Забивается память или нет

[praiden]

Drno, ram вообще не забивается почему хз, ну забьет макс на +50mb ram после атаки.

[praiden]

Drno, вбил значения такие в /etc/sysctl.conf:

net.netfilter.nf_conntrack_generic_timeout=60
net.netfilter.nf_conntrack_icmp_timeout=10
#net.netfilter.nf_conntrack_tcp_timeout_close=10
net.netfilter.nf_conntrack_tcp_timeout_close_wait=20
net.netfilter.nf_conntrack_tcp_timeout_established=600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait=30
#net.netfilter.nf_conntrack_tcp_timeout_last_ack=30
#net.netfilter.nf_conntrack_tcp_timeout_max_retrans=300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv=30
net.netfilter.nf_conntrack_tcp_timeout_syn_sent=60
net.netfilter.nf_conntrack_tcp_timeout_time_wait=60
#net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=300
#net.netfilter.nf_conntrack_udp_timeout=30
net.netfilter.nf_conntrack_udp_timeout_stream=60
net.netfilter.nf_conntrack_max = 544145728 
дальше прописал:	
echo "155524608" > /sys/module/nf_conntrack/parameters/hashsize
- теперь после атаки ram забилась до " 1.3G-1.8G"

[Drno]

praiden, ну забилась рам - это пофиг, если её хватает. лаги пропали? или нет?
обычно для ускорения VPN подключений на сервере, множественных, используют bbr "патч" от гугла
если есть поддержка я ядре

echo net.core.default_qdisc = fq >> /etc/sysctl.conf
echo net.ipv4.tcp_congestion_control = bbr >> /etc/sysctl.conf

[praiden]

Drno, вбил это:

echo net.core.default_qdisc = fq >> /etc/sysctl.conf
echo net.ipv4.tcp_congestion_control = bbr >> /etc/sysctl.conf

дальше прописал sysctl -p - вроде включились эти опции.
у меня GRE tunnel используется я бы хотел под GRE tunnel заточку бы.