Как сделать проброс IPV4 из одной точки в другую точку?(IP forward)

Ты не написал, сколько там каких сетей. А так - сделай всё в одной сети, и мостами (bridge) соедини.

ip r a <ip_vm/mask_vm> via <ip_gre_vds2>
iptables -t raw -A PREROUTING -d <one_of_ips> -j DNAT --to-destination <ip_vm>
iptables -t nat -A POSTROUTING -o gre0 -j SNAT --to-source <gre0_ip>

Ну как-то так, наверно.

две vds не в одной локалке, vds в разных концах света. вводить на второй vds «ip r a <ip_vm/mask_vm> via <ip_gre_vds2> iptables -t raw -A PREROUTING -d <one_of_ips> -j DNAT –to-destination <ip_vm> iptables -t nat -A POSTROUTING -o gre0 -j SNAT –to-source <gre0_ip>»?

там сложная схема, вторая vds имеет свой внешний IP но она не в одной локальной сети с первой vds, надо пробросить внешний IP первой vds во вторую vds но чтобы этот внешний IP попадал в виртуальную машину чтобы к ней можно было подключиться по ssh.

Бро, если ты нихего не понял в написанном, то мой тебе совет: никуда ничего не вводи, найми админа.

гений писать команды но не уточнять к какой vds ты их готовил, давать кусок инфы чтобы что?

представь у тебя провайдер которая не продает доп ipv4, тем самым приходится покупать vds у которой есть дополнительные ipv4, так вот, есть port forward a есть ip forward, нужно сделать Ip forward чтобы домашняя виртуальная машина имел свой внешний IPV4 чтобы извне могли подключиться к ней.

«Не-не, представь, у тебя визави, который нахватался каких-то терминов слов, задает вопрос по форме «В каком году, какой автор написал какую книгу?». Получив ответ, смотрит на него как баран на новые ворота.»

Хотел написать я, но не стал. Потом, так как мне скучно, смотри:

Вопрос:

Здравствуйте, у меня такой расклад, есть две vds, соединенные gre туннелем (зачем, не спрашивайте, я ннп).

VDS1:

:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:02:ef:dc brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 47.36.219.183/24 brd 47.36.219.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet 46.38.219.206/24 brd 46.38.219.255 scope global secondary ens3:0
       valid_lft forever preferred_lft forever
    inet 46.36.220.217/24 brd 46.36.220.255 scope global secondary ens3:1
       valid_lft forever preferred_lft forever
    inet 46.46.220.217/24 brd 46.46.220.255 scope global secondary ens3:2
       valid_lft forever preferred_lft forever
3: gre0: blah blah blah
    inet 10.0.0.1/24 blah blah blah remote 123.123.123.123

:~# ip r s
default via 47.36.219.1 dev ens3 
10.0.0.0/24 dev gre0 scope link 

VDS2:

:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:02:ef:dc brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 123.123.123.123/24 brd 123.123.123.123 scope global ens3
       valid_lft forever preferred_lft forever
3: gre0: blah blah blah
    inet 10.0.0.2/24 blah blah blah remote 47.36.219.183
4: vnet0: blah blah blah blah
    inet 172.16.10.10/24
:~# ip r s
default via 123.123.123.1 dev ens3 
10.0.0.0/24 dev gre0 scope link 
172.16.10.0/24 dev vnet0 scope link

Надо пробросить 46.46.220.217 до 172.16.10.10.

Тогда ответ был бы такой:

VDS1:

ip r a 172.16.10.0/24 via 10.0.0.2 dev gre0
iptables -t nat -A PREROUTING -d 46.46.220.217 -j DNAT --to-destination 172.16.10.10
iptables -t nat -A POSTROUTING -o gre0 -j SNAT --to-source 10.0.0.1

Логика такая: все пакеты, летящие на пробрасываемый ip у vds1 перенаправляем на адрес виртуальной машины через туннель к vds2. Так как виртуальная машина будет отвечать адресу источника, то пакет улетит через шлюз vds2 123.123.123.1, поэтому на vds1 включаем NAT, дабы не потерять трафик. Ну и локальный роутинг до сети виртуальной машины должен работать. Поэтому маршрут на vds1 должен быть фиксирован.

Как-то так. Разве что дополню, что решение топорное. В идеале, на входе к vds1 пакеты метить, а на выходе с vds1 матчить по метке для SNAT. Пусть будет домашним заданием.

нужно сделать Ip forward чтобы домашняя виртуальная машина имел свой внешний IPV4 чтобы извне могли подключиться к ней.

Не обязательно GRE использовать, можно wireguard тоже.

у меня виртуальные машины запущены через virtualbox и имеют сеть «сетевой мост» думаешь wireguard тут подходит в таком случае?

У тебя virtualbox в качестве серверной платформы виртуализации, я правильно понял?

У Вас бисер посыпался.

для тестов да

Вопросы с просьбами о настройке Wireguard для проброса порта с сохранением IP-адреса, настройке GRE/IPIP для этой же цели, вопросах о скорости разных VPN-решений/туннелей и заявление, что iptables работает медленно, из-за чего человеку приходится использовать различные прокси (преимущественно в контексте защиты от DDoS для сервера Minecraft) пишет один и тот же человек под несколькими аккаунтами, на разных сайтах (эти же вопросы появляются на Тостере).

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

Другие аккаунты автора:
@shaesnow
@maincrafter

чтобы пробросить ip адрес через ip тунель, нужно чтобы у машины было как минимум 2 адреса, один который ты пробрасываешь, второй с которого будет подниматся gre тунель до пробрасываемой машины. В случае с вдс так сделать нельзя. Но ты можешь использовать ip6 тунель с внешними адресами для проброса ип4 адреса. альтернативно, можно пробрасывать порты\протоколы NAT PAT с целью вырезать из проброса gre протокол который будет принадлежать самой вдс и пробрасыватся не будет. Оформить это через ip тунель чтобы пробрасываемый ип висел прямо на интерфейсе ip тунеля можно но геморойно, т.к возникнет конфликт по маршрутам. Проще трансляцию 1:1 с исключением gre