|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
01-Июл-18 14:49
(6 лет 7 месяцев назад, ред. 01-Июл-18 14:49)
Hannibal61 писал(а):
75604015потом пров мог что угодно сделать, а вы так и надеетесь на белый...
Ещё раз говорю что - нет. Я об этом сразу узнаю. Пров уведомляет, если что, услуга ведь платная.
|
|
|
|
maximus_lt
Стаж: 17 лет 7 месяцев Сообщений: 6126
|
maximus_lt ·
01-Июл-18 14:50
(спустя 1 мин.)
vlad_ns писал(а):
maximus_lt
А как определили? Там и лог наверно есть.
Есть суслик (SoulseekQt) я там иногда общаюсь в чате, вот в чате и идут сообщения. Но его не удобно использовать для лога, т.к. это Р2Р, расшарены папки, ест трафик, память и т.д.
|
|
|
|
Не сэнсэй
Стаж: 15 лет 10 месяцев Сообщений: 2075
|
Не сэнсэй ·
01-Июл-18 14:55
(спустя 5 мин., ред. 01-Июл-18 14:58)
vlad_ns писал(а):
75604048Я об этом сразу узнаю.
ну и какой у вас айпишник первые цифры до точки... в свойствах сети на компе показывает?...
адрес IPv4 какой?
|
|
|
|
yura_nn
Стаж: 16 лет 1 месяц Сообщений: 825
|
yura_nn ·
01-Июл-18 16:14
(спустя 1 час 18 мин., ред. 01-Июл-18 16:14)
maximus_lt писал(а):
75602105Не пинайте. Искал-искал подходящий раздел и не нашел (перекиньте если что), нужна программа, которая ведет лог переподключения интернета, что бы предоставить провайдеру.
Вам нужно просто опрашивать какой-нибудь сайт, с небольшими перерывами (чтобы ваши опросы за DOS атаку не приняли), и записывать это в текстовый файл. Можете воспользоваться этим скриптом:
Код:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import urllib.request
import time
import datetime
addr = "http://127.0.0.1"
def status_connection():
try:
urllib.request.urlopen(addr, timeout=1)
string_status = "Соединение есть: " + \
datetime.datetime.now().strftime('%d-%m-%Y %H:%M:%S') + '\n'
except Exception as err:
string_status = "Соединения нет: " + \
datetime.datetime.now().strftime('%d-%m-%Y %H:%M:%S') + '\n'
with open("log.txt", 'a') as fd:
fd.write(string_status)
def main():
n = True
while n is True:
status_connection()
time.sleep(60)
if __name__ == "__main__":
main()
В переменной addr нужно указать существующий сайт. В случае Windows '\n' может быть придется поменять на "\r\n".
|
|
|
|
maximus_lt
Стаж: 17 лет 7 месяцев Сообщений: 6126
|
maximus_lt ·
01-Июл-18 16:40
(спустя 26 мин.)
yura_nn писал(а):
75604456Вам нужно просто опрашивать какой-нибудь сайт
Это будет неуловимый Джо, т.к. переподключение происходит за 4сек. Оно бывает рандомным или периодами по 4 минуты, минуте.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
01-Июл-18 18:22
(спустя 1 час 41 мин.)
Не сэнсэй
Тролльте кого-нибудь другого...
|
|
|
|
rijh
Стаж: 13 лет Сообщений: 608
|
rijh ·
01-Июл-18 21:20
(спустя 2 часа 57 мин.)
vlad_ns писал(а):
75605059Тролльте кого-нибудь другого...
Вас не троллят,а задают вопросы.Вы общались с провайдером на эту тему???Не считайте себя всезнайкой.Если вам кажется,что всё хорошо,значит вы чего-то не видите.
|
|
|
|
Papant
Стаж: 17 лет 5 месяцев Сообщений: 56740
|
Papant ·
01-Июл-18 21:30
(спустя 10 мин.)
У некоторых провайдеров порты бывают недоступны даже при наличии внешнего адреса.
Один из вариантов - Защита от атак из интернета. Для доступности портов её надо было отключить.
Возможны и другие варианты в каждом конкретном случае. Если у провайдера есть форум - желательно посмотреть/спросить там.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
02-Июл-18 18:25
(спустя 20 часов)
rijh
А вы читайте с начала, я уже всё сказал и каждому повторять не собираюсь.
Papant
Провайдером только один порт закрыт, для почтовых программ, это то что я вижу в личном кабинете.
С провайдером общаться смысла не вижу, т.к. это ему в текущей ситуации не выгодно, трафик от меня возрастает значительно.
Вот https://rutr.life/forum/viewtopic.php?p=75600019#75600019 по поводу других портов. Ладно, повторюсь, у меня ещё открыты порты для http/ftp(s)/PMS серверов, stunnel, i2p всё это работает. Но именно порт для transmission не хочет, как я его не менял и брал из того диапазона тех служб (что я выше перечислил) для которых порты открыты. На основе этого я делаю вывод что порт для transmission может и не закрыт, но провайдер что-то делает с трафиков на этом порту. Я запускал и utorrent и уже об этом тоже писал, там ситуация такая же, встроенный тест говорит что порт закрыт. Всё началось с апреля, трафик с меня резко упал. Буквально на прошлой неделе всё само восстановилось дней на 5, может быть провайдер что-то делал.
|
|
|
|
maximus_lt
Стаж: 17 лет 7 месяцев Сообщений: 6126
|
maximus_lt ·
02-Июл-18 20:02
(спустя 1 час 36 мин.)
vlad_ns, спросите у провайдера, почему закрыты порты для uT и что изменилось с недавних пор с сетью, возможно вас запихнули за Nat.
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
03-Июл-18 14:53
(спустя 18 часов, ред. 03-Июл-18 14:53)
vlad_ns писал(а):
75609992rijh
А вы читайте с начала, я уже всё сказал и каждому повторять не собираюсь.
Papant
Провайдером только один порт закрыт, для почтовых программ, это то что я вижу в личном кабинете.
С провайдером общаться смысла не вижу, т.к. это ему в текущей ситуации не выгодно, трафик от меня возрастает значительно.
Вот https://rutr.life/forum/viewtopic.php?p=75600019#75600019 по поводу других портов. Ладно, повторюсь, у меня ещё открыты порты для http/ftp(s)/PMS серверов, stunnel, i2p всё это работает. Но именно порт для transmission не хочет, как я его не менял и брал из того диапазона тех служб (что я выше перечислил) для которых порты открыты. На основе этого я делаю вывод что порт для transmission может и не закрыт, но провайдер что-то делает с трафиков на этом порту. Я запускал и utorrent и уже об этом тоже писал, там ситуация такая же, встроенный тест говорит что порт закрыт. Всё началось с апреля, трафик с меня резко упал. Буквально на прошлой неделе всё само восстановилось дней на 5, может быть провайдер что-то делал.
У нас домра внедрила файервол и в конце года без предупреждения всем его подключила. Трафик тоже падал и не сразу сообразил, что вместо белого адреса (динамического) стал получать шаред (100.64/10).
Хорошо хоть оставили возможность отключить это счастье в личном кабинете.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
03-Июл-18 18:31
(спустя 3 часа)
maximus_lt писал(а):
75610450спросите у провайдера, почему закрыты порты для uT
Боюсь что в ответ будет какой-нибудь шаблонный ответ.
maximus_lt писал(а):
75610450возможно вас запихнули за Nat.
Видимо нужно повторять много раз, вот вывод команды ifconfig:
Код:
root@home-router:~# ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:92.255.ХХХ.ХХ P-t-P:10.91.255.126 Mask:255.255.255.255
inet6 addr: fe80::2047:576:d299:c349/10 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:1001734503 errors:0 dropped:0 overruns:0 frame:0
TX packets:1432950353 errors:0 dropped:2256 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:284844730833 (284.8 GB) TX bytes:1716660941828 (1.7 TB)
где в "inet addr" мой белый ip, который все в инете сервисы всякой проверки и показывают.
Cr0wer
А у вас если не секрет, был постоянный белый ip (в виде услуги)? Если нет, то это может быть и закономерно. У меня в личном кабинете ничего не изменилось, всё тоже. Я думаю что внедрили что-то типа dpi, т.к. у меня в принципе всё работает, просто порт не открывается/фильтруется для торрент-клиента, для всего остального только в путь. Я вообще, даже без услуги постоянного ip не видел у себя серых ip. Они были всегда белые, но динамические и совпадали с "inet addr" (писал выше), так же и в интернете виделись.
|
|
|
|
maximus_lt
Стаж: 17 лет 7 месяцев Сообщений: 6126
|
maximus_lt ·
04-Июл-18 02:17
(спустя 7 часов, ред. 04-Июл-18 02:17)
vlad_ns писал(а):
75614301просто порт не открывается/фильтруется для торрент-клиента, для всего остального только в путь.
Проверь тот же порт через PFPort Checker, будет понятно, настроен ли фильтр на uT клиент.
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
04-Июл-18 17:07
(спустя 14 часов, ред. 04-Июл-18 17:07)
vlad_ns писал(а):
75614301А у вас если не секрет, был постоянный белый ip (в виде услуги)?
...
Я думаю что внедрили что-то типа dpi, т.к. у меня в принципе всё работает, просто порт не открывается/фильтруется для торрент-клиента, для всего остального только в путь. Я вообще, даже без услуги постоянного ip не видел у себя серых ip. Они были всегда белые, но динамические и совпадали с "inet addr" (писал выше), так же и в интернете виделись.
Постоянный ip не покупал, но всегда получал белый ip, который выдавался динамически.
dpi в нашем улусе они внедрили больше года назад. blockcheck говорил что full dpi, а по трейсам было видно как "пассивный" dpi присылает поддельные RST раньше настоящих пакетов.
У меня тоже transmission, но на компе. Запустил wireshark, ткнул кнопку "Тест порта" и вижу: transmission делает http-запрос на специальный трансмишиновский сайт с "просьбой" проверить нужный порт. С той стороны на этот порт приходит tcp-запрос и соблюдая правила приличия обе стороны вежливо "здороваются" и "прощаются".
И даже не дожидаясь прощания трансмишеновский сайт уже отвечает на http-запрос, что всё ок.
При проверке порта все пакеты пустые и никакой полезной нагрузки не содержат. DPI в такой ситуации нечего ловить.
Если только не тупо блокировать сам трансмишеновский сайт или банить обращения к верхним портам, которые обычно используются битторентами.
Но смысл первого как-то ускользает - нахрена это провайдеру? А второе — не просто паскудство, а повод к многочисленным претензиям из-за неработоспособности совершенного другого софта. Тот же ftp использует аналогичный механизм.
Что-то тут не так.
Вроде что-то похожее было, когда на маршрутизаторе включил защиту от флуд-пакетов со слишком низким лимитом. Битторент их легко переплюнул и маршрутизатор стал отсеивать лишнее, устраивая локальный DOS.
В другой раз на самом компе через dmesg обнаружил "nf_conntrack: table full, dropping packet". Пришлось увеличивать *conntrack_max.
Но в во всех случаях сначала думал что это провайдер пакостит. 
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
04-Июл-18 18:20
(спустя 1 час 12 мин., ред. 04-Июл-18 18:20)
Cr0wer писал(а):
75618440dpi в нашем улусе они внедрили больше года назад. blockcheck говорил что full dpi, а по трейсам было видно как "пассивный" dpi присылает поддельные RST раньше настоящих пакетов.
Нет, я не про это. Оно не влияет на раздачу. Я имею ввиду что они тип трафика могут предположительно определять.
Cr0wer писал(а):
75618440нахрена это провайдеру?
А как же закон о сборе трафика? Провайдер его уменьшил, смысл есть. А то что торрент хуже стал работать, так это их особо и не волнует.
Cr0wer писал(а):
75618440Тот же ftp использует аналогичный механизм.
Ну в том то и дело, для остальных нужный порт отрывается.
Cr0wer писал(а):
75618440когда на маршрутизаторе включил защиту от флуд-пакетов со слишком низким лимитом.
Вы про это net.ipv4.tcp_syncookies?
Cr0wer писал(а):
75618440В другой раз на самом компе через dmesg обнаружил "nf_conntrack: table full, dropping packet". Пришлось увеличивать *conntrack_max.
Но в во всех случаях сначала думал что это провайдер пакостит.
Так у меня это схема 4 года работает, в том то и дело и проблемы этой не было.
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
05-Июл-18 10:27
(спустя 16 часов)
vlad_ns писал(а):
75618720
Cr0wer писал(а):
75618440dpi в нашем улусе они внедрили больше года назад. blockcheck говорил что full dpi, а по трейсам было видно как "пассивный" dpi присылает поддельные RST раньше настоящих пакетов.
Нет, я не про это. Оно не влияет на раздачу. Я имею ввиду что они тип трафика могут предположительно определять.
Битторент трафик определять, конечно-же, могут. Но Вы писали, что сам transmission при проверке порта обнаруживает, что он закрыт.
А отличить проверку открытия порта от начала другого соединения невозможно.
Поставьте все раздачи на паузу, смените порт, включите проверку открытости. Закрыт? Ну и как тогда провайдер может заранее узнать что будет на этот порт приходить, если он ещё новенький и на него пока ещё ничего не прилетало?
В передаваемых при тестировании пакетах нет никакой полезной нагрузки, поэтому соединение по типу трафика пока ещё не типизировано и повода его закрывать ещё нет. Закрывать всё подряд? Чревато. Если у интернет-зависимого перестанут грузиться танчики, он провайдеру горло перегрызёт.
А вот если тестирование на девственном порту пройдёт, а после первого трафика он заблокируется — это будет веский аргумент...
vlad_ns писал(а):
75618720
Cr0wer писал(а):
75618440нахрена это провайдеру?
А как же закон о сборе трафика? Провайдер его уменьшил, смысл есть. А то что торрент хуже стал работать, так это их особо и не волнует.
В этом есть резон, но в данном случает вопрос в том, ограничил ли провайдер доступ к тестирующему трансмишиновскому серверу и зачем это ему нужно. Трафик туда копеечный и вполне себе законный. На нём ничего не сэкономишь, зато потеряешь на разработке и внедрении.
Если бы порт тестировался как открытый, а полезный трафик p2p блокировался — это было бы уже похоже на меры противодействия.
vlad_ns писал(а):
75618720
Cr0wer писал(а):
75618440когда на маршрутизаторе включил защиту от флуд-пакетов со слишком низким лимитом.
Вы про это net.ipv4.tcp_syncookies?
У меня tplink с web-интерейсом, клацнул там чекбоксы на TCP-SYN Flood, UDP Flood and ICMP-Flood и оставил дефолтовые лимиты, решив что их должно хватить.
vlad_ns писал(а):
75618720
Cr0wer писал(а):
75618440В другой раз на самом компе через dmesg обнаружил "nf_conntrack: table full, dropping packet". Пришлось увеличивать *conntrack_max.
Но в во всех случаях сначала думал что это провайдер пакостит.
Так у меня это схема 4 года работает, в том то и дело и проблемы этой не было.
Я же навязываю, просто делюсь. Всегда может всё работать, а потом "бац!" — повышенный поток запросов, которые залепляют входящий порт и для последующих входящих он оказывается закрытым. У меня схема тоже работала несколько лет, а потом решил позапускать magnetico — пособирать коллекцию торрентов, вот и исчерпал conntrack_max.
|
|
|
|
Papant
Стаж: 17 лет 5 месяцев Сообщений: 56740
|
Papant ·
05-Июл-18 10:31
(спустя 4 мин.)
Cr0wer писал(а):
75621481Если бы порт тестировался как открытый, а полезный трафик p2p блокировался — это было бы уже похоже на меры противодействия.
Как я понимаю - при этом проблема только на раздаче, блокируются только входящие соединения..
Уж если бы блокировался торрент как протокол - блокировалось бы всё, и скачивание тоже.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
05-Июл-18 20:14
(спустя 9 часов, ред. 05-Июл-18 20:14)
Cr0wer писал(а):
75621481Поставьте все раздачи на паузу, смените порт, включите проверку открытости. Закрыт?
 Я это уже пробовал и уже выше писал об этом.
Cr0wer писал(а):
75621481что сам transmission при проверке порта обнаруживает, что он закрыт.
Да, но я не знаю алгоритма теста. Сервисы (в интернетах) говорят что трафик фильтруется. Поэтому точно не известно.
Cr0wer писал(а):
75621481Трафик туда копеечный и вполне себе законный.
Ну, логично предположить что провайдеру не нужен трафик от меня по 18 ТБ в месяц :). Вот в этом может быть проблема.
Вообще, что происходит, уточню. Когда всё нормально, на своём тарифе в 50 Мб, я часто вижу что скорость от меня доходит до 100 Мб, при этом раздач становиться больше, до 60-80 штук, чем больше, тем сильнее канал утилизируется. А в случае проблемы, я вижу что исходящий трафик от меня падает раза в два как минимум (редко больше 50 Мб), раздач становится 10-15 штук, по тесту transmission говорит что порт закрыт. Больше это ни на что не влияет. Началось это с апреля. Решил разобраться на прошлой неделе, т.к. в середине июня дней на 10 всё само восстановилось, вот и обнаружил что "порт закрыт". Сейчас, со вчерашнего дня всё нормализовалось, опять же само. Правда буквально позавчера заглючила внешняя карточка usb to ethernet dlink 1312, т.к. интернет вообще поломался. У меня поначалу возникла мысль что проблема может быть связана с этим (dropped росло). Но с одной стороны, всё началось намного раньше (апрель) и я переделал соединение (у меня это pppoe) на встройку, с другой эта переделка ничего не решила, всё осталось так же. Этот dlink не накрылся, как я в начале предположил, т.к. сильно нагрелся. На работе я его протестировал, да нагревается очень сильно но работает 200 ГБ инфы спокойно прокачал. Вчера я решил его поставить назад, после небольшой модернизации, наклеил небольшой радиатор на чип asix, радиатор греется до 60 градусов. Вернул соединение как было и всё заработало, попутно обновил ядро на 4.15, но это вряд ли с этим связано. Пока что всё до сих пор работает и порт открыт. Единственное я убавил скорость через qos исходящую и входящую до тарифной, может провайдер как-то на этом основывается, не знаю. Я не думаю что дело в железках, т.к. проблема началась за долго (апрель), другая сетевуха (встройка на мамке) не помогла.
Cr0wer писал(а):
75621481вот и исчерпал conntrack_max.
У меня он не исчерпаем :).
Papant писал(а):
75621503при этом проблема только на раздаче, блокируются только входящие соединения..
Да. На счёт блокируется, тут не ясно. поэтому я и просил как проверить, кроме как спросить у провайдера.
Papant писал(а):
75621503Уж если бы блокировался торрент как протокол - блокировалось бы всё, и скачивание тоже.
Вот об этом я не подумал. Тогда это убирает тень с провайдера. Почему я начал думать на прова, знаю что они это не любят (торренты), домру ранее был замечен в махинации с трафиком торрента, тут даже тема есть одного "пострадавшего"...
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
06-Июл-18 08:16
(спустя 12 часов)
vlad_ns писал(а):
75623644
Cr0wer писал(а):
75621481что сам transmission при проверке порта обнаруживает, что он закрыт.
Да, но я не знаю алгоритма теста. Сервисы (в интернетах) говорят что трафик фильтруется. Поэтому точно не известно.
Алгоритм теста transmission легко выясняется. Смотрим в исходник.
скрытый текст
Код:
static void
portTested (tr_session * session UNUSED,
bool did_connect UNUSED,
bool did_timeout UNUSED,
long response_code,
const void * response,
size_t response_byte_count,
void * user_data)
{
char result[1024];
struct tr_rpc_idle_data * data = user_data;
if (response_code != 200)
{
tr_snprintf (result, sizeof (result), "portTested: http error %ld: %s",
response_code, tr_webGetResponseStr (response_code));
}
else /* success */
{
const bool isOpen = response_byte_count && * (char*)response == '1';
tr_variantDictAddBool (data->args_out, TR_KEY_port_is_open, isOpen);
tr_snprintf (result, sizeof (result), "success");
}
tr_idle_function_done (data, result);
}
static const char*
portTest (tr_session * session,
tr_variant * args_in UNUSED,
tr_variant * args_out UNUSED,
struct tr_rpc_idle_data * idle_data)
{
const int port = tr_sessionGetPeerPort (session);
char * url = tr_strdup_printf ("http://portcheck.transmissionbt.com/%d", port);
tr_webRun (session, url, portTested, idle_data);
tr_free (url);
return NULL;
}
Кратко: идёт на portcheck.transmissionbt.com, сообщает номер порта и ждёт http-кода 200 - "ОК" с единицей теле ответа.
Что при этом делает portcheck.transmissionbt.com?
Для этого ставим эксперимент:
скрытый текст
Код:
No. Time Source Destination Protocol Length Info
2127 2.547388322 192.168.0.2 87.98.162.88 TCP 74 42560 → 80 [SYN] Seq=0 Len=0
2173 2.661711752 87.98.162.88 192.168.0.2 TCP 74 80 → 42560 [SYN, ACK] Seq=0 Ack=1 Len=0
2174 2.661784312 192.168.0.2 87.98.162.88 TCP 66 42560 → 80 [ACK] Seq=1 Ack=1 Len=0
2175 2.661868393 192.168.0.2 87.98.162.88 HTTP 217 GET /51413 HTTP/1.1
2211 2.776037142 87.98.162.88 192.168.0.2 TCP 66 80 → 42560 [ACK] Seq=1 Ack=152 Len=0
2213 2.776307784 87.98.162.88 192.168.0.2 TCP 74 60140 → 51413 [SYN] Seq=0 Len=0
2214 2.776369425 192.168.0.2 87.98.162.88 TCP 74 51413 → 60140 [SYN, ACK] Seq=0 Ack=1 Len=0
2330 2.890805976 87.98.162.88 192.168.0.2 TCP 66 60140 → 51413 [ACK] Seq=1 Ack=1 Len=0
2331 2.890851336 87.98.162.88 192.168.0.2 TCP 66 60140 → 51413 [FIN, ACK] Seq=1 Ack=1 Len=0
2332 2.891064258 87.98.162.88 192.168.0.2 HTTP 306 HTTP/1.1 200 OK (text/html)
2333 2.891090938 192.168.0.2 87.98.162.88 TCP 66 42560 → 80 [ACK] Seq=152 Ack=241 Len=0
2334 2.892984633 192.168.0.2 87.98.162.88 TCP 66 51413 → 60140 [ACK] Seq=1 Ack=2 Len=0
2598 3.365398314 192.168.0.2 87.98.162.88 TCP 66 51413 → 60140 [FIN, ACK] Seq=1 Ack=2
2704 3.479853506 87.98.162.88 192.168.0.2 TCP 66 60140 → 51413 [ACK] Seq=2 Ack=2 Len=0
Здесь и запрос клиента, и проверка порта сайтом. В ответе сайта та самая единичка, которую transmission ждёт.
Трейс снят на компе за маршрутизатором, поэтому локальный адрес. Клиент получает от маршрутизатора проброс порта посредством UPnP.
Вроде всё понятно.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
06-Июл-18 17:59
(спустя 9 часов)
Cr0wer
Да это не важно, это всего лишь точность формулировки. Transmission Remote GUI говорит что закрыт, сервисы проверки в интернете что фильтруется. Не суть, повлиять на это всё равно нельзя. Тем более всё это само по себе происходит. Сейчас вот до сих пор всё нормально, надолго ли?
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
06-Июл-18 19:58
(спустя 1 час 58 мин.)
vlad_ns писал(а):
75627727Cr0wer
Да это не важно, это всего лишь точность формулировки. Transmission Remote GUI говорит что закрыт, сервисы проверки в интернете что фильтруется. Не суть, повлиять на это всё равно нельзя.
Проблема понятна, но причина достоверно не устатовлена, поэтому ещё остаются возможности борьбы с ней.
В обсуждаемом случае имеет значение что закрытость порта не может быть следствием чисто блокировки битторент трафика. А поскольку в цепочке участвуют кроме провайдера роутер и сам SAN, я бы не исключал вариант что и они могут быть причастны к проблеме. Поэтому не мешало бы отрейсить "тест порта" когда он закрыт, а для сравнения — сейчас, когда открыт. Если на роутере, wireshark не запустить, то можно tcpdump или запустить и клиента, и трейсер на компе или ноуте.
Может некоторые адреса, выдаваемые провайдером, в каких-то делах засветились и где-то банятся или откуда-то флудятся/д?досятся. Тогда можно попробовать переустанавливать соединение до получения роутером "чистого" адреса.
А если провайдер молча на пропускает входящий трафик на верхние адреса независимо от типа трафика, можно попробовать какие-то из нижних, изображая из себя другой безобидный софт.
|
|
|
|
Papant
Стаж: 17 лет 5 месяцев Сообщений: 56740
|
Papant ·
06-Июл-18 20:48
(спустя 49 мин.)
Хорошо бы узнать, как обстоит с этим дело у соседей по провайдеру - через форум провайдера или в соцсетях. Или на каком-то ресурсе, где обсуждают интернет-провайдеров.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
07-Июл-18 01:45
(спустя 4 часа, ред. 07-Июл-18 01:45)
Cr0wer писал(а):
75628278SAN
А что это?
Cr0wer писал(а):
75628278Поэтому не мешало бы отрейсить "тест порта" когда он закрыт
Можно, но сторонние сервисы в интернете в этот момент тоже определяют что фильтруется.
Cr0wer писал(а):
75628278то можно tcpdump
Можно, надо смотреть как...
Cr0wer писал(а):
75628278Может некоторые адреса, выдаваемые провайдером, в каких-то делах засветились и где-то банятся или откуда-то флудятся/д?досятся. Тогда можно попробовать переустанавливать соединение до получения роутером "чистого" адреса.
Какие адреса? Если вы про внешний адрес, то я уже не раз говорил что он прежний. Порты пробовал разные, тоже уже писал. Порты для других служб открыты и доступны из вне.
Papant
К сожалению форум у них закрыт, в соцсетях не бываю. Есть знакомые на том же провайдере.
Когда порт закрыт/фильтруется, это сразу видно по количеству раздач и скорости отдачи, их в этот момент становится 10-15 штук, скорость падает до тарифной и даже ниже. Потом я проверяю из transmission порт и подтверждается что он закрыт. Когда всё нормально, количество одновременных раздач увеличивается до 50-80 штук и скорость раздач начинает упираться в скорость подключения. Вот видно как чётко упирается в установленное мной ограничение на 50 Мб, т.е. канал полностью утилизируется:
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
07-Июл-18 04:59
(спустя 3 часа, ред. 07-Июл-18 04:59)
Papant писал(а):
75628520Хорошо бы узнать, как обстоит с этим дело у соседей по провайдеру - через форум провайдера или в соцсетях. Или на каком-то ресурсе, где обсуждают интернет-провайдеров.
У меня провайдер тот-же, но может быть другой город/регион. В целенаправленном блокировании торрент-протокола провайдер пока не замечен. Поэтому и предлагал проверить причины закрытости порта другие нежели злонамеренная борьба с лишним трафиком.
vlad_ns писал(а):
75629643
Cr0wer писал(а):
75628278SAN
А что это?
Нарушение согласования полушарий мозга, левая рука отработала быстрее правой, отсутствовал авторский контроль мозгом за тем, что наклацали пальцы. Mea culpa.
Конечно-же, там должен был быть NAS.
|
|
|
|
Papant
Стаж: 17 лет 5 месяцев Сообщений: 56740
|
Papant ·
07-Июл-18 09:32
(спустя 4 часа)
Cr0wer писал(а):
75629806У меня провайдер тот-же, но может быть другой город/регион.
Более того - может зависеть от района или даже конкретного дома. На форуме моего прова как-то были странные жалобы из одного сегмента сети. Оказалось, что при замене какой-то сетевой железки - забыли внести туда нужные настройки, оставили дефолтные. Поэтому в пиковые часы железяка глючила.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
07-Июл-18 13:13
(спустя 3 часа)
Cr0wer писал(а):
75625583Для этого ставим эксперимент:
А не подскажите правильные настройки tcpdump, интерфейсы ppp0 (интернет), br0 (локальная сеть), ip nas 192.168.2.129, порт 51413?
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
07-Июл-18 18:40
(спустя 5 часов)
vlad_ns писал(а):
75631273
Cr0wer писал(а):
75625583Для этого ставим эксперимент:
А не подскажите правильные настройки tcpdump, интерфейсы ppp0 (интернет), br0 (локальная сеть), ip nas 192.168.2.129, порт 51413?
Зависит от того что и где хотите отловить. Если только обращение к сайту и проверка им порта, то проще так:
Код:
tcpdump -s 1500 -w trace.pcap host portcheck.transmissionbt.com
Если маршрутизатор отказывается писать в файл (типа некуда), можно вывести прямо в консоль — без параметра "-w файл".
Вывод лаконичный. Для более подробного можно добавить "-v".
Можно уточнить интерфейс, если по-умолчанию выбирает не тот что надо: "-i br0".
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
08-Июл-18 11:23
(спустя 16 часов, ред. 08-Июл-18 11:23)
Cr0wer
скрытый текст
Код:
.ò.......................A[.E..J...J...D.[......)....E..<H.@.@.5.....Wb.X...PbL........r.U{.........
.V............A[
F..J...J......)..D.[.....E..<..@.@.}.Wb.X.....P...ʻ.bL....q ...........
?....V........A[.F..B...B...D.[......)....E..4H.@.@.5.....Wb.X...PbL...ʻ............
.V..?.....A[
G..........D.[......)....E...H @.@.5)....Wb.X...PbL...ʻ............
.V..?...GET /51413 HTTP/1.1
User-Agent: Transmission/2.84
Host: portcheck.transmissionbt.com
Accept: */*
Accept-Encoding: gzip;q=1.0, deflate, identity
..A[1G..B...B......)..D.[.....E..4.X@.@...Wb.X.....P...ʻ.bL.......
.....
?....V....A[..
.J...J......)..D.[.....Ep.<.T@.4...Wb.X........M.........r.R}.........
&S.A..........A[E.
.J...J...D.[......)....E..<..@.@.}.....Wb.X.թ...p.M.....q Kw.........
.V..&S.A......A[....B...B......)..D.[.....Ep.4.U@.4...Wb.X........M.....pɀ....k.....
&S.T.V....A[....B...B......)..D.[.....Ep.4.V@.4...Wb.X........M.....pɀ....j.....
&S.T.V....A[....B...B...D.[......)....E..4..@.@.......Wb.X.թ...p.M........X.....
.V.,&S.T..A[|B..<...<......)..D.[.....E....Y@.@...Wb.X.....P...ʻ.bL.............
?....V..HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Sun, 08 Jul 2018 08:14:28 GMT
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 1
X-Cache: MISS from home-router
X-Cache-Lookup: HIT from home-router:3128
Connection: keep-alive
..A[.B..B...B...D.[......)....E..4H!@.@.5.....Wb.X...PbL...ʼ............
.V..?.....A[.D..C...C......)..D.[.....E..5.Z@.@...Wb.X.....P...ʼ.bL.............
?....V..1..A[aD..B...B...D.[......)....E..4H"@.@.5.....Wb.X...PbL...ʼ............
.V..?.....A['...B...B...D.[......)....E..4..@.@.......Wb.X.թ...p.M..............
.V..&S.T..A[#...B...B......)..D.[.....Ep.4S.@.4.6WWb.X........M.....pʀ....C.....
&S...V....A[=B..B...B...D.[......)....E..4H#@.@.5.....Wb.X...PbL...ʼ......0.....
.V..?.....A[.B..B...B......)..D.[.....E..4.[@.@...Wb.X.....P...ʼ.bL.......
.....
?....V....A[.C..B...B...D.[......)....E..4H$@.@.5.....Wb.X...PbL...ʼ............
.V..?...
Т.к. пока всё нормально, то и вывод правильный. Если вывод делаю в консоль, то он другой, вот такой:
скрытый текст
Код:
root@home-router:~# tcpdump -s 1500 -i br0 host portcheck.transmissionbt.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 1500 bytes
11:21:01.395493 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [S], seq 3293655608, win 29200, options [mss 1460,sackOK,TS val 207124370 ecr 0,nop,wscale 7], length 0
11:21:01.395551 IP vm4.transmissionbt.com.http > home-nas.home-router.loc.40906: Flags [S.], seq 1600965927, ack 3293655609, win 28960, options [mss 1460,sackOK,TS val 1073646459 ecr 207124370,nop,wscale 7], length 0
11:21:01.395721 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 207124370 ecr 1073646459], length 0
11:21:01.395895 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [P.], seq 1:152, ack 1, win 229, options [nop,nop,TS val 207124370 ecr 1073646459], length 151: HTTP: GET /51413 HTTP/1.1
11:21:01.395917 IP vm4.transmissionbt.com.http > home-nas.home-router.loc.40906: Flags [.], ack 152, win 235, options [nop,nop,TS val 1073646460 ecr 207124370], length 0
11:21:01.557764 IP vm4.transmissionbt.com.46212 > home-nas.home-router.loc.51413: Flags [S], seq 3122939025, win 29200, options [mss 1460,sackOK,TS val 643125732 ecr 0,nop,wscale 7], length 0
11:21:01.558102 IP home-nas.home-router.loc.51413 > vm4.transmissionbt.com.46212: Flags [S.], seq 3567379287, ack 3122939026, win 28960, options [mss 1460,sackOK,TS val 207124411 ecr 643125732,nop,wscale 7], length 0
11:21:01.680203 IP vm4.transmissionbt.com.46212 > home-nas.home-router.loc.51413: Flags [.], ack 1, win 229, options [nop,nop,TS val 643125763 ecr 207124411], length 0
11:21:01.680216 IP vm4.transmissionbt.com.46212 > home-nas.home-router.loc.51413: Flags [F.], seq 1, ack 1, win 229, options [nop,nop,TS val 643125763 ecr 207124411], length 0
11:21:01.684265 IP home-nas.home-router.loc.51413 > vm4.transmissionbt.com.46212: Flags [.], ack 2, win 227, options [nop,nop,TS val 207124443 ecr 643125763], length 0
11:21:01.690417 IP vm4.transmissionbt.com.http > home-nas.home-router.loc.40906: Flags [P.], seq 1:251, ack 152, win 235, options [nop,nop,TS val 1073646754 ecr 207124370], length 250: HTTP: HTTP/1.1 200 OK
11:21:01.690455 IP vm4.transmissionbt.com.http > home-nas.home-router.loc.40906: Flags [P.], seq 251:252, ack 152, win 235, options [nop,nop,TS val 1073646754 ecr 207124370], length 1: HTTP
11:21:01.690515 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [.], ack 251, win 237, options [nop,nop,TS val 207124444 ecr 1073646754], length 0
11:21:01.690540 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [.], ack 252, win 237, options [nop,nop,TS val 207124444 ecr 1073646754], length 0
11:21:02.149457 IP home-nas.home-router.loc.51413 > vm4.transmissionbt.com.46212: Flags [F.], seq 1, ack 2, win 227, options [nop,nop,TS val 207124559 ecr 643125763], length 0
11:21:02.231589 IP vm4.transmissionbt.com.46212 > home-nas.home-router.loc.51413: Flags [.], ack 2, win 229, options [nop,nop,TS val 643125901 ecr 207124559], length 0
11:21:16.055159 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [F.], seq 152, ack 252, win 237, options [nop,nop,TS val 207128035 ecr 1073646754], length 0
11:21:16.055247 IP vm4.transmissionbt.com.http > home-nas.home-router.loc.40906: Flags [F.], seq 252, ack 153, win 235, options [nop,nop,TS val 1073661119 ecr 207128035], length 0
11:21:16.055452 IP home-nas.home-router.loc.40906 > vm4.transmissionbt.com.http: Flags [.], ack 253, win 237, options [nop,nop,TS val 207128035 ecr 1073661119], length 0
11:23:01.177348 IP home-nas.home-router.loc.51413 > vm4.transmissionbt.com.6881: UDP, length 97
11:23:01.263217 IP vm4.transmissionbt.com.6881 > home-nas.home-router.loc.51413: UDP, length 277
|
|
|
|
Cr0wer
Стаж: 12 лет 10 месяцев Сообщений: 161
|
Cr0wer ·
08-Июл-18 13:01
(спустя 1 час 37 мин.)
vlad_ns писал(а):
75635623Т.к. пока всё нормально, то и вывод правильный. Если вывод делаю в консоль, то он другой, вот такой:
...
Всё правильно. При выводе на консоль бинарное содержимое пакетов не отображается, выводится последовательность передачи пактов и она важна. Содержимое можно увидеть в хексе и ascii с параметром "-X", но вполне достаточно и "-vv".
При проблеме с закрытым портом лучше будет трассировать интерфейс ppp0. Заодно будет исключён прокси на роутере.
Отсутствие какого-нибудь из первого десятка пакетов может многое сказать о характере проблемы, а при вредительстве со стороны dpi могут появиться лишние.
|
|
|
|
vlad_ns
Стаж: 14 лет 11 месяцев Сообщений: 1755
|
vlad_ns ·
08-Июл-18 19:32
(спустя 6 часов)
Cr0wer писал(а):
75636054При проблеме с закрытым портом лучше будет трассировать интерфейс ppp0. Заодно будет исключён прокси на роутере.
Ну прокси я исключаю, т.к. все (вся локальная сеть) по любому через него ходят и nas не исключение. Но я всё равно посмотрел через ppp0, разница в том что внешнее dns имя вместо локального, а так в целом тоже самое. Жду часа х.
|
|
|
|
