 |
Обход блокировки сотовыми операторами использования смартфона в качестве точки доступа |
[комментарии]
|
| | Некоторые сотовые операторы начали вводить в практику блокировку или замедление
доступа для соединений, установленных со сторонних устройств, подключающихся
через смартфон, работающий в режиме точки доступа ("tethering").
Как правило подобные блокировки основываются на привязке к TTL и обойти их
можно увеличив TTL с 64 до 65, что скроет наличие дополнительного хоста в цепочке.
В системах на базе ядра Linux:
sysctl net.ipv4.ip_default_ttl=65
Во FreeBSD:
sysctl net.inet.ip.ttl=65
Изменить TTL для транзитных пакетов в Linux можно при помощи пакетного фильтра:
iptables -t mangle -A POSTROUTING -o usb0 -j TTL --ttl-set 65
|
| |
 |
|
|
Решение проблемы с uTP-протоколом uTorrent (доп. ссылка 1) |
Автор: Zzz
[комментарии]
|
| | По многочисленным наблюдениям системных администраторов различных компаний предоставляющих доступ к сети интернет, с начала февраля 2010 года наблюдается ежедневный лавинообразный рост количества пакетов в сети, их фрагментация, а также существенный рост исходящего трафика. Данная проблема связана с новой версией торрент-клиента uTorrent вышедшего 3 февраля 2010 года с поддержкой протокола uTP, работающего поверх UDP. Призванный снизить нагрузку на провайдеров протокол uTP в результате привел к обратному эффекту.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Tshark для мониторинга запросов http (доп. ссылка 1) |
Автор: CHAPPAY
[комментарии]
|
| | Tshark из комплекта сниффера Wireshark (http://www.wireshark.org/) позволяет наглядно проследить запросы к http-серверу.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Решение проблемы с крахом Net-SNMP |
[обсудить]
|
| | В один прекрасный момент Net-SNMP начал слетать с оставлением в логе ошибки:
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
|
|
Как увеличить размер таблицы контроля сессий ip_conntrack в Linux |
[комментарии]
|
| | Если ядро ругается "kernel: ip_conntrack: table full, dropping packet.", причину флуда
(скорее всего вирус или сканирование портов) можно найти по списку /proc/net/ip_conntrack
Если просто общая загрузка большая, увеличить размер таблицы можно через /proc/sys/net/ipv4/ip_conntrack_max
Также можно увеличить размерность хэша через параметр hashsize модуля ip_conntrack:
/etc/modules.conf:
options ip_conntrack hashsize=N
Более тонкий тюнинг можно произвести через переменные определенные в /proc/sys/net/ipv4/netfilter
|
| |
|
|
|
Примеры использования ngrep для выборки и просмотра содержимого пакетов (доп. ссылка 1) |
Автор: Mayank Sharma
[комментарии]
|
| | ngrep служит для отображения проходящих сетевых пакетов удовлетворяющих заданной маске.
Как мне кажется ngrep гораздо проще и удобнее, чем tcpdump. Вот несколько примеров:
Показать содержимое всех пакетов, прошедших по 80 порту, со словом google
ngrep google port 80
Вывод пакетов удовлетворяющих маске по одному в строке, для интерфейса eth0:
ngrep -i \'game*|chat|recipe\' -W byline -d eth0
Слушать весь SMTP трафик на всех сетевых интерфейсах:
ngrep -i \'rcpt to|mail from\' -d any tcp port smtp
Показать текущее время для каждого совпадения (кто и когда заходит на машину телнетом):
ngrep -q -t -wi "login" port 23
|
| |
|
|
|
Почему в FreeBSD 5.3 не работает форвадинг пакетов (ipfw fwd) (доп. ссылка 1) |
Автор: Bushi
[комментарии]
|
| | Это ошибка в FreeBSD 5.3, патч здесь:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71910
|
| |
|
|
|
Как сгенерировать IPv6 пакет для отладки сети. (доп. ссылка 1) |
[обсудить]
|
| | # netwox 142 --device "Eth0" --eth-dst "0:8:9:a:b:c" --ip6-src "fec0:0:0:1::1"
--ip6-dst "fec0:0:0:1::2" --tcp-src "1234" --tcp-dst "80" --tcp-syn
# netwox 142 --device "Eth0" --eth-src "00:11:22:33:44:55" --eth-dst "0:8:9:a:b:c"
--ip6-src "fec0:0:0:1::1" --ip6-dst "fec0:0:0:1::2" --tcp-src "1235" --tcp-dst "80" --tcp-syn
142 - код операции "Spoof EthernetIp6Tcp", netwox - http://laurentconstantin.by.ru/ru/
|
| |
|
|
|
Почему при использовании туннеля возникают проблемы с некоторыми хостами. (доп. ссылка 1) |
[комментарии]
|
| | Выход - поставить на интерфейсе туннеля MTU 1500, вместо 1476.
Проблема возникает при попытке протолкнуть пакет размером 1500 байт
с выставленным DF (don't fragment запрещена фрагментация) битом через интерфейс 1476 байт.
Другие решения:
interface ethernet0
ip policy route-map clear-df
route-map clear-df permit 10
match ip address 101
set ip df 0
access-list 101 permit tcp 10.1.3.0 0.0.0.255 any
или
interface tunnel0
ip tcp adjust-mss 1436
|
| |
|
|
|
В чем может быть причина неработы ассиметричного рутинга под Linux. (доп. ссылка 1) |
[обсудить]
|
| | Linux отказывается маршрутизировать пакеты между двумя сетевыми
картами, кода пакет входит через один интерфейс и выходит через другой, если
включен rp_filter (RFC1812).
Необходимо отключить rp_filter:
/sbin/sysctl -w net.ipv4.conf.default.rp_filter = 0
/sbin/sysctl -w net.ipv4.conf.all.rp_filter = 0
Для FreeBSD можно посоветовать:
в /etc/rc.conf: tcp_extensions="NO"
или sysctl -w net.inet.tcp.rfc1323=0
А так же sysctl -w net.inet.tcp.rfc1644=1 и sysctl -w net.inet.tcp.rfc1323=0
|
| |
|
|
|
С чем может быть связаны потери пакетов и нестабильная работа ethernet карт ? (доп. ссылка 1) |
[комментарии]
|
| | Приходилось сталкиваться с проблемами согласования режимов работы карт Intel EtherExpress 100 и
Reltek RTL-8139 c коммутаторами и концентраторами различных производителей. Несогласование
проявляется, например в работе карты в режиме half-duplex, а свича в
full-duplex и т.д. (в linux: /sbin/mii-tool -F 100baseTx-FD eth0)
|
| |
|
|
|
Почему выкачиваются данные с машины нормально, как только пытаюсь что-то закачать - соединение останавливается, даже через ssh больше 5 мин. не удается поработать. Другие машины работают нормально. |
[комментарии]
|
| | Неоднократно замечена проблема работы сетевых карт на базе RealTek 8129/8139 (машины под FreeBSD,
но с другими ОС тоже проявляется) с некоторыми концентраторами и коммутаторами.
Проявляется в замирании сессий до истечения таймаута.
Диагностика: ping -s N remote_ip, при больших N не проходят.
Решение: Смените сетевую карту, например, на Intel EtherExpress Pro.
|
| |
|
|
|
Почему лог почтового сервера изобилует сообщениями о разрыве по Timeout, часто, при приеме большого объема данных, прокачка останавливается и замирает до истечения таймаута ? |
[комментарии]
|
| | Вероятные причины: Туннель, блокировка ICMP, "path MTU discovery" и ECN
(Explicit Congestion Notification,
ECN проявляется в основном при доступе через Proxy).
При блокировке ICMP трафика, возможно блокируется не только
echo_replay/echo_request ICMP сообщения,
но и другие важные сообщения
передаваемые по ICMP. При блокировке ICMP сообщений типа 3.4 (fragmentation
needed and DF set) возможно
нарушение нормальной фрагментации пакетов, что вполне может проявляться как
внезапная остановка передачи
данных большого объема и разрыв сесcии по таймауту, например, если на пути
трафика встречается туннель.
Одним из путей решением проблемы, является установка на туннеле MTU > 1500 и
отмена блокировки ICMP трафика.
Проблемы с ECN в Linux лечатся:
echo 0 >/proc/sys/net/ipv4/tcp_ecn
path MTU discovery:
Linux: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
FreeBSD: sysctl -w net.inet.tcp.rfc1323=0
|
| |
|
|
