i2pd
i2pd copied to clipboard
PurpleI2P
Enabling of IPv6 significantly decreases number of transit tunnels
I suspect that enabling of IPv6 significantly decreases number of transit tunnels. I have two identical very cheap VDS. Some CPU, 256 MB RAM, 1 ipv4 address, 1 ipv6 address. i2pd version 2.13 with identical config, but on first vds ipv6=true, on second vds ipv6=false. Uptime 20 hours. Mem usage less than 30M. first vds: client tunnels 35, transit tunnels 162 second vds: client tunnels 32, transit tunnels 787 Is it bug? Do you need additional info? Suspicion was born at ver 2.11
one vds IPv6 enabled in i2pd.conf ~# netstat -nap | grep i2pd | grep EST | grep "tcp6" | wc -l 10 ~# netstat -nap | grep i2pd | grep EST | grep "tcp " | wc -l 252
other vds IPv6 disabled in i2pd.conf ~# netstat -nap | grep i2pd | grep EST | grep "tcp6" | wc -l 0 ~# netstat -nap | grep i2pd | grep EST | grep "tcp " | wc -l 1338
Может оно раньше 2.11 возникло, но я раньше этой темой не интересовался
uptime 1 day 20 hours туннели кл 34, тр 943 - ipv6 disabled кл 37, тр 191 - ipv6 enabled
Вчера вечером поменял конфиги местами и перезапустил обе vds. Теперь эффект не наблюдается. Либо баг плавающий, либо проблемы у хостера, либо бага нет.
Имеется 2 одинаковые vds у одного хостера (я надеюсь, что одинаковые) Хостер сообщил, что действительно были проблемы с потерей пакетов, сейчас они устранены, все работает нормально
============== uptime примерно 10 часов, с разницей 15 минут
ipv6=true ОЗУ 36356, туннели к 36 т 748
~# ss -s
Total: 1385 (kernel 1422)
TCP: 1375 (estab 1278, closed 40, orphaned 33, synrecv 0, timewait 40/0), ports 0
Transport Total IP IPv6
* 1422 - -
RAW 0 0 0
UDP 18 9 9
TCP 1335 983 352
INET 1353 992 361
FRAG 0 0 0
ipv6=false ОЗУ 28472, туннели к 35 т 1101
:~# ss -s
Total: 2070 (kernel 2091)
TCP: 2063 (estab 1966, closed 44, orphaned 34, synrecv 0, timewait 44/0), ports 0
Transport Total IP IPv6
* 2091 - -
RAW 0 0 0
UDP 17 9 8
TCP 2019 2014 5
INET 2036 2023 13
FRAG 0 0 0
================
перезапустил на обоих vds i2pd, поменяв ipv6=true и ipv6=false местами uptime 17 часов
ipv6=true ОЗУ 24120, туннели к 39 т 579
~# ss -s
Total: 1285 (kernel 1311)
TCP: 1257 (estab 1177, closed 28, orphaned 27, synrecv 0, timewait 28/0), ports 0
Transport Total IP IPv6
* 1311 - -
RAW 0 0 0
UDP 18 9 9
TCP 1229 1126 103
INET 1247 1135 112
FRAG 0 0 0
ipv6=false ОЗУ 38004, туннели к 32 т 953
~# ss -s
Total: 1982 (kernel 1989)
TCP: 1991 (estab 1880, closed 40, orphaned 53, synrecv 0, timewait 40/0), ports 0
Transport Total IP IPv6
* 1989 - -
RAW 0 0 0
UDP 17 9 8
TCP 1951 1947 4
INET 1968 1956 12
FRAG 0 0 0
====================================
Поменял местами ipv6=true/false на этих 2 vds еще раз uptime приблизительно 3 часа 50 минут
ipv6=true ОЗУ 33196, туннели к 40 т643
~# ss -s
Total: 878 (kernel 900)
TCP: 837 (estab 777, closed 25, orphaned 19, synrecv 0, timewait 25/0), ports 0
Transport Total IP IPv6
* 900 - -
RAW 0 0 0
UDP 18 9 9
TCP 812 756 56
INET 830 765 65
FRAG 0 0 0
ipv6=false ОЗУ 36028, туннели к 30 т 805
~# ss -s
Total: 1627 (kernel 1641)
TCP: 1642 (estab 1529, closed 44, orphaned 53, synrecv 0, timewait 44/0), ports 0
Transport Total IP IPv6
* 1641 - -
RAW 0 0 0
UDP 17 9 8
TCP 1598 1593 5
INET 1615 1602 13
FRAG 0 0 0
================================
I2pd ver 2.13, Debian Jessie 64 bit По моим наблюдениям этот эффект перемещается вслед за ipv6=true и начинает проявляться примерно через 2 часа работы. Сначала к-во соединений и транзитных туннелей на обоих vds растет примерно с равной скоростью, затем сервер с вкл IPv6 начинает отставать. Процессы не монотонные, а пилообразные, но общая картина какая-то такая. В конфиге такое: ifname = eth0 nat = false bandwidth = 20480 notransit = false floodfill = true
Баг или не баг?
@codingPrimate Сейчас наблюдаю такое. 2 шт одинаковых (надеюсь) vds, на каждом 1 шт ipv4 и 1 шт ipv6. Единственное отличие - 1 строчка в i2pd.conf. С включенным ipv6 за 17 часов образовалось 437 транзитных туннелей, а с выключенным за те же 17 часов образовался 921 транзитный туннель. Почему включение еще одного протокола уменьшает к-во туннелей ? По установленным tcp-соединениям та же картина. Мне кажется, что должно быть наоборот, или как минимум включение ipv6 не должно ухудшать работу ipv4. Или я тоже недостаточно умный?
@LLE8 там проблема в том что для соединения выбирается только из двух адресов, а не из четырех. Это надо переделать
На другом хостинге тоже проявляется эта особенность, хотя там не совсем чистый эксперимент, с разрешенным и запрещенным ipv6 запускал последовательно на одном vds, а не одновременно на двух одинаковых, как выше.
По сравнению с https://github.com/PurpleI2P/i2pd/issues/804#issuecomment-299835348 при ipv6=false после 23 с половиной часов образовалось примерно 1080-1120 транзитных туннелей.
~# ss -s
Total: 1706 (kernel 1734)
TCP: 1705 (estab 1603, closed 45, orphaned 38, synrecv 0, timewait 45/0), ports 796
Transport Total IP IPv6
* 1734 - -
RAW 0 0 0
UDP 16 9 7
TCP 1660 1656 4
INET 1676 1665 11
FRAG 0 0 0
@orignal just FYI, usually not only one but multiple IPv6 addresses are assigned to the interface, and the software need to make sure it replies from the same IPv6 address to which the request came. Also IPv6 address could be temporary (ephemeral) which work only for several hours (IPv6 privacy extension).
Попался недорогой хостер с сетью /64 IPv6 https://racktech.ru/rus/service/vps/ Когда баг исправится, можно будет попробовать. Еще /64, но дороже https://www.vps.ag/ И еще https://www.ipserver.su/ru/prices/cats/view/id/3/countryId/18 https://www.ipserver.su/ru/news/index/view/id/102/ipv6-v-moskve-64-na-kaghduyu-uslugu И еще https://www.netangels.ru/cloud/ https://www.netangels.ru/company/news/2016/ipv6/ И эти https://hostlix.ru/vdss.php ответили "да, можно, это бесплатно. Сеть предоставляется по запросу только для виртуализации KVM"
@orignal может это связано с тем костылем в ntcp, который я недавно заметил?
https://github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/NTCPSession.cpp#L1082
Наблюдаю такую странную картину
root@debian:~# netstat -np -6 | grep ESTAB | wc -l
111
root@debian:~# netstat -np -6 | grep SYN_SENT | wc -l
83
Т.е. ВСЕГДА 35-40% tcp6-соединений находится в состоянии SYN_SENT., причем каждое такое соединение находится в состоянии SYN_SENT некоторое время, не менее нескольких секунд, и в состояние ESTABLISHED похоже не переходит. В состоянии TIME_WAIT обычно 1-2 штуки. Явление наблюдается непрерывно,, почти не меняется на протяжении часов, общее количество tcp6-соединений почти не увеличивается. Выглядит так:
tcp6 0 0 xxxx:**41:0:1973::51296 2a02:2970:1002:0::21400 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::45618 2001:569:bc89:400:29481 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::39628 2a00:c440:70:88b::27002 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::54558 2001:bc8:4700:250:21826 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::56070 2001:470:28:1dd:2:18773 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::49102 2405:9800:ba11:d0:23137 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::54098 2605:e000:1906:c8:36875 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::36026 2a02:2970:1002:0::16819 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::33792 2603:9000:e70f:c7:23496 SYN_SENT 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::33680 2a02:c7f:8c6d:2f0:26955 SYN_SENT 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::49078 2605:e000:160d:13:32887 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::50494 2a02:ee0:2:aaaa::4:8203 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::60982 2604:2000:b090:81:25116 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::52080 2601:603:b80:b09::21225 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::58836 2001:18c0:462:cb0:39053 SYN_SENT 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::33426 2a02:c7f:9e18:300:39121 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::48102 2a01:4f8:d16:128e:29352 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::48260 2001:48f8:24:80b::28175 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::34524 2001:e68:5445:117:35477 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::35858 2a02:587:1112:3d0:20087 SYN_SENT 11103/i2pd
tcp6 0 1066 xxxx:**41:0:1973::46590 2600:3c02::f03c:9:26930 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::55882 2a02:2168:a07:32ec:9520 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::58124 2605:a000:1110:12:32610 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::50732 2001:bc8:4700:250:24984 ESTABLISHED 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::41370 2600:1700:1bd0:27:20137 ESTABLISHED 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::32852 2601:186:c180:c70:29941 SYN_SENT 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::41952 2405:9800:ba00:3a:24934 SYN_SENT 11103/i2pd
tcp6 0 1 xxxx:**41:0:1973::53130 2607:fea8:879f:f8:39967 SYN_SENT 11103/i2pd
tcp6 0 0 xxxx:**41:0:1973::45160 2a01:e34:eeaf:c01:35718 ESTABLISHED 11103/i2pd
Debian Jessie 64 bit, ipv6 сеть /64. i2pd свежий bd5122c6ea2d499. Ранее на этом VDS около недели работал i2pd только с ipv4, без ipv6, набралась некоторая netDb. По tcp4 такой картины не наблюдается.
Uptime двое суток, картина та же, иногда даже немного больше 40%
root@debian:~# netstat -np -6 | grep SYN_SENT | wc -l
101
root@debian:~# netstat -np -6 | wc -l
232
син_сент значит у партнера задекларирован ip6 endpoint, но соединения не принимаются возможно из-за фаервола типичная настройка домашних роутеров ipv6 предполагает обруб incoming с возможностью открыть через upnp. но i2pd как я понимаю его не поддерживает
В openwrt по умолчанию применяется такая схема с miniupnpd если нет soho роутера можно поставить x86_64 в виртуалку
Java I2P на выделенном сервере:
# ss -npt6 | grep java | grep ESTAB | wc -l
559
# ss -npt6 | grep java | grep SYN-SENT | wc -l
14
# ss -npt6 | grep java | grep WAIT | wc -l
0
у меня и на vps с нативкой, и на туннельброкере от he.net аналогично. проблемы не вижу просто предположил 1 из возможных вариантов почему у многих может быть закрыт порт ведь ip6 предполагает раздачу прямых адресов всем внутренним устройствам. было бы странно оставлять по умолчанию их полностью открытыми. такое уже проходили в 90е-нулевые, когда половина виндов висела с расшареными дисками C D, а NT с administrator без пароля
да, еще если мы на винду как-то ставимся, то неплохо было бы open port на windows firewall
Насколько я знаю, UPnP сделан только для NAT, для перенаправления порта на внутренний IP-адрес. Для межсетевого экрана, если входящие соединения закрыты на маршрутазиторе по IPv6, есть специальный протокол: PCP
In addition to UPnP IGD, miniUPnPd supports NAT-PMP and PCP однозначно стоит порыться в miniupnp
Вполне возможно, что OpenWrt пользуется заслуженной популярностью, но я сомневаюсь, что i2p так популярна в OpenWrt, что 40% SYN_SENT. На другом vds с ipv6 /64 тоже видел что-то подобное, но не так много, всего 10-15-20%.