Jump to content
Калькуляторы

nftables/iptables или iproute2 или netns (проектно)

Требуется решение задачи на nftables (приоритетней)/iptables или iproute2 или netns. При себе: ubuntu 18.04, nginx 1.14 с php-fpm 7.2, nftables 0.8.2/iproute2.

 

О проблеме:

имеется две виртуальные сетевые карты реализованные средствами proxmox 5.2 с разными айпи адресами (серый и белый с лупбеком),
php скриптом опрашивается удалённый сервер по UDP,
запросы посылаются с серого адреса в ожидании ответа. Ответ от удалённого сервера не приходит (особенность сети, придёт если отправить с белого).

 

netstat -anoptu

Quote

udp        0      0 192.168.1.11:51442     176.12.99.34:7066      ESTABLISHED 821/php              off (0.00/0/0)
udp        0      0 192.168.1.11:42282     176.12.99.34:7066      ESTABLISHED 821/php              off (0.00/0/0)

ip a
 

Quote

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ce:f9:8c:4e:46:48 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.11/24 brd 192.168.1.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::ccf9:8cff:fe4e:4648/64 scope link
       valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether c6:b2:8f:4b:fb:ac brd ff:ff:ff:ff:ff:ff
    inet 176.12.33.34/32 scope global ens19
       valid_lft forever preferred_lft forever
    inet6 fe80::c4b2:8fff:fe4b:fbac/64 scope link
       valid_lft forever preferred_lft forever

 

ip route

 

Quote

default via 192.168.1.1 dev ens18 proto static
192.168.1.0/24 dev ens18 proto kernel scope link src 192.168.1.11

 

О задаче:

с помощью nftables (приоритетней)/iptables или iproute2 или netns перенаправить трафик определённого пользователя (от которого запускается php-fpm) с серого адреса на белый.
Тесты проведу сам. С вас только реализация.

 

Прошу компетентных людей оставить свои контакты в теме.
Оплата после результата (успешно отправленного пакета с белого адреса).

Edited by Mokvolt

Share this post


Link to post
Share on other sites

2 hours ago, pppoetest said:

В iptables есть модуль owner, можно попробовать воспользоваться им.

Пробовал:
 

Quote

iptables -t mangle -A OUTPUT -m owner --uid-owner "www-data" -j MARK --set-xmark 100

iptables -t nat -A POSTROUTING -m mark --mark 100 -j SNAT --to-source 176.12.33.34

Трафик блокируется. Сам nginx работает, всё, что имеет отношение к .php - нет.

Edited by Mokvolt

Share this post


Link to post
Share on other sites

А если просто

Цитата

ip route add default via адрес_пира dev ens19 t 100
iptables -t mangle -A OUTPUT -m owner --uid-owner "web-user" -j MARK --set-mark 100
ip rule add from all fwmark 100 lookup 100

 

Share this post


Link to post
Share on other sites

2 hours ago, pppoetest said:

ip route add default via адрес_пира dev ens19 t 100

Quote

ip route add default via 176.12.33.34 dev ens19 t 100


Error: argument "100 " is wrong: "table" value is invalid

 

Quote

ip route add default via 176.12.33.34 dev ens19

RTNETLINK answers: File exists

 

 

route

Quote

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    0      0        0 ens18
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 ens18

 

ip route del default

Дублирую команду

Quote

ip route add default via 176.12.33.34 dev ens19

Успешно.

Сеть легла. Гетвея то нет по дефолтному маршруту.

Добавляю белый гетвей:

 

Quote

route add default gw 176.12.33.35
SIOCADDRT: Network is unreachable

 

 

Edited by Mokvolt

Share this post


Link to post
Share on other sites

 ip route add default via 176.12.33.34 dev ens19 t 100  

via указывается КОМУ слать пакеты, а ты указал ip интерфейса с которого уходить.

 

Схема сети кстати не ясна.

 

176.12.33.35 

А этот адрес чей?

 

В общем накидай схему сети

Share this post


Link to post
Share on other sites

1 hour ago, pppoetest said:

В общем накидай схему сети

На словах пойдёт? )))
Попробую...

Juniper SRX 100H с BGP + NAT и подсетью белых адресов 176.12.33.32/29.
За Juniper гипервизор с серой сетью.
На гипервизоре сбриджена виртуальнная машина с двумя виртуальными сетевыми интерфейсами:
192.168.1.11
176.12.33.34
Белый айпи получаю средствами Bird 1.6, интерфейс с белым айпи с лупбеком.

176.12.33.35 это белый гетвей. Который я пытался прицепить в дефолт роут.

Edited by Mokvolt

Share this post


Link to post
Share on other sites

Ясно, ни гипервизор, ни виртуалка не знают о 176.12.33.35, потому и анричбл. Ещё такой вопрос, опрашиваемый узел за натом джуна?

Share this post


Link to post
Share on other sites

57 minutes ago, pppoetest said:

Ясно, ни гипервизор, ни виртуалка не знают о 176.12.33.35, потому и анричбл. Ещё такой вопрос, опрашиваемый узел за натом джуна?

Верно.
Ну... опрашиваемый узел работает по такой же схеме - висит на белом айпи.

У меня был ещё вариант - аналогичный инстанс с бёрдом, но только на уровне гипервизора и бридж в виртуалку (позволит исключить дополнительный вирт. интерфейс в виртуалке и иметь белый айпи по стандарту (в теории работало бы)).

Edited by Mokvolt

Share this post


Link to post
Share on other sites

Правильно ли я понимаю, что в данном случае при построении ещё одного моста требуется подключение по отдельному физическому сетевому интерфейсу?
 

Quote

 

auto vmbr0
iface vmbr0 inet static
        address  192.168.1.3
        netmask  255.255.255.0
        gateway  192.168.1.1
        bridge_ports eth1
        bridge_stp off
        bridge_fd 0
 

auto vmbr1_white
iface vmbr1_white inet static
        address 176.12.33.33
        netmask 255.255.255.255
        gateway 192.168.1.1
        bridge_ports eth1
        bridge_stp off
        bridge_fd 0

 

 

Edited by Mokvolt

Share this post


Link to post
Share on other sites

address 176.12.33.33
netmask 255.255.255.255
gateway 192.168.1.1

Оно так работать не будет. Зачем тебе ещё один мост и белый адрес, если опрашиваемый сервер у тебя за пределами сети? Может проще все запросы натить на джуне и не надо ничего вообще городить?

Share this post


Link to post
Share on other sites

41 minutes ago, pppoetest said:

address 176.12.33.33
netmask 255.255.255.255
gateway 192.168.1.1

Оно так работать не будет. Зачем тебе ещё один мост и белый адрес, если опрашиваемый сервер у тебя за пределами сети?

Верно, но попробовал - не вышло.

 

41 minutes ago, pppoetest said:

Может проще все запросы натить на джуне и не надо ничего вообще городить?

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

p.s. Ещё пробовали переписать скрипт - создали сокет и с белого адреса отправляли запросы, но они идут по дефолтному маршруту с серой сети.

Edited by Mokvolt

Share this post


Link to post
Share on other sites

16 минут назад, Mokvolt сказал:

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

Что за чушь, если у тебя

Цитата

NAT и подсеть белых адресов 176.12.33.32/29.

То пакет с серой подсети отначенный в 176.12.33.32/29 должен дойти до адресата и ответ вернётся обратно

Share this post


Link to post
Share on other sites

46 minutes ago, pppoetest said:

опрашиваемый сервер у тебя за пределами сети

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

Edited by Mokvolt

Share this post


Link to post
Share on other sites

6 minutes ago, pppoetest said:

То пакет с серой подсети отначенный в 176.12.33.32/29 должен дойти до адресата и ответ вернётся обратно 

Верно, но скрипт посылает по сети инфу на клиент не с тем адресом.
По факту это не из трафика клиент понимает, а из инфо которую клиент ему возвращает.

Share this post


Link to post
Share on other sites

7 minutes ago, pppoetest said:

Тогда давай схемку от опрашивающего узла до опрашивающего

Попробую в очередной раз на словах.

Скрипт отправляет с 192.168.1.11 (176.12.33.33 NATовский) до 176.12.33.34.
176.12.33.34  возвращает:
 

Quote

18:33:10.952872 IP 176.118.73.200.49808 > 176.12.33.34.7065: UDP, length 25
18:33:10.953853 IP 176.12.33.34.7065 > 176.118.73.200.49808: UDP, length 90
18:33:56.120525 IP 2.92.123.153.53773 > 176.12.33.34.7065: UDP, length 25
18:33:56.125052 IP 176.12.33.34.7065 > 2.92.123.153.53773: UDP, length 90
18:33:58.939293 IP 176.12.33.34.7065 > 2.92.123.153.53774: UDP, length 90

Смотришь что за айпишники, а это BGP разных провайдеров.

Edited by Mokvolt

Share this post


Link to post
Share on other sites

Благодарю за помощь pppoetest в найденном решении:
 

Quote

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.all.rp_filter=0
iptables -t nat -I PREROUTING -d 192.168.1.201 -s 192.168.1.200 -j DNAT --to-destination 176.12.33.34

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.