Блокировка провайдером или неверная конфигурация?

Имею VPS с xray, который гонял shadowsocks и vless tcp reality. Строит в Европе.
Дома провайдер МГТС, Москва.

Какое-то время назад подключение к этому VPS померло при подключении второго смартфона к ShadowSocks через v2ray. Померло накрепко, не работает ничего: до VPS не работает ни HTTPs, ни HTTP, ни один из xray протоколов, ни SSH.
При этом все прекрасно работает через мобильный интернет МТС, если отключить wi-fi.

Не беда: у сервера есть второй IP, поднял на втором IP Trojan и перенес туда VLESS, ShadowSocks не использую вообще. Работает на основном смартфоне, подключаю на втором Trojan - ломается подключение и на этот IP.
Я хватаюсь за голову и начинаю мучить правила firewall на Mikrotik-е. Я пользователь Mikrotik совсем неискушенный, но минут через 30 и пару перезагрузок роутера подключение на второй IP оживает.
Я так и не понял: это либо я что-то на Mikrotik-е отчебучил, либо МГТС второй IP просто не совсем насмерть заблокировал, и временный бан прошел. Первый IP "не работает" уже больше суток, чую, что и не заработает уже, если это таки МГТС.

Как выглядят попытки с curl:
curl -v https://pl.****
* Host pl.****:443 was resolved.
* IPv6: (none)
* IPv4: 146.****
*   Trying 146.****:443...
* connect to 146.**** port 443 from 0.0.0.0 port 61693 failed: Timed out
* Failed to connect to pl.**** port 443 after 62036 ms: Couldn't connect to server
* Closing connection
curl: (28) Failed to connect to pl.**** port 443 after 62036 ms: Couldn't connect to server

При этом до сервера проходит ping:
ping pl.****

Pinging pl.**** [146.****] with 32 bytes of data:
Reply from 146.****: bytes=32 time=61ms TTL=48
Reply from 146.****: bytes=32 time=61ms TTL=48
Reply from 146.****: bytes=32 time=61ms TTL=48
Reply from 146.****: bytes=32 time=61ms TTL=48

Ping statistics for 146.****:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 61ms, Maximum = 61ms, Average = 61ms

И traceroute:
traceroute pl.**** 

traceroute to pl.**** (146.****), 30 hops max, 60 byte packets
 1  router.lan (192.168.1.1)  0.126 ms  0.104 ms  0.194 ms
 2  **** (****)  3.174 ms  5.419 ms  5.346 ms
 3  mpts-ss-51.msk.mts-internet.net (212.188.1.6)  12.781 ms  12.874 ms  12.883 ms
 4  * * *
 5  mag9-cr02-be13.77.msk.mts-internet.net (195.34.53.206)  5.346 ms  5.288 ms  5.721 ms
 6  a433-cr06-eth-trunk15.msk.mts-internet.net (212.188.28.102)  5.774 ms  5.909 ms  5.632 ms
 7  mmon-cr01-be1.spb.mts-internet.net (212.188.2.53)  18.185 ms  16.278 ms  16.442 ms
 8  radio-cr01-ae9.0.hel.mts-internet.net (212.188.29.23)  23.051 ms  23.060 ms  23.067 ms
 9  decix2.ovhcloud.com (80.81.193.209)  47.680 ms  47.642 ms  47.672 ms
10  * * *
11  * * *
12  * * *
13  be103.waw-wa2-sbb1-nc5.pl.eu (213.251.128.114)  62.830 ms be104.waw-atm-sbb1-nc5.pl.eu (54.36.50.117)  63.635 ms be103.waw-wa2-sbb1-nc5.pl.eu (213.251.128.114)  60.012 ms
14  be101.waw1-oza1-g1-nc5.pl.eu (91.121.131.151)  62.767 ms  62.773 ms be101.waw1-oza1-g2-nc5.pl.eu (213.186.32.203)  65.377 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  ****.bluevps.net (146.****)  60.546 ms  58.236 ms  59.888 ms
20  ****.eu (146.****)  64.008 ms  61.600 ms  64.716 ms

Но не TCP traceroute на порт 443:
sudo traceroute -T -p 443 pl.****

traceroute to pl.**** (146.****), 30 hops max, 60 byte packets
 1  router.lan (192.168.1.1)  0.177 ms  0.152 ms  0.190 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *

С него подключение тоже не проходит:
/tool fetch url="https://pl.****" mode=https
  status: failed

failure: Idle timeout - connecting

На Микроте настроил логгинг подключений на IP:
09-20 01:21:50 firewall,info OUT-TO-146.****:  forward: in:bridge out:ether1, connection-state:new sr
c-mac d8:5e:d3:ad:e1:a4, proto TCP (SYN), 192.168.1.5:61473->146.****:443, len 52
 09-20 01:21:52 firewall,info OUT-TO-146.****:  forward: in:bridge out:ether1, connection-state:new,sn
at src-mac d8:5e:d3:ad:e1:a4, proto TCP (SYN), 192.168.1.5:61473->146.****:443, NAT (192.168.1.5:6147
3->91.****:61473)->146.****:443, len 52
 09-20 01:21:56 firewall,info OUT-TO-146.****:  forward: in:bridge out:ether1, connection-state:new,sn
at src-mac d8:5e:d3:ad:e1:a4, proto TCP (SYN), 192.168.1.5:61473->146.****:443, NAT (192.168.1.5:6147
3->91.****:61473)->146.****:443, len 52
 09-20 01:22:04 firewall,info OUT-TO-146.****:  forward: in:bridge out:ether1, connection-state:new sr
c-mac d8:5e:d3:ad:e1:a4, proto TCP (SYN), 192.168.1.5:61473->146.****:443, len 52
 09-20 01:22:20 firewall,info OUT-TO-146.****:  forward: in:bridge out:ether1, connection-state:new sr
c-mac d8:5e:d3:ad:e1:a4, proto TCP (SYN), 192.168.1.5:61473->146.****:443, len 5

Wireshark:
47	1.473509	192.168.1.5	146.****	TCP	66	62874 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
82	3.483680	192.168.1.5	146.****	TCP	66	[TCP Retransmission] 62874 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
177	7.490131	192.168.1.5	146.****	TCP	66	[TCP Retransmission] 62874 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
312	15.490795	192.168.1.5	146.****	TCP	66	[TCP Retransmission] 62874 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
509	31.493933	192.168.1.5	146.****	TCP	66	[TCP Retransmission] 62874 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM

Все блокирующие правила микрота уже пытался выключать, но на всякий случай вот они все.
Mangle и Raw чистые, address list вычистил от блеклиста адресов, в NAT только src-nat на статический IP и горочка dst-nat на несколько домашних сервисов.
UPNP и NAT-PMP включены (были всегда), смена DNS ничего не дала (да и не должна, IP резолвится правильный).

Хочу узнать у знающих пользователей: вы видите здесь явные признаки блокировки провайдером или неверной конфигурации микротика?
Учитывая, что неделю назад все работало нормально, я на 90% склоняюсь к тому, что малину ломает МГТС. Но почему же тогда TCP traceroute падает на первом же узле, который микрот? И почему подключение до второго IP сдохло, когда я уже использовал Trojan вместо ShadowSocks? ТСПУ уже и Trojan умеет?
  • Вопрос задан
  • 2011 просмотров
Решения вопроса 1
@Drno
Блокируют провайдеры. Попробуйте перекинуть vless (хоть это и не логично и не правильно) на другой порт
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@kest70
Человеку свойственно ошибаться
Аналогичная история. С VPS в KZ. Начинает работать, а потом соединение пропадает, и не появляется совсем.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы