LINUX.ORG.RU
Форум — General  

Нужна помощь с непонятным сетевым поведением ipv6/ipv4

 , , , ,


0

1

Привет! Потратил кучу времени на то чтобы завести приложение в docker на vps и получить доступ к нему по ipv4

VPS - archlinux

docker –version Docker version 27.2.1, build 9e34c9bb39

Суть проблемы - приложение XXX (на golang) которое поднимается в докере по какой-то причине поднимается на ipv6 [::] хотя адрес я заправляю 0.0.0.0 чтобы запросы летели со всех интерфейсов. При этом в целом ipv4 вроде обслуживается с lo с локалки, но с удаленной машины устанавливается только tcp коннект без отдачи контента сервером:

Лог приложения:
INFO - Web server running HTTP on [::]:65228

TCP соединения на локалке:

> lsof -iTCP
COMMAND     PID            USER FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r   294 systemd-resolve 12u  IPv4   3321      0t0  TCP *:llmnr (LISTEN)
systemd-r   294 systemd-resolve 19u  IPv4   3333      0t0  TCP _localdnsstub:domain (LISTEN)
systemd-r   294 systemd-resolve 21u  IPv4   3335      0t0  TCP _localdnsproxy:domain (LISTEN)
sshd        317            root  7u  IPv4   3604      0t0  TCP *:228 (LISTEN)
sshd        317            root  8u  IPv6   3606      0t0  TCP *:228 (LISTEN)
container   322            root  9u  IPv4   3889      0t0  TCP localhost:40909 (LISTEN)
sshd-sess  9268            root  4u  IPv4  78772      0t0  TCP CCC:228->YYY:60970 (ESTABLISHED)
sshd-sess  9282             vpn  4u  IPv4  78772      0t0  TCP CCC:228->YYY:60970 (ESTABLISHED)
XXX      20798            root  7u  IPv6 227414      0t0  TCP *:65228 (LISTEN)
rkn 20822            root  4u  IPv4 227437      0t0  TCP localhost:62789 (LISTEN)
rkn 20822            root  7u  IPv4 227439      0t0  TCP localhost:vce (LISTEN)

docker-compose.yml:

services:
  3xui:
    build:
      context: .
      dockerfile: ./Dockerfile
    container_name: rkn_app
    #hostname: ??? #<- optional
    volumes:
      - $PWD/db/:/etc/x-ui/
      - $PWD/cert/:/root/cert/
    environment:
      rkn_FORCED: "false"
      rkn_ENABLE_FAIL2BAN: "true"
    tty: true
    network_mode: host
    restart: unless-stopped

При этом запрос с loopback на локалке в этот контейнер спокойно долетает и по ipv4:

curl -4 -v -IHEAD "http://0.0.0.0:65228"
curl -4 -v "http://0.0.0.0:65228"
*   Trying 0.0.0.0:65228...
* Connected to 0.0.0.0 () port 65228
> GET / HTTP/1.1
> Host: 0.0.0.0:65228
> User-Agent: curl/8.10.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Date: Sun, 07 Sep 2025 20:27:27 GMT
< Transfer-Encoding: chunked
<

tcpdump при локальном запросе:

tcpdump -i any -n tcp port 65228
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
20:29:46.382409 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [S], seq 1906462195, win 65495, options [mss 65495,sackOK,TS val 1137138809 ecr 0,nop,wscale 7], length 0
20:29:46.382425 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [S.], seq 3063170275, ack 1906462196, win 65483, options [mss 65495,sackOK,TS val 1137138809 ecr 1137138809,nop,wscale 7], length 0
20:29:46.382437 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 1, win 512, options [nop,nop,TS val 1137138809 ecr 1137138809], length 0
20:29:46.382932 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [P.], seq 1:78, ack 1, win 512, options [nop,nop,TS val 1137138809 ecr 1137138809], length 77
20:29:46.382941 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [.], ack 78, win 511, options [nop,nop,TS val 1137138809 ecr 1137138809], length 0
20:29:46.384670 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [P.], seq 1:4097, ack 78, win 512, options [nop,nop,TS val 1137138811 ecr 1137138809], length 4096
20:29:46.384683 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 4097, win 809, options [nop,nop,TS val 1137138811 ecr 1137138811], length 0
20:29:46.384698 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [P.], seq 4097:9428, ack 78, win 512, options [nop,nop,TS val 1137138811 ecr 1137138811], length 5331
20:29:46.384704 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 9428, win 807, options [nop,nop,TS val 1137138811 ecr 1137138811], length 0
20:29:46.384846 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [P.], seq 9428:13524, ack 78, win 512, options [nop,nop,TS val 1137138811 ecr 1137138811], length 4096
20:29:46.384884 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 13524, win 780, options [nop,nop,TS val 1137138811 ecr 1137138811], length 0
20:29:46.385538 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [P.], seq 13524:17620, ack 78, win 512, options [nop,nop,TS val 1137138812 ecr 1137138811], length 4096
20:29:46.385564 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 17620, win 843, options [nop,nop,TS val 1137138812 ecr 1137138812], length 0
20:29:46.385977 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [P.], seq 17620:21716, ack 78, win 512, options [nop,nop,TS val 1137138812 ecr 1137138812], length 4096
20:29:46.385985 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 21716, win 816, options [nop,nop,TS val 1137138812 ecr 1137138812], length 0
20:29:46.386272 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [P.], seq 21716:21914, ack 78, win 512, options [nop,nop,TS val 1137138813 ecr 1137138812], length 198
20:29:46.386279 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 21914, win 815, options [nop,nop,TS val 1137138813 ecr 1137138813], length 0
20:29:46.390340 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [F.], seq 78, ack 21914, win 843, options [nop,nop,TS val 1137138817 ecr 1137138813], length 0
20:29:46.390388 lo    In  IP 127.0.0.1.65228 > 127.0.0.1.36254: Flags [F.], seq 21914, ack 79, win 512, options [nop,nop,TS val 1137138817 ecr 1137138817], length 0
20:29:46.390444 lo    In  IP 127.0.0.1.36254 > 127.0.0.1.65228: Flags [.], ack 21915, win 843, options [nop,nop,TS val 1137138817 ecr 1137138817], length 0

При этом если я делаю запрос со своей реальной машины на VPS сервак на указанный порт - TCP соединение устанавливается, но от сервера HTML страницу я почему-то не получаю (curl запрос подвисает на бесконечность):

ncat -4 -w 1 -vz VPS 65228
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Connected to VPS:65228.
Ncat: 0 bytes sent, 0 bytes received in 0.06 seconds.

curl -w 1 -4 -v "http://VPS:65228"
*   Trying VPS:65228...
* Connected to VPS (VPS) port 65228
* using HTTP/1.x
> GET / HTTP/1.1
> Host: VPS:65228
> User-Agent: curl/8.12.1
> Accept: */*
> 
* Request completely sent off

На VPS при этом tcpdump следующий:

tcpdump -i any -n tcp port 65228
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
20:39:11.848374 eth0  In  IP myPC.48070 > VPS.65228: Flags [S], seq 782807053, win 64240, options [mss 1456,sackOK,TS val 2703465502 ecr 0,nop,wscale 7], length 0
20:39:11.848551 eth0  Out IP VPS.65228 > myPC.48070: Flags [S.], seq 3026312210, ack 782807054, win 65160, options [mss 1460,sackOK,TS val 3225839648 ecr 2703465502,nop,wscale 7], length 0
20:39:11.887313 eth0  In  IP myPC.48070 > VPS.65228: Flags [.], ack 1, win 502, options [nop,nop,TS val 2703465541 ecr 3225839648], length 0
20:39:13.872647 eth0  Out IP VPS.65228 > myPC.52810: Flags [.], ack 1607925916, win 510, options [nop,nop,TS val 3225841672 ecr 2703328807], length 0
20:39:27.525965 eth0  Out IP VPS.65228 > myPC.48070: Flags [.], ack 1, win 510, options [nop,nop,TS val 3225855325 ecr 2703465541], length 0
20:39:29.232641 eth0  Out IP VPS.65228 > myPC.52810: Flags [R.], seq 1, ack 1, win 510, options [nop,nop,TS val 3225857032 ecr 2703328807], length 0
20:39:42.885896 eth0  Out IP VPS.65228 > myPC.48070: Flags [.], ack 1, win 510, options [nop,nop,TS val 3225870685 ecr 2703465541], length 0
20:39:58.247361 eth0  Out IP VPS.65228 > myPC.48070: Flags [.], ack 1, win 510, options [nop,nop,TS val 3225886047 ecr 2703465541], length 0
20:40:13.605948 eth0  Out IP VPS.65228 > myPC.48070: Flags [.], ack 1, win 510, options [nop,nop,TS val 3225901405 ecr 2703465541], length 0
^C
9 packets captured
10 packets received by filter
0 packets dropped by kernel

Подскажите в чем может быть трабл и как подружить запросы из вне с сервером. Уже всю голову сломал, не понимаю в чем тут собака зарыта. Буду очень признателен за помощь - если чего-то не хватает, пишите какие команды докинуть. Мне очень интересно что конкретно не так, почему сервер отвечает только на сообщения с lo, почему он не посылает html контент в установленное tcp соединение и просто шлет ACK’и без Push’ей, но при этом работает по lo

Я сначала думал что дело в том что оно слушает на ipv6, но curl -4 сбивает меня с толку. Файрвол есть, но он открывает все TCP на 65228, вроде миссконфига не должно быть… + файрвол работает на транспортном уровне, по идее тогда TCP соединение не установилось бы и зареджектилось или таймаутнуло. Сейчас у меня предположение что сервер как-то чекает src ip и в зависимости от этого определяет кидать ответ или нет. Вообще звучит бредово, но пока идей больше нет(((



Последнее исправление: wh75per (всего исправлений: 1)
← На роутере Ростелекома неправильные дата и время
Kubernetes для сайта →
Ответ на: комментарий от BOOBLIK

Читал про это, НО

lsof -iTCP классифицирует слушающий сокет по этому адресу как ipv6

Все коннекты по этому адресу подефолту инициируются как ipv6

В lsof у меня есть ipv4 слушающие сокеты адрес которых прописан как 0.0.0.0

wh75per
() автор топика
Ответ на: комментарий от wh75per

lsof -iTCP классифицирует слушающий сокет по этому адресу как ipv6

Можно пример того, что ты называешь «классификацией» и ссылку на доку lsof где это описано?

Все коннекты по этому адресу подефолту инициируются как ipv6

То как у тебя инициируются коннекты от слущающей стороны не зависит. За это отвечает настройка getaddrinfo в твоей системе через конфиг gai.conf

В lsof у меня есть ipv4 слушающие сокеты адрес которых прописан как 0.0.0.0

Это нормально. Авторы приложений, на сокеты которых ты смотришь, могли сделать эти сокеты с различными флагами/типами (AF_INET, AF_INET6, флаг IPV6_V6ONLY и т.п.). Соотвественно в утилитах типа ss их сокеты будут выглядеть как 0.0.0.0 или [::] или вообще *:порт.

BOOBLIK ★★★★
()
Последнее исправление: BOOBLIK (всего исправлений: 2)
← На роутере Ростелекома неправильные дата и время
General
Kubernetes для сайта →