LINUX.ORG.RU
ФорумAdmin

Возможны ли такие блокировки 80-го порта?

 , ,


0

1

Всех приветствую.

Поднял на digital ocean сервер. Накатил nginx. Всё отлично, всё работает. Потом решил поделиться ссылкой на свежеподнятый ресурс в телеграм, туда попытался сходить telegrambot, и всё. После этого ресурс по 80-му порту не отвечает. При этом, если пытаться открыть его в обход (через прокси, анонимайзеры, впн), то всё отлично работает. Напрямую работать перестал. Однако, если nginx перевесить на любой другой порт, то опять же - работает, так же работает и ssh на 22-м порту.

Стал разбираться в вопросе, попробовал посмотреть, что мне скажет:

$ sudo tcpdump -nvvi any dst port 80
И, как ни странно, но пакеты какие-то приходят. Что-то в этом духе:
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:41:47.776241 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63073 > 206.189.14.89.80: Flags [S], cksum 0xa6bf (correct), seq 3691586037, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410217700 ecr 0,sackOK,eol], length 0
10:41:48.028833 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63074 > 206.189.14.89.80: Flags [S], cksum 0xd905 (correct), seq 2828804640, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410217951 ecr 0,sackOK,eol], length 0
10:41:48.780835 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63073 > 206.189.14.89.80: Flags [S], cksum 0xa2d7 (correct), seq 3691586037, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410218700 ecr 0,sackOK,eol], length 0
10:41:49.034858 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63074 > 206.189.14.89.80: Flags [S], cksum 0xd51d (correct), seq 2828804640, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410218951 ecr 0,sackOK,eol], length 0
10:41:49.783256 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63073 > 206.189.14.89.80: Flags [S], cksum 0x9eef (correct), seq 3691586037, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410219700 ecr 0,sackOK,eol], length 0
10:41:50.035957 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63074 > 206.189.14.89.80: Flags [S], cksum 0xd135 (correct), seq 2828804640, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410219951 ecr 0,sackOK,eol], length 0
10:41:50.786591 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63073 > 206.189.14.89.80: Flags [S], cksum 0x9b07 (correct), seq 3691586037, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410220700 ecr 0,sackOK,eol], length 0
10:41:51.038744 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63074 > 206.189.14.89.80: Flags [S], cksum 0xcd4d (correct), seq 2828804640, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410220951 ecr 0,sackOK,eol], length 0
10:41:51.792429 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63073 > 206.189.14.89.80: Flags [S], cksum 0x971f (correct), seq 3691586037, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410221700 ecr 0,sackOK,eol], length 0
10:41:52.044462 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63074 > 206.189.14.89.80: Flags [S], cksum 0xc965 (correct), seq 2828804640, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410221951 ecr 0,sackOK,eol], length 0
10:41:52.799409 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63073 > 206.189.14.89.80: Flags [S], cksum 0x9337 (correct), seq 3691586037, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 410222700 ecr 0,sackOK,eol], length 0
И так бесконечно, пока бразуер не скажет, что не смог подключиться. Если посмотреть то же самое, но через VPN:
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:42:52.250145 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    185.125.168.87.63104 > 206.189.14.89.80: Flags [SEW], cksum 0x913b (correct), seq 2722778500, win 65535, options [mss 1360,nop,wscale 5,nop,nop,TS val 410281830 ecr 0,sackOK,eol], length 0
10:42:52.311618 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    185.125.168.87.63104 > 206.189.14.89.80: Flags [.], cksum 0xaab8 (correct), seq 2722778501, ack 3348941576, win 4128, options [nop,nop,TS val 410281891 ecr 99226], length 0
10:42:52.312449 IP (tos 0x2,ECT(0), ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 512)
    185.125.168.87.63104 > 206.189.14.89.80: Flags [P.], cksum 0xecd7 (correct), seq 0:460, ack 1, win 4128, options [nop,nop,TS val 410281891 ecr 99226], length 460: HTTP, length: 460
	GET / HTTP/1.1
	Host: www.some-domain.com
	User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
	Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
	Accept-Encoding: gzip, deflate
	Connection: keep-alive
	Upgrade-Insecure-Requests: 1
	If-Modified-Since: Mon, 23 Apr 2018 10:34:20 GMT
	If-None-Match: "5addb6ac-f"
	Cache-Control: max-age=0
	
10:42:52.373373 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    185.125.168.87.63104 > 206.189.14.89.80: Flags [.], cksum 0xa7ef (correct), seq 460, ack 188, win 4122, options [nop,nop,TS val 410281948 ecr 99241], length 0
Т.е. всё отлично срабатывает и никаких зацикливаний.

Собственно вопрос, в чём же дело? Как можно локализовать проблему?

На всякий случай:

$ netstat -plutn
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -               
tcp6       0      0 :::22                   :::*                    LISTEN      -               
tcp6       0      0 :::80                   :::*                    LISTEN      -           

★★★

Последнее исправление: VirRaa (всего исправлений: 1)

Ответ на: комментарий от Deleted

Да, с сервера.

$ sudo ufw disable
Firewall stopped and disabled on system startup
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
VirRaa ★★★
() автор топика
Ответ на: комментарий от Deleted
$ sudo tcpdump -nvvi any port 80
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes



11:03:07.089584 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    206.189.14.89.80 > 79.xxx.xxx.121.63487: Flags [S.], cksum 0x1664 (incorrect -> 0x8e1f), seq 442724988, ack 1628156029, win 28960, options [mss 1460,sackOK,TS val 402936 ecr 411458878,nop,wscale 7], length 0
11:03:07.189504 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63487 > 206.189.14.89.80: Flags [S], cksum 0x7633 (correct), seq 1628156028, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 411469878 ecr 0,sackOK,eol], length 0
11:03:07.189547 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    206.189.14.89.80 > 79.xxx.xxx.121.63487: Flags [S.], cksum 0x1664 (incorrect -> 0x8e07), seq 442724988, ack 1628156029, win 28960, options [mss 1460,sackOK,TS val 402960 ecr 411458878,nop,wscale 7], length 0
11:03:09.011116 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63488 > 206.189.14.89.80: Flags [S], cksum 0x8d90 (correct), seq 2987802939, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 411471630 ecr 0,sackOK,eol], length 0
11:03:09.011155 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    206.189.14.89.80 > 79.xxx.xxx.121.63488: Flags [S.], cksum 0x1664 (incorrect -> 0xcdc2), seq 321791123, ack 2987802940, win 28960, options [mss 1460,sackOK,TS val 403416 ecr 411471630,nop,wscale 7], length 0
11:03:09.264010 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63489 > 206.189.14.89.80: Flags [S], cksum 0x179a (correct), seq 1550060528, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 411471873 ecr 0,sackOK,eol], length 0
11:03:09.264044 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    206.189.14.89.80 > 79.xxx.xxx.121.63489: Flags [S.], cksum 0x1664 (incorrect -> 0xac4e), seq 3966695056, ack 1550060529, win 28960, options [mss 1460,sackOK,TS val 403479 ecr 411471873,nop,wscale 7], length 0
11:03:09.696636 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63490 > 206.189.14.89.80: Flags [S], cksum 0xb784 (correct), seq 3333947405, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 411472292 ecr 0,sackOK,eol], length 0
11:03:09.696675 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    206.189.14.89.80 > 79.xxx.xxx.121.63490: Flags [S.], cksum 0x1664 (incorrect -> 0x0179), seq 2215815489, ack 3333947406, win 28960, options [mss 1460,sackOK,TS val 403587 ecr 411472292,nop,wscale 7], length 0
11:03:09.950236 IP (tos 0x8, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    79.xxx.xxx.121.63491 > 206.189.14.89.80: Flags [S], cksum 0x1eba (correct), seq 1813770883, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 411472532 ecr 0,sackOK,eol], length 0
11:03:09.950285 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    206.189.14.89.80 > 79.xxx.xxx.121.63491: Flags [S.], cksum 0x1664 (incorrect -> 0xd71b), seq 1844924591, ack 1813770884, win 28960, options [mss 1460,sackOK,TS val 403651 ecr 411472532,nop,wscale 7], length 0
VirRaa ★★★
() автор топика
Ответ на: комментарий от VirRaa

Похоже, что до клиента не доходит SYN-ACK. До клиента трафик как доходит, роутеры на пути есть? Какой-нибудь впн на них (роутерах) поднят? И подняты ли какие-нибудь впн'ы на самом клиенте в момент, когда возникает проблема?

Хотя да, если по другим портам все работает, то скорее всего блокировки.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Роутер есть. Работает в самом штатном режиме. VPN поднимаю на ноутбуке. Если VPN на ноуте не поднят - не работает, если VPN поднят, то соответственно, работает.

VirRaa ★★★
() автор топика
Ответ на: комментарий от Deleted

Просто в реестре заблокированных IP - не числится. Поэтому и возникли мысли, что может они вовсе и не виноваты.

VirRaa ★★★
() автор топика

Потом решил поделиться ссылкой на свежеподнятый ресурс в телеграм, туда попытался сходить telegrambot, и всё. После этого ресурс по 80-му порту не отвечает.

А это на любой ресурс работает, или только на твой ип?

Deleted
()
Ответ на: комментарий от Deleted

В данном случае с другими ресурсами не игрался, случилось именно с моим IP. Про телеграмбота - это предположение.

VirRaa ★★★
() автор топика

Подводя итог: насоздавал ещё дроплетов на digitalocean, в Амстере, Канаде и Сингапуре. У всех 80-й порт без VPN не алё.

VirRaa ★★★
() автор топика
Последнее исправление: VirRaa (всего исправлений: 1)
Ответ на: комментарий от madcore

А если и так? Правда я не знаю, как можно определить что ссылка туда попала. Может они рефереры мониторят?

mittorn ★★★★★
()

Есть похожая проблема. Мой VPS попал под раздачу. некоторые провайдеры вообще к ip не пускают, а ростелеком через раз рвет передачу по 443 порту

SR_team ★★★★★
()

Вести с полей. Проблема внезапно исчезла.

VirRaa ★★★
() автор топика
Ответ на: комментарий от VirRaa

Доступ ограничен к подсетям 167.99.0.0/16 и 206.189.0.0/16, каждая из которых содержит по 65 тысяч IP-адресов

anonymous
()
Ответ на: комментарий от VirRaa

да посади их на другой порт - делов-то. если они банят только 80 порт, то и хрен с ними. портов ещё много. я не думаю, что эти дебилы настолько продвинуты, чтобы что-то там отслеживать. тем более во внешнем трафике между твоим сервером и телеграмом, который им никак не доступен. просто ковровые бомбардировки случайных подсетей, без логики и без объяснений.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

А откуда пользователи будут знать, что надо не на 80-й идти? =) Это стандартный порт http. Пока вышел из ситуации так, что подсеть лондоновскую ещё не тронули, поэтому поднял дроплет в лондоне.

VirRaa ★★★
() автор топика
Ответ на: комментарий от Iron_Bug

я не думаю, что эти дебилы настолько продвинуты

половина «этих дебилов» админы и на лоре сидят

anonymous
()
Ответ на: комментарий от anonymous

да прям. в РКН сидят моральные уроды, а не админы. а админы просто вынуждены как-то «блокировать» что попало по причудам этих больных на голову существ. причём админы хорошо понимают, что это бред. и пытаются уменьшить тотальный вред от блокировок. юзеры же будут звонить провайдеру или хостеру, а не в роскомпозор.

Iron_Bug ★★★★★
()
Ответ на: комментарий от VirRaa

если у юзера есть ссылка, то какая ему баня, если там ещё и порт указан. браузеру тоже по барабану. а можно TLS поднять и 443-й юзать, если он не закрыт.

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

половина «этих дебилов» админы и на лоре сидят

И на опеннете их видел. И на линукс/юниксфоруме. Испанский стыд.

Deleted
()
Ответ на: комментарий от Iron_Bug

Моральное уродство начинается и заканчивается свершившимся фактом. Претворяют идею в жизнь - исполнители. Делать из них жертв - ну я не знаю...

Deleted
()
Ответ на: комментарий от Iron_Bug

Люди работают. Сейчас давят по адресам, чуть позже будут давить по dpi, адреса разблокируют.

anonymous
()
Ответ на: комментарий от Deleted

ну, я программист и я вообще не вижу в этом всём хоть какой-либо смысл. заблокировать интернет можно только выдернув сетевой шнур. и то с развитием спутниковых технологий - хз, хз. так что все эти попытки только создают нагрузку на все узлы сети, но абсолютно ничего не меняют. вот никто не страдает от «запретов». кроме провайдеров, на которых свалился лишний геморрой. а они-то не виноваты как раз.

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

ну какой dpi? это сколько бабла нужно выбросить на ветер? не всякий провайдер может купить себе эту печку - это раз. во-вторых, dpi абсолютно никак не влияет на защищённые каналы - это два. смысл? нулевой абсолютно. трата денег и времени впустую. страна дураков.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Выбрасывают. И МВД закупают. И службы. И спец.службы. Идиотизм на марше, да, но и 95% людей как известно...

Deleted
()
Ответ на: комментарий от Iron_Bug

Все эти попытки подтолкнут ipv6 и технологии децентрализации, имхо. Я имею в виду общие тенденции по всему миру.

В РФ к чему это приведёт... Я думаю, что чебурнету — быть.

Deleted
()
Ответ на: комментарий от Deleted

распилы никто не отменял. а мозг - если его нет, то не купишь ни за какие деньги, увы.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Deleted

физически этот чебурнет невозможен. во-первых, вся работа бизнеса связана с сетью. причём не с локальной. локальная нафиг никому не сдалась как раз. во-вторых, тот же Маск, у которого далеко не все проекты взлетают, но некоторые-таки взлетают, обещает мировой интернет уже через несколько лет. то, что они не хотят выделять частоты - это смешно. потому что частоты от этого никуда не денутся, да. гасить широкий диапазон над всей страной невозможно. опять же, физически. в общем, попытки дураков создать своё замкнутое и ограниченное королевство не увенчаются успехом. а вот бабла они на этом попилят дофига. и нервов потреплют людям, простым юзерам и бизнесменам.

но да, есть некоторые плюсы: юзеры стали грамотнее, начали более активно развиваться приложения, использующие децентрализованные протоколы. это плюс для конкретной страны, но в целом-то вещь ненужная, потому что без дурацких запретов это ведь и не нужно нафиг. это просто приспособление к нечеловеческим условиям выживания.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

физически этот чебурнет невозможен.

А опыт КНР и КНДР?

во-первых, вся работа бизнеса связана с сетью.

Бизнес закупит vpn. Ой, уже закупает. В тч Госпредприятия и госслужбы. КНР же фаерволл бизнесу не помеха. Даже наоборот, торгуют средствами обхода.

во-вторых, тот же Маск

До этого ещё дожить надо. И вроде как, репрессивный аппарат быстрее развивается, чем светлое будущее с дронами раздающими вайфай. Потому,я склонен думать что чебурнету быть. Он уже есть, и те, кто следит за википедией, поисковиками, ютубом это знают, однако, не э в таком гротескном виде, как кажется должен быть.

Deleted
()
Ответ на: комментарий от Iron_Bug

но да, есть некоторые плюсы: юзеры стали грамотнее, начали более активно развиваться приложения, использующие децентрализованные протоколы. это плюс для конкретной страны, но в целом-то вещь ненужная, потому что без дурацких запретов это ведь и не нужно нафиг. это просто приспособление к нечеловеческим условиям выживания.

Дай бог. Когда-то и проприетарные площадки использовали для организации/координации митингов. Власть нагнула корпорации. Пришла пора децентрализованным технологиям войти в жизнь молодого поколения.

Deleted
()
Ответ на: комментарий от Deleted

посмотри на «китайский файрволл» и количество китайских ботов в сети. оно само за себя говорит. а в Корее интернета просто нет.

vpn годится для всех. не только для бизнеса. а что касается «светлого будущего», то оно всё равно наступит. нельзя закуклиться и жить в прошлом веке, как бы ни пытались власти это имитировать.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

посмотри на «китайский файрволл» и количество китайских ботов в сети.

есть нюанс.


$ ping yandex.ru
PING yandex.ru (77.88.55.80) 56(84) bytes of data.
64 bytes from yandex.ru (77.88.55.80): icmp_seq=1 ttl=51 time=409 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=2 ttl=51 time=433 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=3 ttl=51 time=357 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=4 ttl=51 time=480 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=6 ttl=51 time=522 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=7 ttl=51 time=546 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=10 ttl=51 time=381 ms
64 bytes from yandex.ru (77.88.55.80): icmp_seq=13 ttl=51 time=381 ms
^C
--- yandex.ru ping statistics ---
14 packets transmitted, 8 received, 42% packet loss, time 13111ms
rtt min/avg/max/mdev = 357.673/439.123/546.367/65.468 ms

{пинг яндекса из Шанхая, без использования туннеля, т.е. чисто домашний инет, рабочий не лучше}

Вот что такое китайский интернет. И можно обставиться vpn , но статистику потерь и латенси ты не улучшишь.

Сегодня удачный вечер, все мои туннели «за стеной» доступны, потерь не так много (я привел не самую удачную статистику). Всякие github, steam, хостеры do, hetzner, amazon и тд и тп - аналогично.

Пинга меньше 180ms «за стену» не бывает вприинципе. Обычно - 250-300. Потери - 15-20%.

Все это жутко мешает даже работе. Не могу, к сожалению, найти статью китайского химика, который эту ситуацию описывал, насколько это затрудняет работу.

Это первый фактор. А именно: искусственное ухудшение качества канала вне чебурнета. Это заставляет хоститься внутри, и юзать отечественные сервисы. В китайнете сеть хорошая, жирная, пинги 5ms, конечно.

Второй фактор - качество туннельного софта. Не знаю как под виндой. Но под маком, айос и андроид все мессенджеры, которые не работают без туннелей, лишаются адекватных уведомлений. Туннели часто отваливаются, нотификаций нет. Вотзап, например, самый мерзкий сервис. Телеграм (не к ночи будет упомянут) - иногда шуршит даже без socks, чего-то там находит какие-то ноды.

В итоге, да, туннели работают. Но качество коммуникации падает катастрофически. Я когда выезжаю в отпуск куда-нибудь во Вьетнам или Тай - просто получаю освежающую порцию девственного чистого интернета. В Москве (уже, походу, по воспоминаниям) - инет просто сказочно офигенный был. Ну, теперь и это просрали, видать.

олег за всё берётся смело
всё превращается в говно
а если за говно берётся
то просто тратит меньше сил 

Deleted
()
Ответ на: комментарий от Deleted

это всё понятно. но интернет такой прямо весь из себя хороший в Москве и заканчивается. ну, ещё пару-тройку крупных городов и отдельных провайдеров можно причислить. а в целом-то по стране из всяких мухосрансков пинги ничуть не лучше, чем из Китая. а Китай вон как далеко. кстати, магистральные сети из Китая до яндекса точно так же идут здесь. так что что из Китая, что с какого-нибудь Дальнего Востока - одинакова фигня. да и кому этот яндекс сдался в Китае? я вот его даже тут вообще не использую. важны пинги до нужных серверов: до гугла, до амазона, до крупных хостингов. остальное - более-менее фиолетово. а что насчёт пингов, то самые худшие - во всяких там Таиландах и около. но вопрос не в этом, а в доступности сети в принципе.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

а в доступности сети в принципе.

формально да, проблем нет. Но во время осенней коммунистической тусы у меня куча туннелей перестали работать, спасали только сервисы vpn с сотнями адресов по всему шарику, из которых можно было выбрать парочку доступных. Так что доступность есть, но она бывает низка.

да и кому этот яндекс сдался в Китае?

я возможно немного намутил воду с этим яндексом. Просто многие популярные сервисы запрещают пинги (иногда, прицельно китайские), другие заблочены в китае, поэтому взять так с кондачка какой-нибудь пинг до github не получается, в голову не приходит. Но прошу понять - это пинги до _любого_ хоста за пределами чебурнета. Амазоновский ли EC2, DO в амстердаме или калифорнии, CDN какого-нибудь гугла - это все не лучше, чем до того яндекса.

$ ping ftp.debian.org
PING ftp.debian.org (130.89.148.12) 56(84) bytes of data.
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=1 ttl=48 time=613 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=3 ttl=48 time=606 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=4 ttl=48 time=441 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=5 ttl=48 time=445 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=6 ttl=48 time=469 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=7 ttl=48 time=381 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=8 ttl=48 time=517 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=9 ttl=48 time=338 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=10 ttl=48 time=360 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=11 ttl=48 time=383 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=12 ttl=48 time=433 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=13 ttl=48 time=428 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=14 ttl=48 time=451 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=15 ttl=48 time=678 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=16 ttl=48 time=571 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=18 ttl=48 time=517 ms
64 bytes from klecker2.snt.utwente.nl (130.89.148.12): icmp_seq=19 ttl=48 time=492 ms
^C
--- ftp.debian.org ping statistics ---
20 packets transmitted, 17 received, 15% packet loss, time 19097ms
rtt min/avg/max/mdev = 338.998/478.492/678.993/92.795 ms

В случае дебиана, есть, конечно, внутреннее зеркало, вот для сравнения.

$ ping ftp.cn.debian.org
PING ftp.cn.debian.org (45.125.0.6) 56(84) bytes of data.
64 bytes from 45.125.0.6.static.xtom.com (45.125.0.6): icmp_seq=1 ttl=50 time=31.7 ms
64 bytes from 45.125.0.6.static.xtom.com (45.125.0.6): icmp_seq=2 ttl=50 time=31.8 ms
64 bytes from 45.125.0.6.static.xtom.com (45.125.0.6): icmp_seq=3 ttl=50 time=33.0 ms
64 bytes from 45.125.0.6.static.xtom.com (45.125.0.6): icmp_seq=4 ttl=50 time=31.8 ms
^C
--- ftp.cn.debian.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 31.774/32.136/33.058/0.548 ms

Кстати, торренты в основной массе хорошо качаются - p2p решает, конечно.

Deleted
()
Ответ на: комментарий от Iron_Bug

но интернет такой прямо весь из себя хороший в Москве и заканчивается

Надо сравнивать подобное. Например, Москва (инет норм) - Шанхай (инет говно). В перди, понятно, чего ожидать. Было бы кстати забавно получить обратный пример.

В Тае нормальный интернет, даже на островах - оптику последние годы протянули, а чебурнет не завезли (пока, хз чего дальше в голову стукнет). Там проблема в последней миле всегда была - безсистемная паутина из меди на столбах ни к чему хорошему не приводила. Мобильный инет и раньше был ОК.

а в Корее интернета просто нет.

не очень понял, что имеется ввиду. Я там не был. (Корея == Сев.Корея? Удивлен :) но в этом случае, тогда понятно)

Самый жопный инет, с которым я сталкивался, это была Куба. Интернет кафе в отеле не работало; интернет-роуминга просто нет (2012 что ли год); был какой-то безумно дорогой мобильный инет для туристов, но я не брал симки. И гид рассказывал, что нельзя так просто взять и подключить инет гражданам.

Deleted
()
Ответ на: комментарий от Iron_Bug

если они банят только 80 порт,

Нет. Выгрузка содержит несколько типов блокировок. Памятка оператору с форматом вот тут раздаётся открыто: https://eais.rkn.gov.ru/tooperators/

За последние пару недель много влетело с blocktype=«ip», DO в том числе.

AS ★★★★★
()

Потом решил поделиться ссылкой на свежеподнятый ресурс в телеграм, туда попытался сходить telegrambot

лул

targitaj ★★★★★
()
Ответ на: комментарий от Iron_Bug

это сколько бабла нужно выбросить на ветер?

Приходится. И выбрасывать, и что-то придумывать. Иначе - штраф. За два штрафа могут начать лицензию отзывать. Совсем адово не зажимают пока, но в тонусе держат.

AS ★★★★★
()
Ответ на: комментарий от AS

имхо, проще ихнюю коробку заизолировать нахрен от внешнего мира, а остальным людям дать жить нормально.

Iron_Bug ★★★★★
()

Сегодня внезапно обнаружил, что не пущает ssh по 80 порту ни дома, ни на работе. Сервак точно доступен, 80 порт точно открыт (могу соединиться через свой же прокси), могу подключиться на любой рандомный, предварительно включив в sshd_config. IP точно не попадал под раздачу, я отслеживаю выгрузку. Хостер один из небольших европейских. Что за нах? o_O

user42 ★★
()
Последнее исправление: user42 (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

имхо, проще ихнюю коробку заизолировать нахрен от внешнего мира

Если бы они не могли подключиться в виде обычного клиента...

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.