Debian OpenVPN server + Mikrotik ovpn client

0

1

Добрый день!

Настроил openVPN сервер на Debian и подключил к нему домашний mikrotik как клиента. Две недели всё работало хорошо, сегодня начались проблемы. Трафик до сервера не идёт, соединение обрывается и переподключается раз в минуту, примерно.

В логе микротика: ovpn-out1: initializing… ovpn-out1: connecting… ovpn-out1: using encoding - AES-256-CBC/SHA1 ovpn-out1: connected ovpn-out1: terminating… - nothing received for a while ovpn-out1: disconnected

И далее тоже самое по кругу. При подключении до сервера проходит несколько пингов (ping 10.8.0.1), но сервер быстро перестаёт пинговаться.

Конфиг сервера:

port 9494
proto tcp
dev tun

ca /path/to/certs
cert /path/to/certs
key /path/to/certs  # This file should be kept secret
dh /path/to/certs

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist /var/log/openvpn/ipp.txt

keepalive 10 120

--data-ciphers AES-256-CBC
data-ciphers-fallback AES-256-CBC

persist-key
persist-tun

status /var/log/openvpn/openvpn-status.log

log-append  /var/log/openvpn/openvpn.log

verb 6

explicit-exit-notify 0

Лог сервера:

2024-10-18 19:16:40 us=305531 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2024-10-18 19:16:40 us=305578 library versions: OpenSSL 3.0.14 4 Jun 2024, LZO 2.10
2024-10-18 19:16:40 us=305634 DCO version: N/A
2024-10-18 19:16:40 us=313964 net_route_v4_best_gw query: dst 0.0.0.0
2024-10-18 19:16:40 us=314170 sitnl_send: checking for received messages
2024-10-18 19:16:40 us=314286 sitnl_send: rtnl: received 412 bytes
2024-10-18 19:16:40 us=314347 net_route_v4_best_gw result: via 66.1.1.1 dev ens1
2024-10-18 19:16:40 us=317903 Diffie-Hellman initialized with 2048 bit key
2024-10-18 19:16:40 us=321684 TLS-Auth MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2024-10-18 19:16:40 us=322286 net_route_v4_best_gw query: dst 0.0.0.0
2024-10-18 19:16:40 us=322356 sitnl_send: checking for received messages
2024-10-18 19:16:40 us=322390 sitnl_send: rtnl: received 412 bytes
2024-10-18 19:16:40 us=322438 net_route_v4_best_gw result: via 66.1.1.1 dev ens1
2024-10-18 19:16:40 us=322501 ROUTE_GATEWAY 66.11.1.1/255.255.255.0 IFACE=ens1 HWADDR=56:9f:00:e4:04:97
2024-10-18 19:16:40 us=326869 TUN/TAP device tun0 opened
2024-10-18 19:16:40 us=326932 do_ifconfig, ipv4=1, ipv6=0
2024-10-18 19:16:40 us=326996 net_iface_mtu_set: mtu 1500 for tun0
2024-10-18 19:16:40 us=327100 sitnl_send: checking for received messages
2024-10-18 19:16:40 us=327138 sitnl_send: rtnl: received 36 bytes
2024-10-18 19:16:40 us=327217 net_iface_up: set tun0 up
2024-10-18 19:16:40 us=327561 sitnl_send: checking for received messages
2024-10-18 19:16:40 us=327591 sitnl_send: rtnl: received 36 bytes
2024-10-18 19:16:40 us=327618 net_addr_ptp_v4_add: 10.8.0.1 peer 10.8.0.2 dev tun0
2024-10-18 19:16:40 us=327719 sitnl_send: checking for received messages
2024-10-18 19:16:40 us=327744 sitnl_send: rtnl: received 36 bytes
2024-10-18 19:16:40 us=327785 net_route_v4_add: 10.8.0.0/24 via 10.8.0.2 dev [NULL] table 0 metric -1
2024-10-18 19:16:40 us=327835 sitnl_send: checking for received messages
2024-10-18 19:16:40 us=327856 sitnl_send: rtnl: received 36 bytes
2024-10-18 19:16:40 us=327884 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
2024-10-18 19:16:40 us=327915 Could not determine IPv4/IPv6 protocol. Using AF_INET
2024-10-18 19:16:40 us=327957 Socket Buffers: R=[131072->131072] S=[16384->16384]
2024-10-18 19:16:40 us=328007 Listening for incoming TCP connection on [AF_INET][undef]:9494
2024-10-18 19:16:40 us=328077 TCPv4_SERVER link local (bound): [AF_INET][undef]:9494
2024-10-18 19:16:40 us=328097 TCPv4_SERVER link remote: [AF_UNSPEC]
2024-10-18 19:16:40 us=328158 MULTI: multi_init called, r=256 v=256
2024-10-18 19:16:40 us=328278 IFCONFIG POOL IPv4: base=10.8.0.4 size=62
2024-10-18 19:16:40 us=328315 ifconfig_pool_read(), in='mikrotik,10.8.0.4,'
2024-10-18 19:16:40 us=328338 succeeded -> ifconfig_pool_set(hand=0)
2024-10-18 19:16:40 us=328356 IFCONFIG POOL LIST
2024-10-18 19:16:40 us=328372 mikrotik,10.8.0.4,
2024-10-18 19:16:40 us=328419 MULTI: TCP INIT maxclients=1024 maxevents=1029
2024-10-18 19:16:40 us=329423 Initialization Sequence Completed

2024-10-18 20:14:24 us=91861 MULTI: multi_create_instance called
2024-10-18 20:14:24 us=92202 Re-using SSL/TLS context
2024-10-18 20:14:24 us=93408 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
2024-10-18 20:14:24 us=93534 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
2024-10-18 20:14:24 us=93757 TCP connection established with [AF_INET]5.2.2.2:13153
2024-10-18 20:14:24 us=93793 TCPv4_SERVER link local: (not bound)
2024-10-18 20:14:24 us=93816 TCPv4_SERVER link remote: [AF_INET]5.2.2.2:13153
2024-10-18 20:14:24 us=94375 5.2.2.2:13153 TCPv4_SERVER READ [14] from [AF_INET]5.2.2.2:13153: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
2024-10-18 20:14:24 us=94427 5.2.2.2:13153 TLS: Initial packet from [AF_INET]5.2.2.2:13153, sid=a0d9a733 401262bd
2024-10-18 20:14:24 us=94484 5.2.2.2:13153 TCPv4_SERVER WRITE [26] to [AF_INET]5.2.2.2:13153: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
2024-10-18 20:14:24 us=125399 5.2.2.2:13153 TCPv4_SERVER READ [26] from [AF_INET]5.2.2.2:13153: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ 0 ] pid=1 DATA len=0
2024-10-18 20:14:24 us=125567 5.2.2.2:13153 TCPv4_SERVER WRITE [26] to [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 1 0 ] DATA len=0
2024-10-18 20:14:24 us=197113 5.2.2.2:13153 TCPv4_SERVER READ [279] from [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=265
2024-10-18 20:14:24 us=200580 5.2.2.2:13153 TCPv4_SERVER WRITE [1222] to [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ 2 1 0 ] pid=1 DATA len=1188
2024-10-18 20:14:24 us=200868 5.2.2.2:13153 TCPv4_SERVER WRITE [1054] to [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ 2 1 0 ] pid=2 DATA len=1020
2024-10-18 20:14:24 us=231371 5.2.2.2:13153 TCPv4_SERVER READ [22] from [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 1 ] DATA len=0
2024-10-18 20:14:24 us=305512 5.2.2.2:13153 TCPv4_SERVER READ [22] from [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 2 ] DATA len=0
2024-10-18 20:14:24 us=580645 5.2.2.2:13153 TCPv4_SERVER READ [1414] from [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1400
2024-10-18 20:14:24 us=580845 5.2.2.2:13153 TCPv4_SERVER WRITE [34] to [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 3 2 1 0 ] DATA len=0
2024-10-18 20:14:24 us=611888 5.2.2.2:13153 TCPv4_SERVER READ [712] from [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=698
2024-10-18 20:14:24 us=613086 5.2.2.2:13153 VERIFY OK: depth=1, CN=openvpn
2024-10-18 20:14:24 us=613284 5.2.2.2:13153 VERIFY OK: depth=0, CN=mikrotik
2024-10-18 20:14:24 us=614048 5.2.2.2:13153 TCPv4_SERVER WRITE [89] to [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ 4 3 2 1 ] pid=3 DATA len=51
2024-10-18 20:14:24 us=647300 5.2.2.2:13153 TCPv4_SERVER READ [22] from [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 3 ] DATA len=0
2024-10-18 20:14:24 us=721055 5.2.2.2:13153 TCPv4_SERVER READ [303] from [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=289
2024-10-18 20:14:24 us=721297 5.2.2.2:13153 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-10-18 20:14:24 us=721399 5.2.2.2:13153 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-10-18 20:14:24 us=721435 5.2.2.2:13153 TCPv4_SERVER WRITE [271] to [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ 5 4 3 2 ] pid=4 DATA len=233
2024-10-18 20:14:24 us=752370 5.2.2.2:13153 TCPv4_SERVER READ [22] from [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 4 ] DATA len=0
2024-10-18 20:14:24 us=752490 5.2.2.2:13153 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2024-10-18 20:14:24 us=752563 5.2.2.2:13153 [mikrotik] Peer Connection Initiated with [AF_INET]5.2.2.2:13153
2024-10-18 20:14:24 us=752611 mikrotik/5.2.2.2:13153 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
2024-10-18 20:14:24 us=752676 mikrotik/5.2.2.2:13153 MULTI: Learn: 10.8.0.6 -> mikrotik/5.2.2.2:13153
2024-10-18 20:14:24 us=752696 mikrotik/5.2.2.2:13153 MULTI: primary virtual IP for mikrotik/5.2.2.2:13153: 10.8.0.6
2024-10-18 20:14:24 us=752742 mikrotik/5.2.2.2:13153 Data Channel MTU parms [ mss_fix:1363 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
2024-10-18 20:14:24 us=753017 mikrotik/5.2.2.2:13153 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
2024-10-18 20:14:24 us=753047 mikrotik/5.2.2.2:13153 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
2024-10-18 20:14:24 us=753065 mikrotik/5.2.2.2:13153 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
2024-10-18 20:14:24 us=753085 mikrotik/5.2.2.2:13153 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
2024-10-18 20:14:24 us=824830 mikrotik/5.2.2.2:13153 TCPv4_SERVER READ [10] from [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ ] DATA len=0
2024-10-18 20:14:24 us=824950 mikrotik/5.2.2.2:13153 TCPv4_SERVER READ [56] from [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=42
2024-10-18 20:14:24 us=825019 mikrotik/5.2.2.2:13153 PUSH: Received control message: 'PUSH_REQUEST'
2024-10-18 20:14:24 us=825069 mikrotik/5.2.2.2:13153 SENT CONTROL [mikrotik]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)
2024-10-18 20:14:24 us=825118 mikrotik/5.2.2.2:13153 TCPv4_SERVER WRITE [46] to [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 6 5 4 3 2 1 0 ] DATA len=0
2024-10-18 20:14:24 us=825353 mikrotik/5.2.2.2:13153 TCPv4_SERVER WRITE [160] to [AF_INET]5.2.2.2:13153: P_CONTROL_V1 kid=0 [ 6 5 4 3 ] pid=5 DATA len=122
2024-10-18 20:14:24 us=925102 mikrotik/5.2.2.2:13153 TCPv4_SERVER READ [22] from [AF_INET]5.2.2.2:13153: P_ACK_V1 kid=0 [ 5 ] DATA len=0
2024-10-18 20:14:26 us=31663 mikrotik/5.2.2.2:13153 Data Channel: cipher 'AES-256-CBC', auth 'SHA1'
2024-10-18 20:14:26 us=31856 mikrotik/5.2.2.2:13153 Timers: ping 10, ping-restart 240
2024-10-18 20:14:32 us=323258 mikrotik/5.2.2.2:13153 Connection reset, restarting [0]
2024-10-18 20:14:32 us=323294 mikrotik/5.2.2.2:13153 SIGUSR1[soft,connection-reset] received, client-instance restarting
2024-10-18 20:14:32 us=323624 TCP/UDP: Closing socket

Встречал в логе строки типа:

2024-10-18 16:57:09 us=72781 mikrotik/5.2.2.2:55715 MULTI: bad source address from client [100.3.3.3], packet dropped
2024-10-18 16:59:15 us=95989 MULTI: new connection by client 'mikrotik' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

Пробовал подсети провайдера и домашней сети (которая за микротиком) этому клиенту, прописывая:

client-config-dir ccd
route 192.168.88.0 255.255.255.0
route 100.3.3.3 255.255.255.0

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

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

←	Не настраивается tc для шейпинга

Настройка WDS

→

При подключении до сервера проходит несколько пингов (ping 10.8.0.1), но сервер быстро перпстаёт пинговаться.

ТСПУ

Dimez ★★★★★
(18.10.24 20:36:13 MSK)

Ответ на: комментарий от Dimez 18.10.24 20:36:13 MSK

Тоже думал об этом, но не знаю как это достоверно проверить.

Кроме того странным кажется, что сначала у меня была схожая проблема, когда я всё только настраивал. Но там я сперва проверил подключение, настроив клиент на компе и пробовал настраивать клиент на роутере не выключив клиент на компе.

В общем, тот косяк в изначальной настройке я решил, и теперь всё очень похоже сломалось спустя 2 недели.

Dextir
(18.10.24 20:43:06 MSK) автор топика

Ответ на: комментарий от Dextir 18.10.24 20:43:06 MSK

но не знаю как это достоверно проверить.

Поднять сервер openvpn с такими же настройками, но не за границей.

Но симптом «всё работало, а сейчас проходит несколько пингов в туннеле, потом замирает» - это 99% работа ТСПУ.

Dimez ★★★★★
(18.10.24 20:45:22 MSK)

У тебя опенвпн в России расположен или нет? Если второе - то всё работает как задумано, иностранные впн запретили и блокируют. Переноси его на государственно одобряемый хостинг.

firkax ★★★★★
(18.10.24 20:51:36 MSK)

Ответ на: комментарий от Dimez 18.10.24 20:45:22 MSK

это 99% работа ТСПУ

Она самая, на той неделе столкнулся. С локальным сервером соединение держит как бульдог, с удаленными — циклично отваливается.

У тебя опенвпн в России расположен

Не показатель. В частности, московская vps на pq-hosing конвульсирует с теми же симптомами.

hargard ★★
(18.10.24 20:57:06 MSK)
Последнее исправление: hargard 18.10.24 20:57:40 MSK (всего исправлений: 2)

Починить разве что сменой провайдера (временно) или внесением в VPN-реестр от имени подшефной организации.

Пробуй другие способы подключения, на микроте их хватает. Какой-нибудь на твоем провайдере наверняка еще работает.

hargard ★★
(18.10.24 21:06:24 MSK)
Последнее исправление: hargard 18.10.24 21:06:44 MSK (всего исправлений: 1)

Ответ на: комментарий от hargard 18.10.24 21:06:24 MSK

на микроте их хватает

К сожалению банятся все туннели в которые может микрот. Так что либо что то на OpenWRT и на нём поднимать stunnel\vray\x2ray\amnezia и т.п., либо Кинетик, они в последних прошивках научились в амнезию.

Единственный вариант сделать из микрота wireguard сервер (да, я знаю что в wireguard стороны равноправны, имеется ввиду то к чему будем цепляться) и подключаться к нему с клиента умеющего в амнезию.

Jameson ★★★★★
(18.10.24 21:23:58 MSK)
Последнее исправление: Jameson 18.10.24 21:27:07 MSK (всего исправлений: 2)

Ответ на: комментарий от hargard 18.10.24 21:06:24 MSK

Очень жаль. Я надеялся, что это у меня руки кривые и надо что-то докрутить… :)

У меня микротик простенький, не так много умеет, как хотелось бы. Он даже WireGuard не умеет, а на 7.* прошивку, в которой вроде бы научился мне пока не хотелось перепрошивать. Менять устройство тоже не особо хотелось. Рассчитывал обойтись малыми средствами. Но, видимо, надо будет искать другие варианты.

А можно ли спрятать свой туннель от ТСПУ? Желательно как нибудь так, что бы микротик сумел подключиться.

Dextir
(18.10.24 22:06:34 MSK) автор топика

Ответ на: комментарий от Dextir 18.10.24 22:06:34 MSK

Спрятать можно в ssh либо в ssl туннель, или амнезия. Ничего из этого микротик не умеет. К сожалению (или счастью) в текущий момент микротик абсолютно бесполезен в битве с Роскомнадзором. Есть один единственный экзотический вариант для мощных микротов умеющих в докер, но проще отдельную железку завести, НЕ микрот. И по этому поводу от микрота совсем отказаться наконец.

Они там вообще медленные очень, сначала они не могли по человечески заставить OpenVPN работать с ключами, потом мучительно рожали wireguard, ну их к чОрту. Когда то я активно их юзал, внедрял и советовал, но не сейчас. Они явно теряют рыночек.

Jameson ★★★★★
(18.10.24 22:30:09 MSK)
Последнее исправление: Jameson 18.10.24 22:45:15 MSK (всего исправлений: 5)

Ответ на: комментарий от Dextir 18.10.24 22:06:34 MSK

Можно попробовать ipip+ipsec тоннель по какой-то подобной инструкции https://habr.com/ru/articles/496514/ (не проверял, первое попавшееся в поиске)
Но по крайней мере просто ipip без шифрования у меня работал.

PS. про 7 прошивку. Я обновил свой старенький RB951G-2HnD специально для WG. Оно работает, но программно и упирается в процессор примерно на 60Mb/s, ещё и отвалы интернета не всегда стабильно переживает, приходится его «дёргать» иногда
пока хватает, но в фоне подумываю на что бы поменять…

Flotsky ★★
(18.10.24 23:01:56 MSK)

Ответ на: комментарий от Flotsky 18.10.24 23:01:56 MSK

ipip+ipsec

Тоже выявляется ТСПУ и блокируется, с шифрованием или без. Для борьбы с Роскомнадзором микрот бесполезен целиком и полностью. Знаю по личному опыту, у меня около десяти контор с микротами пострадали. Пока на кинетики их перевёл, поскольку они были в оперативном наличии, думаю в перспективе надо относительно мощным железом под OpenWRT закупаться.

Jameson ★★★★★
(18.10.24 23:11:55 MSK)
Последнее исправление: Jameson 18.10.24 23:13:55 MSK (всего исправлений: 2)

Ответ на: комментарий от Jameson 18.10.24 22:30:09 MSK

Когда то я активно их юзал, внедрял и советовал, но не сейчас. Они явно теряют рыночек.

У меня в одной из компаний учредитель родом из совка и на политической волне параноит, что господа из-за бугра обязательно готовят нам что-то нехорошее, а учитывая не так давно ситуацию с пейджерами в Ливане попросил предложить альтернативу микротам. Ему понравилась идея перевести пограничные марши на комплекс из ПО debian+isc-dhcp+bind+nftables+frr(между филиалами) благо филиалов не так много. Так что (потирая руки) выходные у меня насыщенные сулят. Ну и выход в выходной оплачивается солиднее…=)

Shprot ★★
(18.10.24 23:18:35 MSK)

Ответ на: комментарий от Jameson 18.10.24 23:11:55 MSK

Значит мне с простым ipip до заграничного VPS пока везёт т.к. оно не режется (проводной мегафон, подмосковье)

относительно мощным железом под OpenWRT закупаться

увы боюсь так, целый ПК для этого не хочется ставить, скорее всего для начала буду делать виртуальный роутер и часть трафика на него заворачивать…

Flotsky ★★
(18.10.24 23:20:41 MSK)

Ответ на: комментарий от Flotsky 18.10.24 23:20:41 MSK

Да, кстати, если что то у кого то заработало — не факт что это будет работать у всех и всегда. Блокируют и детектят разными способами, способы периодически меняются, то что работало сегодня может через неделю отвалиться, или наоборот, внезапно отвалившееся начнёт пролезать. Там у них рандом и хаос.

Достоверно пока известно следующее — не мешают тоннелям ssh (не факт что так будет всегда и не факт что провайдер не возжелает их шейпить), не мешают тоннелям ssl, которые не могут отличить от https трафика (но могут раз в сутки или чаще сбрасывать сессии, чтобы жизнь мёдом не казалась), работают методы сворачивания кукухи DPI фильтру от ValdikSS, но работающие параметры придётся подбирать скриптом или вручную под своего провайдера, работают «продвинутые» носки типа vray, x2ray с маскировкой под «легитимный» трафик, obfs прокси работают только свежие, «старую» версию протокола научились детектить.

Jameson ★★★★★
(18.10.24 23:25:31 MSK)

Ответ на: комментарий от Flotsky 18.10.24 23:20:41 MSK

А целый ПК и не нужно, поищи что-то типа этого

https://ozon.ru/t/5vdjMW3

hargard ★★
(19.10.24 08:05:54 MSK)

←	Не настраивается tc для шейпинга

Admin

Настройка WDS

→

Похожие темы