я использую либтины (Он использует 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 аналогичный вопрос был задан на этом сайте несколько лет назад, но никому не удалось предоставить рабочее решение.
Ваши точные команды работают в моей системе.
Вот что я проверил:
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, не касаясь клиента. Не хочу обижаться, на всякий случай констатирую очевидное.