Видеоролик о том, почему Windows на нетбуке это плохо
В ролике хочу показать контраст в скорости работы между Windows и Linux, думаю мне это удалось. Винда очень тяжко ворочается на нетбуках с Intel Atom, сжирая половину оперативки только под свои нужды. Людям которые никогда не видели ничего другого кроме винды и привыкли к ее тормозам будет очень полезно посмотреть, что тормоза интерфейса и привычное потребление ресурсов в семерочке не является нормальным априори. Даже в состоянии покоя Windows вдруг начинает выполнять какие то действия о которых ее никто не просил загружая при этом оба ядра процессора что называется "по полной"
Характеристики нетбуков:
- Lenovo S10 - 3C - Windows Se7en Starter Edition (x86), Intel Atom N455, DDR III (1Gb)
После загрузки занято 500Мб RAM
- Asus Eee PC 1001 PX - Gentoo Linux amd64 (pure 64bit), Intel Atom N450, DDR II (1Gb)
После загрузки занято 44Мб (сорок четыре) RAM.
проходит, но как-то мало и только в том случае. если я открываю приложение, его использующее и делаю "тест порта"
(^C в конце - это я остановил его прослушку Ctrl+C)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:05:29.856431 IP 192.168.0.83.50621 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 2377001023, win 7300, options [mss 1460,sackOK,TS val 23248130 ecr 0,nop,wscale 0], length 0
23:05:29.858931 IP 192.168.0.83.57909 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 723047712, win 7300, options [mss 1460,sackOK,TS val 23248131 ecr 0,nop,wscale 0], length 0
23:05:49.081387 IP 192.168.0.83.37077 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 745499159, win 7300, options [mss 1460,sackOK,TS val 23252936 ecr 0,nop,wscale 0], length 0
23:05:55.139907 IP 192.168.0.83.56478 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 3914599992, win 7300, options [mss 1460,sackOK,TS val 23254451 ecr 0,nop,wscale 0], length 0
23:05:55.142054 IP 192.168.0.83.37568 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 1637092155, win 7300, options [mss 1460,sackOK,TS val 23254452 ecr 0,nop,wscale 0], length 0
23:05:55.142632 IP 192.168.0.83.45784 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 3836859802, win 7300, options [mss 1460,sackOK,TS val 23254452 ecr 0,nop,wscale 0], length 0
23:05:55.142964 IP 192.168.0.83.34000 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 217328987, win 7300, options [mss 1460,sackOK,TS val 23254452 ecr 0,nop,wscale 0], length 0
23:06:28.859034 IP 192.168.0.83.37515 > broadband-90-154-67-102.nationalcablenetworks.ru.3002: Flags [S], seq 122968871, win 7300, options [mss 1460,sackOK,TS val 23262881 ecr 0,nop,wscale 0], length 0
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Видны только исходящие пакеты.
Нужно локализовать проблему.
Попробуйте сделать
После этого запустите tcpdump с теми же параметрами. Если входящие пакеты будут приходить, то проблема конкретно в iptables. Если нет, то смотрите модем/роутер.
Но скорее всего роутер, так как tcpdump прослушивает интерфейс еще так сказать до файрвола. Может DNAT не настроен на роутере и пакеты приходящие на ваш белыйIP:3002 никуда не натится, а пропадает еще в модеме?
по-моему ничего не изменилось
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:12:22.328830 IP 192.168.0.83.53521 > broadband-90-154-67-42.nationalcablenetworks.ru.3002: Flags [S], seq 3997548182, win 7300, options [mss 1460,sackOK,TS val 7290990 ecr 0,nop,wscale 0], length 0
18:12:22.329025 IP 192.168.0.83.55195 > broadband-90-154-67-42.nationalcablenetworks.ru.3002: Flags [S], seq 3566243189, win 7300, options [mss 1460,sackOK,TS val 7290990 ecr 0,nop,wscale 0], length 0
18:12:22.330612 IP 192.168.0.83.54074 > broadband-90-154-67-42.nationalcablenetworks.ru.3002: Flags [S], seq 3743619715, win 7300, options [mss 1460,sackOK,TS val 7290991 ecr 0,nop,wscale 0], length 0
18:12:22.332395 IP 192.168.0.83.49095 > broadband-90-154-67-42.nationalcablenetworks.ru.3002: Flags [S], seq 609924175, win 7300, options [mss 1460,sackOK,TS val 7290991 ecr 0,nop,wscale 0], length 0
18:12:22.333585 IP 192.168.0.83.50023 > broadband-90-154-67-42.nationalcablenetworks.ru.3002: Flags [S], seq 2016903854, win 7300, options [mss 1460,sackOK,TS val 7290992 ecr 0,nop,wscale 0], length 0
18:12:28.339394 IP 192.168.0.83.42273 > broadband-90-154-67-42.nationalcablenetworks.ru.3002: Flags [S], seq 3466174799, win 7300, options [mss 1460,sackOK,TS val 7292493 ecr 0,nop,wscale 0], length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel
я вот что скажу
что не ковыряться в iptables ручками я поставил gufw и через него прописал правило: в/из 3002,3001,3000 разрешить всё что угодно (файерволл мне кстати постоянно показывает, что он пропускает пакеты от программ, которые я запускаю по разрешённому порту, а система, если я повешу 2 программы на 1 порт и сразу же их запущу - тут же ругается, что логично) + прицепом прописал правило для разрешения движения по этим портам в модеме (dlink dir-620) согласно инструкции на сайте. Это не помогло. Но потом, когда я удалил эти правила в роутере, прописал их заново и сделал DMZ - 1 порт из 3х заработал. Потом я не пользовался DC++ и недавно просто врубил его - и уже ничего не работало. Я не знаю -виноват ли роутер или у меня руки кривые, но я пробовал прокинуть порты через форточки (2ой ос стоит) - там та же история - порт закрыт. Со стороны провайдера никаких ограничений нет (кроме 139 и ещё ряда известных для атак портов), может это dlink кривой, может ОС надо снести и заново поставить xubuntu я не знаю, но вот - правила не работают и порты закрыты.
Давайте по порядку.
Вы удалили цепочки как я говорил?
Для проверки потом можно запустить
В выводе должно быть показаны цепочки, но без правил. После этого iptables не оказывает никакое влияние на трафик.
Далее поясню. Если соединение поднимает роутер и после отключения iptables у вас по прежнему не работает, то проблема либо в роутере, либо в провайдере.
Чтобы заработало необходимо дать доступ извне какой то подсети (или любым внешним клиентам) доступ к tcp/3002 и udp/3002. Посмотрите в веб морде роутера, это должно быть. И после вам нужно снатить ваш белый (скажем 1.1.1.1:3002) на локальную машину (192.168.0.83:3002).
Скорее всего у вас либо нет ната, либо внешним клиентам тупо не дано разрешение на доступ к нужным для DC портам.
Давайте по порядку
я выполнил
tcpdump -i 'имя интерфейса' -p tcp and port 3002
результат - выше - ничего не пропускает ТСП
потом я забыл выполнить тоже самое по UDP
вот UDP работает- запустил торрент и он (пара строчек, они однотипные)
23:32:01.706722 IP 192.168.0.83.3002 > 176.120.44.38.40357: UDP, length 20
23:32:01.706779 IP 192.168.0.83.3002 > 77.51.146.219.47689: UDP, length 20
580 packets captured
907 packets received by filter
74 packets dropped by kernel
далее я даю команды
iptables -F
потом
iptables -P input ACCEPT
и результат
iptables: Bad built-in chain name.
а вот результат от
iptables -L -n --line
Chain INPUT (policy ACCEPT)
num target prot opt source destination
Chain FORWARD (policy DROP)
num target prot opt source destination
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain ufw-after-forward (0 references)
num target prot opt source destination
Chain ufw-after-input (0 references)
num target prot opt source destination
Chain ufw-after-logging-forward (0 references)
num target prot opt source destination
Chain ufw-after-logging-input (0 references)
num target prot opt source destination
Chain ufw-after-logging-output (0 references)
num target prot opt source destination
Chain ufw-after-output (0 references)
num target prot opt source destination
Chain ufw-before-forward (0 references)
num target prot opt source destination
Chain ufw-before-input (0 references)
num target prot opt source destination
Chain ufw-before-logging-forward (0 references)
num target prot opt source destination
Chain ufw-before-logging-input (0 references)
num target prot opt source destination
Chain ufw-before-logging-output (0 references)
num target prot opt source destination
Chain ufw-before-output (0 references)
num target prot opt source destination
Chain ufw-logging-allow (0 references)
num target prot opt source destination
Chain ufw-logging-deny (0 references)
num target prot opt source destination
Chain ufw-not-local (0 references)
num target prot opt source destination
Chain ufw-reject-forward (0 references)
num target prot opt source destination
Chain ufw-reject-input (0 references)
num target prot opt source destination
Chain ufw-reject-output (0 references)
num target prot opt source destination
Chain ufw-skip-to-policy-forward (0 references)
num target prot opt source destination
Chain ufw-skip-to-policy-input (0 references)
num target prot opt source destination
Chain ufw-skip-to-policy-output (0 references)
num target prot opt source destination
Chain ufw-track-forward (0 references)
num target prot opt source destination
Chain ufw-track-input (0 references)
num target prot opt source destination
Chain ufw-track-output (0 references)
num target prot opt source destination
Chain ufw-user-forward (0 references)
num target prot opt source destination
Chain ufw-user-input (0 references)
num target prot opt source destination
Chain ufw-user-limit (0 references)
num target prot opt source destination
Chain ufw-user-limit-accept (0 references)
num target prot opt source destination
Chain ufw-user-logging-forward (0 references)
num target prot opt source destination
Chain ufw-user-logging-input (0 references)
num target prot opt source destination
Chain ufw-user-logging-output (0 references)
num target prot opt source destination
Chain ufw-user-output (0 references)
num target prot opt source destination
Оттого, что GNU/Linux так сказать регистрозависимая ОС. 'INPUT' и 'input' - разные вещи. Но у Вас видно, что
это значит политика по умолчанию для входящего трафика - пропускать пакеты.
Теперь с IP. TCP не оказалось скорее всего потому, что торрент клиент использует по умолчанию UDP, а не TCP.
Но опять же, это все _исходящие_ пакеты от вашей локальной машины, а входящих нет. Причем они не доходят даже до интерфейса вашей машины. Проблема в роутере. В доступе к портам извне, либо в НАТ.
Проверьте правильность проброски и доступа к портам на роутере.
ТСП торрент мог и не использовать,я тоже думал в ту сторону, но его должно быть, использует DC++ - т к в нём оба порта настраиваются явно
с пробросом портов всё должно быть в порядке
ну, я имею ввиду, что я сделал по инструкции к модему
http://www.dlink.ru/ru/faq/233/1033.html
и более того - как и писал выше - делал ему DMZ
а чего нужно делать с НАТом? Там динамические адреса, которые раздаются на все устройства
Как что делать? Проброс должен быть явный. белый адрес порт натится в серый адрес порт. например 1.1.1.1:3002 -> 192.168.0.83:3002. Нат с динамическими адресами это бред.Установите на целевой машине (где запущен DC) статику и скорее всего ваши волосы станут мягкими и шелковистыми)
статический белый адрес брать? а зачем? DC автоматом обновляет внешний (белый) IP при подключении
блин, как-то это всё работало раньше
Так у вас уже белый есть адрес, вам его провайдер дает. Не надо ничего больше брать.
Я не знаю как еще проще объяснить.