Пытаюсь поднять 6in4-туннель с помощью собранного некоторое время назад gogoclient'а.
gogoclient отрабатывает нормально, а вот shell-скрипт поднятия интерфейса - нет. Подкажите, в чём может быть дело? Почему возникает ошибка при выполнении ifconfig:
Code:
$ /sbin/ifconfig sit1 add 2001:05c0:1400:000b:0000:0000:0000:cba9/128
ifconfig: SIOCSIFADDR: Permission denied
Upd 15.02 20:11. Разобрался:
Code:
$ echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6
Причём ipv6-адреса на интерфейсах появятся только спустя ~3 секунды после выполнения этой команды.
Upd 16.02 15:40. Победил, работает! Задержки приемлемые, хоть и стали больше:
Code:
$ ping -6 -q ipv6.google.com
PING ipv6.google.com (2a00:1450:4010:c01::63): 56 data bytes
--- ipv6.google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 96.448/96.689/96.893 ms
$ ping -4 -q ipv4.google.com
PING ipv4.google.com (209.85.137.104): 56 data bytes
--- ipv4.google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 34.611/36.860/37.537 ms
На сам туннель приходится задержка в 55мс:
Code:
$ grep "Keepalive reply" /opt/var/log/gw6c.log | tail -4
2012/02/16 15:29:47 I gw6c: Keepalive reply received. Roundtrip time: 55.358ms
2012/02/16 15:30:17 I gw6c: Keepalive reply received. Roundtrip time: 55.322ms
2012/02/16 15:30:47 I gw6c: Keepalive reply received. Roundtrip time: 55.490ms
2012/02/16 15:31:17 I gw6c: Keepalive reply received. Roundtrip time: 55.467ms
Меня "видно" другим torrent-клиентам:
Code:
$ transmission-remote localhost:9091 --torrent 3 --peer-info \
| awk '{print $1 "\t" $4 "\t" $6}'
Address Down Client
2001:0:4137:9e76:cf0:10ec:cd78:bac3 0.0 BitTorrent
2001:0:4137:9e76:3067:29fa:4ed0:dcc2 0.0 µTorrent
2001:0:4137:9e76:34fd:38a5:a049:95f2 0.0 µTorrent
2001:41d0:1:335c::1 220.0 Transmission
2002:5e1a:a384::5e1a:a384 75.0 µTorrent
2a01:e0b:1:145:62eb:69ff:fe8f:183c 295.0 Transmission
2a01:e34:ec04:37d0:a596:7a02:b9c3:1469 6.0 µTorrent
2a02:9a0:7:846:f66d:4ff:fe5c:375b 216.0 Transmission
Если допустить, что ipv4.google.com и ipv6.google.com находятся в одном месте, то для меня путь через ipv6 до них длиннее. Сравним количество узлов:
Code:
$ traceroute -4 ipv4.google.com | tail -n 1 | awk '{print $1}'
8
$ traceroute -6 ipv6.google.com | tail -n 1 | awk '{print $1}'
14
Скорость работы тоннеля на 10% меньше ipv4 подключения. На моём 20-мегабитном канале:
Во время использования тоннеля на максимальной скорости обнаружить увеличение нагрузки на роутер не удалось, всё в порядке.
Upd 17.02 19:25. Расход памяти на работу пакета:
Code:
$ pmap -d `pidof radvd` | grep shared
mapped: 848K writeable/private: 156K shared: 0K
$ pmap -d `pidof gw6c` | grep shared
mapped: 9692K writeable/private: 6476K shared: 0K
В течение работы потребление памяти расти не должно. Демон по сути нужен только для присмотра над установленным туннелем, если вы демона убьёте, то туннель продолжит свою работу до первого сбоя. При старте демон авторизуется по SSL у туннельного брокера, получает XML-файл с настройками и передаёт настройки shell-скрипту подъёма туннеля /opt/share/gw6c/template/linux.sh.
Размер демона в памяти объясняется тем, что он написан на с++. Код открыт, поэтому, если переписать демон на чистом c, то он будет потреблять при работе 64 килобайта памяти, а не 6,4 мегабайта
Если же 6,4Мб памяти принципиально жалко, то можно действовать по следующему алгоритму:
- убивать демона gw6c сразу после успешного поднятия туннеля,
- организовать контроль состояния туннеля самому, например пингом раз в 30 секунд,
- в случае, если с тоннелем что-то не так, то запускать демона по новой. Скрипт настройки отработает корректно в т.ч. при смене адресов.
Позже выложу исправленный пакет и напишу мини-инструкцию по его использованию.
Reply With Quote
Originally Posted by TReX
