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

Перенаправленные пакеты принимаются пространством имен veth0, но не принимаются приложением

я использую либтины (Он использует Pcap) для захвата пакетов канального уровня и пересылки в сетевое пространство имен, где выполняется фактическое приложение.

Client(Browser) -> Server -> Pcap -> Pcap Send -> br0 (Bridge) -> Namespace -> Application 

Теперь я вижу, что пакеты пересылаются и отображаются в моментальном снимке Tcpdump, но я не вижу, что они получены самим приложением, как и никаких признаков исходящих пакетов.

Похоже, что интерфейс обратной петли в пространстве имен тоже не получил пакетов, поэтому похоже, что ядро ​​по какой-то причине не направляет пакеты в петлю.

Я считаю, что приложение по умолчанию прослушивает интерфейс обратной связи, и, исходя из моего предположения, именно там работает localhost.

Я попытался привязать приложение к IP-адресу сетевого интерфейса veth0 в пространстве имен, но это тоже не сработало.

Я могу пинговать любой веб-сайт внутри сетевого пространства имен.

Что касается контрольной суммы, TCP Dump показывает, что пакеты имеют правильную контрольную сумму

Вот как я настраиваю свое сетевое пространство имен,

sysctl -w net.ipv4.ip_forward=1 &&
sysctl -w net.ipv6.conf.all.forwarding=1 &&
ip netns add namespace1 &&
ip link add veth0 type veth peer name veth1 &&
ip link set veth0 netns namespace1 &&
ip netns exec namespace1 ip addr add 192.168.1.11/24 dev veth0 &&
ip link add name br0 type bridge &&
ip link set br0 up &&
ip link set veth1 up &&
ip netns exec namespace1 ip link set veth0 up &&
ip netns exec namespace1 ip link set lo up &&
ip link set veth1 master br0 &&
ip addr add 192.168.1.10/24 brd + dev br0 &&
ip -all netns exec ip route add default via 192.168.1.10 &&
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

Вот пример пакета, захваченного TCP Dump в пространстве имен сети,

16:50:11.742116 IP (tos 0x2a,ECT(0), ttl 115, id 8487, offset 0, flags [DF], proto TCP (6), length 52)
    MYHOMEIP.51202 > SERVERIP.https: Flags [SEW], cksum 0x59a4 (correct), seq 332112346, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Вот вывод ss -lntp в пространстве имен,

State           Recv-Q          Send-Q                     Local Address:Port                     Peer Address:Port          Process
LISTEN          0               511                                    *:443                                 *:*              users:(("node",pid=30798,fd=20))
LISTEN          0               511                                    *:7000                                *:*              users:(("node",pid=30798,fd=19))

Глядя на вывод, я вижу, что Send Q заполнен 511, и я не уверен, что это значит.

Ответ ниже не добавляет ничего нового и не устранил мою проблему.

Я хотел бы наградить награду, но не могу найти кнопку.

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

Поговорите с veth

Ваши точные команды работают в моей системе.

Вот что я проверил:

man nc
ip netns exec namespace1 nc -l 192.168.1.11 8123

Теперь на удаленном клиенте:

ip ro add 192.168.1.11/32 via SERVERIP
echo MyTestData | nc -v 192.168.1.11 8123

Поговорите с петлей

Однако вы что-то говорите о петле. Очевидно, для 127/8 работать не будет, поэтому я подготовил маршрутизацию:

ip netns exec namespace1 ip a add 192.168.2.2 dev lo
ip ro add 192.168.2.2/32 via 192.168.1.11

Теперь на удаленном клиенте:

ip ro add 192.168.2.2/32 via SERVERIP
echo MyTestData | nc -v  192.168.2.2 8123

При этом еще одно предостережение. Похоже, вы пришли из фона netadmin. Сервер не является маршрутизатором, поэтому использование обратной связи для чего-либо, кроме «трафика к самому себе» 127/8, является очень необычной практикой на серверах приложений. Ожидается, что клиенты будут разговаривать с eth / veth.

Но я не могу сказать всем клиентам добавить маршрут

Глядя на ваш предыдущий вопрос (теперь удаленный) о том, как ядро ​​должно обрабатывать маршрутизацию в случае, если клиент обращается к "общедоступному" IP, я хотел бы напомнить о вещи, называемой DNAT. (Это что-то еще, что MASQUERADE. Вы часто используете DNAT вместе с MASQUERADE.)

Так что вместо ip ro add на клиенте вы можете делать DNAT, не касаясь клиента. Не хочу обижаться, на всякий случай констатирую очевидное.