Назад | Перейти на главную страницу

Перенаправить трафик с одного IP-адреса

У A есть корневой сервер с двумя статическими IP-адресами, которые оба подключены к одному интерфейсу (eth0 и eth0: 1). Теперь мне нужно перенаправить весь входящий трафик с одного IP-адреса на виртуальную машину на том же ПК. Виртуальная машина имеет собственный локальный IP-адрес внутри виртуального коммутатора. (Доступен с «корневого компьютера»). Я уже разговаривал с провайдером, и он признал, что это возможно с помощью NAT, но мне не разрешено давать мне более подробные инструкции. Что я уже пробовал:

iptables -t nat -A PREROUTING -p tcp -d 85.214.XXX.XXX -j DNAT --to-destination 192.168.122.58

iptables -t nat -A PREROUTING -i eth0:1 -j DNAT --to-destination 192.168.122.58

Оба не работают. Сама виртуальная машина имеет доступ в Интернет через один IP-адрес. (Пинги от ВМ проходят успешно). Проблема в том, что входящий трафик (например, 85.214.XXX.XXX:80) по-прежнему обрабатывается «корневым компьютером», поэтому его необходимо перенаправить на виртуальную машину. Запросы по другому IP-адресу (85.12.XXX.XXX:80) не должны перенаправляться. Порт 80 был всего лишь примером порта. Есть больше портов, которые нужны http.

РЕДАКТИРОВАТЬ1: После использования первой команды трафик не обрабатывается «корневым сервером», но также не достигает виртуальной машины.

РЕДАКТИРОВАТЬ2:
ip -br ссылка: lo UNKNOWN 00:00:00:00:00:00 eth0 UP ac:1f:6b:21:ea:14 eth1 DOWN ac:1f:6b:21:ea:15 virbr0 UP 52:54:00:07:80:05 virbr0-nic DOWN 52:54:00:07:80:05 vnet0 UNKNOWN fe:00:a3:b0:56:10

IP-BR адрес: lo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 81.169.XXX.XXX/32 85.214.XXX.XXX/32 fe80::ae1f:6bff:fe21:XXXX/64 eth1 DOWN virbr0 UP 192.168.122.1/24 virbr0-nic DOWN vnet0 UNKNOWN fe80::fc00:a3ff:feb0:5610/64

Ip-маршрут: default via 81.169.192.1 dev eth0 81.169.192.1 dev eth0 scope link 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

IP-адрес -c: iptables-save -c # Generated by iptables-save v1.6.0 on Tue Jun 26 21:12:21 2018 *nat :PREROUTING ACCEPT [77:5491] :INPUT ACCEPT [57:4459] :OUTPUT ACCEPT [26:1644] :POSTROUTING ACCEPT [26:1644] [36:1868] -A PREROUTING -d 85.214.XXX.XXX/32 -p tcp -j DNAT --to-destination 192.168.122.58 [326:23798] -A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN [0:0] -A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN [70:4104] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535 [2384:181184] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535 [1:84] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE [4:240] -A POSTROUTING -d 192.168.122.58/32 -j SNAT --to-source 85.214.XXX.XXX COMMIT # Completed on Tue Jun 26 21:12:21 2018 # Generated by iptables-save v1.6.0 on Tue Jun 26 21:12:21 2018 *mangle :PREROUTING ACCEPT [8612376:1647699647] :INPUT ACCEPT [7968616:1098054721] :FORWARD ACCEPT [642923:549577951] :OUTPUT ACCEPT [7286018:1062313751] :POSTROUTING ACCEPT [7752855:1602990616] [363:121944] -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT # Completed on Tue Jun 26 21:12:21 2018 # Generated by iptables-save v1.6.0 on Tue Jun 26 21:12:21 2018 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :f2b-plesk-modsecurity - [0:0] [82390:7025055] -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT [18:720] -A INPUT -p tcp -m tcp --dport 106 -j DROP [2488:104592] -A INPUT -p tcp -m tcp --dport 3306 -j DROP [153:6168] -A INPUT -p tcp -m tcp --dport 5432 -j DROP [9:360] -A INPUT -p tcp -m tcp --dport 9008 -j DROP [41:1784] -A INPUT -p tcp -m tcp --dport 9080 -j DROP [252:20165] -A INPUT -p udp -m udp --dport 137 -j DROP [10772:2676517] -A INPUT -p udp -m udp --dport 138 -j DROP [488:21600] -A INPUT -p tcp -m tcp --dport 139 -j DROP [849142:43736264] -A INPUT -p tcp -m tcp --dport 445 -j DROP [68:2856] -A INPUT -p udp -m udp --dport 1194 -j DROP [39259:2663130] -A INPUT -p udp -m udp --dport 53 -j DROP [15817:947524] -A INPUT -p tcp -m tcp --dport 53 -j DROP [974:36333] -A INPUT -p icmp -m icmp --icmp-type 8/0 -j ACCEPT [5763490:719804706] -A INPUT -j ACCEPT [327455:532369669] -A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT [145660:7917349] -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT [0:0] -A FORWARD -i virbr0 -o virbr0 -j ACCEPT [29309:1533140] -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable [0:0] -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable [0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT [249:11394] -A FORWARD -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j REJECT --reject-with tcp-reset [3875:171296] -A FORWARD -m state --state INVALID -j DROP [0:0] -A FORWARD -i lo -o lo -j ACCEPT [582365:31456904] -A FORWARD -j DROP [363:121944] -A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT [12150865:2418557344] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT [24:5299] -A OUTPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j REJECT --reject-with tcp-reset [12746:706295] -A OUTPUT -m state --state INVALID -j DROP [494443:29667994] -A OUTPUT -o lo -j ACCEPT [408707:30248531] -A OUTPUT -j ACCEPT [68:6175] -A f2b-plesk-modsecurity -j RETURN COMMIT # Completed on Tue Jun 26 21:12:21 2018

И на ВМ:

IP-маршрут: default via 192.168.122.1 dev ens3 169.254.0.0/16 dev ens3 scope link metric 1000 192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.58

Ваш FORWARD правила разрешают трафик, инициированный виртуальной машиной, исходящий и ответный, со следующими правилами:

-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT #reply traffic to the VM
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT #VM initiated

Чего они не разрешают, так это входящего трафика, о чем свидетельствует высокое значение счетчика в следующем FORWARD правило:

[29309:1533140] -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable

Это хорошо для безопасности, но вам придется добавить исключения.

ОБНОВИТЬ: перенаправить весь трафик, а не только несколько портов.

Само перенаправление:

iptables -t nat -I PREROUTING -d 85.214.XXX.XXX -j DNAT --to-destination 192.168.122.58

Это перенаправит все протоколы (icmp, tcp, udp (возможно, другие)), вы можете добавить, как вы написали изначально -p tcp чтобы ограничить его tcp.

Вы должны включить перенаправленный трафик в FORWARD цепочка, так как когда-то трафик DNATed, он становится маршрутизированным, поэтому подлежит FORWARD цепочка (и не более INPUT цепь). В то же время, для защиты от любого неправильного использования локальной маршрутизации (например, шлюзом по умолчанию), вы можете ограничить это значение DNATтолько ed трафик, запрашивая conntrack (пометка пакетов в таблице mangle и их проверка здесь тоже сработала бы):

iptables -I FORWARD -d 192.168.122.58 -m conntrack --ctstate DNAT -j ACCEPT

Обратите внимание на -I. Поскольку вы конкурируете с правилами поставщика виртуальной машины (возможно, с virt-manager), вы должны позаботиться о том, чтобы ваши правила исключений были перед DROP/REJECT правила. Оптимально это могло произойти после ... RELATED,ESTABLISHED ... правило, но с этим можно будет разобраться позже.

Также обратите внимание, что по той же причине (правило приходит слишком поздно) исходящий трафик вашей виртуальной машины использует не ее выделенный IP-адрес, а IP-адрес хоста: SNAT правило приходит слишком поздно, после общего MASQUERADE правило. Вы должны вставить его с -I а не -A тоже, пока вы не выясните, как интегрировать это с (возможно?) virt-manager.
И, кроме того, в этом правиле в любом случае есть ошибка, оно должно использовать -s не -d как в:

iptables -t nat -I POSTROUTING -s 192.168.122.58/32 ! -d 192.168.122.0/24 -j SNAT --to-source 85.214.XXX.XXX

Каждый раз, когда (возможно?) Virt-manager повторно вставляет свое правило (перезапуск и т. Д.), Вы должны еще раз взглянуть на свои правила, чтобы увидеть, все ли по-прежнему в порядке, позволяющем то, что вы намереваетесь.

Это выходит за рамки этого Q / A, чтобы рассмотреть интеграцию virt-manager. Взгляните, например:

Сеть - Libvirt Wiki - Перенаправление входящих соединений