Слияние кода завершено, страница обновится автоматически
Компиляция на основе Docker
Для ядер, поддерживающих BTF, не требуется установка дополнительных зависимостей, можно сразу использовать команду для компиляции nettrace:
docker run -it --rm --network=host --privileged -v $(pwd):$(pwd) -v /lib/modules/:/lib/modules/ -v /usr/src/:/usr/src/ imagedong/nettrace-build make -C $(pwd) all
Если система не поддерживает BTF, необходимо сначала установить пакет kernel-headers, например, с помощью команды apt install linux-headers-$(uname -r) -y для Ubuntu или yum install kernel-headers kernel-devel -y для CentOS. Затем используйте следующую команду для компиляции:
docker run -it --rm --network=host --privileged -v $(pwd):$(pwd) -v /lib/modules/:/lib/modules/ -v /usr/src/:/usr/src/ imagedong/nettrace-build make -C $(pwd) NO_BTF=1 all
Обратите внимание: совместимый режим компиляции инструмента nettrace требует использования той же версии ядра, что использовалась при компиляции. Если ядро не указано, будет использоваться версия из текущей среды компиляции. В противном случае возможны непредвиденные проблемы.
Рекомендуется перед использованием обновить образ докера командой docker pull imagedong/nettrace-build, чтобы получить последнюю версию образа контейнера.
Инструмент nettrace предназначен для отслеживания пакетов ядра и диагностики сетевых проблем. При отслеживании пакетов можно использовать определённые фильтры для отслеживания конкретных пакетов. Основные параметры командной строки:
$ nettrace -h
nettrace: a tool to trace skb in kernel and diagnose network problem
Usage:
-s, --saddr filter source ip/ipv6 address
-d, --daddr filter dest ip/ipv6 address
--addr filter source or dest ip/ipv6 address
-S, --sport filter source TCP/UDP port
-D, --dport filter dest TCP/UDP port
-P, --port filter source or dest TCP/UDP port
-p, --proto filter L3/L4 protocol, such as 'tcp', 'arp'
--netns filter by net namespace inode
--netns-current filter by current net namespace
--pid filter by current process id(pid)
--min-latency filter by the minial time to live of the skb in us
--pkt-len filter by the IP packet length (include header) in byte
--tcp-flags filter by TCP flags, such as: SAPR
--basic use 'basic' trace mode, don't trace skb's life
--diag enable 'diagnose' mode
--diag-quiet only print abnormal packet
--diag-keep don't quit when abnormal packet found
--drop skb drop monitor mode, for replace of 'droptrace'
--drop-stack print the kernel function call stack of kfree_skb
--sock enable 'sock' mode
--monitor enable 'monitor' mode
—rtt enable 'rtt' in statistics mode
--rtt-detail enable 'rtt' in detail mode
--filter-srtt filter by the minial first-acked rtt in ms
--filter-minrtt filter by the minial last-acked rtt in ms
--latency-show show latency between kernel functions
--latency-free account the latency of skb free
--latency enable 'latency' mode
--latency-summary
show latency by statistics
-t, --trace enable trace group or trace. Some traces are disabled by default, use "all" to enable all
--force skip some check and force load nettrace
--ret show function return value
--detail show extern packet info, such as
*Примечание:* в тексте запроса есть код на языке программирования Shell, который был оставлен без перевода. **Статистика по вызовам функций**
*--rate-limit* ограничивает вывод до N/с, не действует в режимах diag/default.
*--btf-path* настраивает путь BTF-информации vmlinux.
-v: показывать информацию журнала.
*--debug*: показывать отладочную информацию.
*-h, --help*: показывать справочную информацию.
*-V, --version*: показывать версию nettrace.
**Параметры фильтрации**
Параметр *s/d/addr/S/D/port/p/pid* используется для фильтрации пакетов на основе IP-адреса (включая IPv6), порта, протокола и других свойств. Другие параметры используются для следующих целей:
* *netns*: фильтрация на основе сетевого пространства имён, за параметром следует номер inode сетевого пространства имён процесса, который можно просмотреть с помощью команды *ls -l /proc/<pid>/ns/net*.
* *netns-current*: отображение только пакетов текущего сетевого пространства имён. Эквивалентно *--netns текущему номеру inode сетевого пространства имён*.
* *pid*: фильтрация по идентификатору процесса, обрабатывающего пакет.
* *min-latency*: фильтрация пакетов по времени жизни, отображаются только пакеты со временем обработки больше указанного значения, в микросекундах. Этот параметр доступен только в режимах *default*, *diag* и *latency*.
* *pkt-len*: фильтрация на основе общей длины IP-пакета (включая заголовок пакета).
* *tcp-flags*: фильтрация на основе флагов TCP-пакетов, поддерживаемые флаги включают SAPRF.
**Режимы**
* *basic*: включение режима *basic* отслеживания. По умолчанию включён режим отслеживания жизненного цикла. В этом режиме непосредственно выводятся функции ядра/tracepoint, через которые проходит пакет.
* *diag*: включение диагностического режима.
* *diag-quiet*: отображение только проблемных пакетов, нормальные пакеты не отображаются.
* *diag-keep*: непрерывное отслеживание. В режиме *diag* отслеживание останавливается после обнаружения проблемы, этот параметр позволяет продолжить отслеживание.
* *drop*: мониторинг системных пакетов потери, заменяет предыдущую функцию *droptrace*.
* *drop-stack*: печать стека вызовов функции *kfree_skb* ядра, эквивалентно *--trace-stack kfree_skb*.
* *sock*: включение режима интерфейса сокета. В этом режиме пакеты больше не отслеживаются, а отслеживается интерфейс сокета.
* *monitor*: включение режима мониторинга. Тип облегчённой системы реального времени для мониторинга сетевых аномалий (требует определённой версии ядра).
* *rtt*: включение режима статистики RTT, отслеживает распределение TCP RTT.
* *rtt-detail*: включение детального режима RTT, выводит данные RTT для каждого пакета, соответствующего условиям фильтрации.
* *filter-srtt*: фильтрация на основе srtt, доступна в режимах *rtt/rtt-detail*, в миллисекундах.
* *filter-minrtt*: фильтрация на основе minrtt, доступна в режимах *rtt/rtt-detail*, в миллисекундах.
* *latency-show*: отображает информацию о задержке (время обработки протокола), недоступно в режимах *basic/sock*.
* *latency*: включает режим анализа задержки, эффективно анализирует время обработки каждого пакета протоколом.
* *latency-summary*: включает режим статистического анализа задержки, анализирует распределение времени обработки протоколом.
**Отображение**
* *t/trace*: отслеживаемый модуль, по умолчанию включены все.
* *ret*: отслеживание и отображение возвращаемого значения функции ядра.
* *detail*: отображение подробной информации отслеживания, включая текущий процесс, сетевой порт и информацию о процессоре. **Перевод текста:**
ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0
[3445.576061] [fib_validate_source ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0
[3445.576080] [ip_forward ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0
[3445.576084] [nf_hook_slow ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0 *ipv4 в цепочке: FORWARD*
[3445.576087] [nft_do_chain ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0 *iptables table:filter, цепочка:FORWARD* *пакет принят*
[3445.576107] [ip_output ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0
[3445.576113] [nf_hook_slow ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0 *ipv4 в цепочке: POST_ROUTING*
[3445.576116] [nft_do_chain ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0 *таблицы iptables:nat, цепочка:POSTROU* *пакет принят*
[3445.576131] [nf_nat_manip_pkt ] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0 *происходит NAT (адрес пакета изменится)*
[3445.576148] [ip_finish_output ] ICMP: 192.168.255.10 -> 10.123.119.98 ping request, seq: 0
[3445.576152] [ip_finish_output2 ] ICMP: 192.168.255.10 -> 10.123.119.98 ping request, seq: 0
[3445.576158] [__dev_queue_xmit ] ICMP: 192.168.255.10 -> 10.123.119.98 ping request, seq: 0
[3445.576165] [netdev_core_pick_tx ] ICMP: 192.168.255.10 -> 10.123.119.98 ping request, seq: 0
[3445.576177] [dev_hard_start_xmit ] ICMP: 192.168.255.10 -> 10.123.119.98 ping request, seq: 0
[3445.576215] [consume_skb ] ICMP: 192.168.255.10 -> 10.123.119.98 ping request, seq: 0 *пакет освобождён (обычно)*
---------------- АНАЛИЗ РЕЗУЛЬТАТА ---------------------
[1] ПРЕДУПРЕЖДЕНИЕ происходит в nf_nat_manip_pkt(netfilter):
происходит NAT (адрес пакета изменится)
**Если текущий пакет содержит ОШИБКУ, инструмент предоставит определённые рекомендации по диагностике и исправлению и завершит текущую операцию диагностики.**
Добавление diag-keep позволяет продолжить отслеживание анализа при возникновении события ОШИБКИ.
Ниже приведён журнал событий при возникновении исключения:
```shell
./nettrace -p icmp --diag --saddr 192.168.122.8
begin trace...
***************** b3c64f00 ***************
[4049.295546] [__netif_receive_skb_core] ICMP: 192.168.122.8 -> 10.123.119.98 ping request, seq: 0 **Перевод текста:**
Проверьте правила iptables:
[3] ERROR происходит в kfree_skb(life): пакет отброшен ядром location: nf_hook_slow+0x96 drop reason: NETFILTER_DROP
Анализ завершён!
Конец трассировки...
Из этого журнала видно, что пакет был отброшен при прохождении через таблицу forward цепочки filter таблицы iptables. В результатах диагностики перечислены все исключительные события, и один пакетный след может затронуть несколько результатов диагностики. Здесь предлагается проверить правила iptables.
Здесь `kfree_skb` — это точка отслеживания, которая адаптирована к характеристике `drop reason`, представленной в документации `droptrace`. Это можно понимать как интеграцию функции `droptrace` в результаты диагностики здесь, где причина пакета указана как `NETFILTER_DROP`.
#### 3.2.2 Поддержка netfilter
Сетевой брандмауэр является зоной бедствия для сетевых сбоев и различных сетевых аварий, поэтому инструмент `netfilter` идеально адаптирован к `netfilter`, включая старую версию `iptables-legacy` и новую версию `iptables-nft`. В режиме диагностики `nettrace` может отслеживать пакеты, проходящие через таблицы и цепочки `iptables`, и выдавать определённые подсказки при отбрасывании пакетов из-за `iptables`. Приведённый выше пример хорошо иллюстрирует эту часть. Помимо поддержки `iptables`, `nettrace` также предоставляет поддержку всему большому модулю netfilter, показывая соответствующие имена протокола и цепочки для каждого HOOK-пункта. Кроме того, чтобы справиться с некоторыми проблемами потери пакетов, вызванными регистрацией сторонних модулей ядра в netfilter. **TCP: 127.0.0.1:36562 -> 127.0.0.1:9999 информация: (1 0) таймер: (ретрансляция, 1.000 с)**
**TCP: 127.0.0.1:36562 -> 127.0.0.1:9999 информация: (0 0)**
**TCP: 127.0.0.1:9999 -> 127.0.0.1:36562 информация: (0 0)**
**TCP: 127.0.0.1:9999 -> 127.0.0.1:36562 информация: (0 0)**
**TCP: 127.0.0.1:36562 -> 127.0.0.1:9999 информация: (0 0)**
Содержание информации в поле «info» — это количество пакетов в очереди и количество повторных передач.
Содержание таймера — текущий таймер интерфейса и время его истечения. В настоящее время информация продолжает совершенствоваться.
### 3.5 Режим мониторинга
Обычные методы определения местоположения сети, включая отслеживание пакетов, диагностику и т. д., не подходят для развёртывания и нормальной работы в производственной среде из-за высоких накладных расходов. Режим мониторинга может обеспечить более лёгкий уровень контроля за сетевыми аномалиями и потерей пакетов. Поскольку этот режим основан на типе BPF TRACING, он предъявляет высокие требования к версии ядра. Ниже приведены требования к ядру:
| TencentOS | 5.4.119-19.0009 | 5.5 |
| --------------- | -------- | -------- |
| BPF особенности | TRACING | TRACING |
| Мониторинг | Можно использовать, нельзя контролировать функции ядра и параметры больше 6 | Можно использовать, нельзя контролировать параметры ядра больше 6 |
| Разработка | BTF_MODULES | TRACING поддерживает 6+ параметров |
TRACING поддержка 6+ параметров уже включена в upstream: [bpf, x86: allow function arguments up to 12 for TRACING](https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=f892cac2371447b3a26dad117c7bcdf2c93215e1).
Основные способы использования (при полной поддержке функций ядра):
```shell
$ nettrace --monitor
begin trace...
[25.167980] [nft_do_chain ] ICMP: 192.168.122.1 -> 192.168.122.9 ping request, seq: 1, id: 1523 *iptables table:filter, chain:INPUT* *пакет отброшен iptables/iptables-nft*
[25.167996] [kfree_skb ] ICMP: 192.168.122.1 -> 192.168.122.9 ping request, seq: 1, id: 1523, причина: NETFILTER_DROP, nf_hook_slow+0xa8
[25.168000] [nf_hook_slow ] ICMP: 192.168.122.1 -> 192.168.122.9 ping request, seq: 1, id: 1523 *ipv4 в цепочке: INPUT* *пакет отбрасывается сетевым фильтром (NF_DROP)*
В режиме мониторинга также можно использовать различные параметры обычного режима, такие как фильтрация пакетов и параметр --detail для отображения подробной информации. По умолчанию в режиме монитора rtt не отслеживается. Однако если указаны параметры --filter-minrtt или --filter-srtt, то будет отслеживаться событие rtt:
./src/nettrace --monitor --filter-minrtt 10
begin trace...
[2651830.434898] [tcp_ack_update_rtt.isra.51] TCP: 127.0.0.1:14275 -> 127.0.0.1:62522 ESTABLISHED CA_Open информация: (0 0) mem: (w0 r0) *srtt: 8 мс, rtt: 40 мс*
[2651830.435267] [tcp_ack_update_rtt.isra.51] TCP: 10.37.80.82:22 -> 10.85.114.159:53493 ESTABLISHED CA_Open информация: (0 0) mem: (w0 r0) *srtt: 38 мс, rtt: 41 мс*
[2651830.484520] [tcp_ack_update_rtt.isra.51] TCP: 10.37.80.82:22 -> 10.85.114.159:53493 ESTABLISHED CA_Open информация: (0 0) mem: (w0 r0) *srtt: 39 мс, rtt: 37 мс*
[2651830.529385] [tcp_ack_update_rtt.isra.51] TCP: 10.37.80.82:22 -> 10.85.114.159:53493 ESTABLISHED CA_Open информация: (0 0) mem: (w0 r0) *srtt: 38 мс, rtt: 36 мс*
[2651830.578473] [tcp_ack_update_rtt.isra.51] TCP: 10.37.80.82:22 -> 10.85.114.159:53493 ESTABLISHED CA_Open информация: (0 0) mem: (w0 r0) *srtt: 38 мс, rtt: 41 мс*
[2651830.752827] [tcp_retransmit_timer] TCP: 10.37.80.82:100 -> 10.154.16.12:8603 SYN_SENT CA_Open информация: (0 0) mem: (w0 r0) *TCP повторная передача таймера*
### 3.6 Анализ производительности
Инструмент в настоящее время поддерживает два метода анализа производительности: один — сбор данных о времени ожидания rtt для соединений tcp на хосте, чтобы определить текущую ситуацию с задержкой обработки сети; другой — сбор данных о затраченном времени. Анализ задержки в стеке протоколов
В определённых сценариях, таких как диагностика проблем с задержкой в сети, нам может потребоваться сосредоточиться на обработке пакетов с длительным временем обработки в стеке протоколов. В этом случае необходимо фильтровать данные о времени обработки на основе времени от начала отслеживания пакета до момента его освобождения предыдущим функциональным блоком. В настоящее время рассматривается только функция непосредственно перед освобождением пакета, поскольку в ядре может существовать поведение «отложенной пакетной очистки», которое влияет на точность измерения задержки. Следующая команда фильтрует пакеты со временем обработки более 1 мс:
```shell
$ sudo ./nettrace -p icmp --latency-show
begin trace... **Последовательность ICMP: 192.168.122.9 -> 192.168.122.1 ping request, seq: 3, id: 9573 latency: 0.003ms**
*Можно использовать --min-latency для фильтрации сообщений по времени обработки в стеке протоколов, измеряемому в микросекундах (us). Например: nettrace -p icmp --min-latency 1000, что позволяет фильтровать сообщения со временем обработки более 1 миллисекунды.*
При использовании этого метода можно получить подробную информацию о времени обработки каждого этапа в стеке протокола, но его эффективность может быть низкой, особенно при большом объёме сетевого трафика. В этом режиме каждое соответствующее событие сообщения отправляется в пользовательское пространство, где выполняется фильтрация по времени.
Для повышения производительности можно использовать режим отслеживания задержки. Этот режим имеет меньшие накладные расходы на производительность, но недостатком является то, что он отслеживает только время от начала до завершения обработки сообщения, не позволяя анализировать время обработки на каждом этапе.
**Этап приёма сообщений**
Отслеживание сообщения после помещения в очередь приёма и до того, как оно будет извлечено из очереди пользователем, включая задержку, вызванную задержкой извлечения сообщения из очереди приёма пользователем:
```shell
nettrace -p tcp --latency -t tcp_queue_rcv,tcp_data_queue_ofo --trace-matcher tcp_queue_rcv,tcp_data_queue_ofo --latency-free --min-latency 1000
Отслеживание задержки между получением сообщения сетевым драйвером и помещением его в очередь приёма интерфейса:
nettrace -p tcp --latency -t __netif_receive_skb_core,tcp_queue_rcv,tcp_data_queue_ofo --trace-matcher __netif_receive_skb_core --trace-free tcp_queue_rcv,tcp_data_queue_ofo --min-latency 1000
Этап отправки сообщений
Отслеживание времени от помещения сообщения в очередь отправки до начала передачи, обычно связанное с агрегированием сообщений алгоритмом Nagle:
nettrace -p tcp --latency -t skb_entail,tcp_skb_entail,__tcp_transmit_skb,__tcp_retransmit_skb --trace-matcher skb_entail,tcp_skb_entail --trace-free __tcp_transmit_skb,__tcp_retransmit_skb --min-latency 1000
Отслеживание времени передачи сообщения от уровня TCP до сетевого драйвера, которое может включать задержку из-за qdisc:
nettrace -p tcp --latency -t __ip_queue_xmit,dev_hard_start_xmit --trace-matcher __ip_queue_xmit --trace-free dev_hard_start_xmit --min-latency 1000
Отслеживание времени между помещением сообщения в очередь передачи и получением подтверждения (ACK), которое может быть затронуто алгоритмом Nagle и задержкой ACK:
nettrace -p tcp --latency -t skb_entail,tcp_skb_entail,tcp_rate_skb_delivered --trace-matcher skb_entail,tcp_skb_entail --trace-free tcp_rate_skv_delivered --min-latency 1000
По умолчанию задержка освобождения сообщения не учитывается как время обработки стека протоколов. Можно включить задержку освобождения с помощью --latency-free. Это полезно для анализа задержек в сети во время процесса приёма, например, для изучения задержки между извлечением данных из очереди приёма и их освобождением в пользовательском пространстве.
Кроме того, можно использовать... --latency-summary для получения статистики по задержкам обработки стека протоколов:
./nettrace --latency -p tcp --latency -t skb_entail,tcp_skb_entail,__tcp_transmit_skb,__tcp_retransmit_skb --trace-matcher skb_entail,tcp_skb_entail --trace-free __tcp_transmit_skb,__tcp_retransmit_skb --latency-summary
Здесь представлена статистика, которая обновляется каждую секунду. На основе этого распределения можно проанализировать общую ситуацию с задержкой обработки в стеке протоколов.
В режиме RTT можно анализировать изменения RTT соединения и поддерживать фильтрацию на основе rtt и srtt. Здесь отслеживаются события обновления RTT интерфейса tcp_ack_update_rtt через трассировку вызовов функции ядра. По умолчанию это статистическое распределение RTT. Способ использования следующий:
./nettrace --rtt
begin trace...
rtt distribution: 29
0 - 1ms: 12 0.4137
2 - 3ms: 0 0.0000
4 - 7ms: 0 0.0000
8 - 15ms: 0 0.0000
16 - 31ms: 0 0.0000
32 - 63ms: 0 0.0000
64 - 127ms: 1 0.0344
128 - 255ms: 4 0.1379
256 - 511ms: 12 0.4137
Приведённая выше информация представляет собой: добавив параметр --rtt-detail, можно просмотреть ситуацию RTT каждого сообщения. Этот метод подходит для мониторинга систем, где RTT превышает определённый порог. Например, ниже приведены данные о сообщениях с задержкой передачи данных более 10 мс в системе мониторинга:
./nettrace --sock -t tcp_ack_update_rtt --filter-srtt 10
begin trace...
[11281.589357] [tcp_ack_update_rtt ] TCP: 192.168.0.111:42890 -> 43.129.25.208:38000 ESTABLISHED CA_Open out:(p0 r0) unack:196997740 mem:(w0 r0) timer:(loss_probe, 0.176s) *rtt:152ms, rtt_min:152ms*
[11281.802090] [tcp_ack_update_rtt ] TCP: 192.168.0.111:42890 -> 43.129.25.208:38000 ESTABLISHED CA_Open out:(p0 r0) unack:196998022 mem:(w0 r0) timer:(loss_probe, 0.124s) *rtt:209ms, rtt_min:209ms*
[11282.201314] [tcp_ack_update_rtt ] TCP: 192.168.0.111:42890 -> 43.129.25.208:38000 ESTABLISHED CA_Open out:(p0 r0) unack:196998304 mem:(w0 r0) timer:(loss_probe, 0.032s) *rtt:308ms, rtt_min:308ms*
[11282.408500] [tcp_ack_update_rtt ] TCP: 192.168.0.111:42882 -> 43.129.25.208:38000 ESTABLISHED CA_Open out:(p0 r0) unack:2248556186 mem:(w0 r0) timer:(loss_probe, 0.376s) *rtt:131ms, rtt_min:131ms*
[11282.408513] [tcp_ack_update_rtt ] TCP: 192.168.0.111:42914 -> 43.129.25.208:38000 ESTABLISHED CA_Open out:(p0 r0) unack:564521627 mem:(w0 r0) timer:(loss_probe, 0.376s) *rtt:128ms, rtt_min:128ms*
[11282.408518] [tcp_ack_update_rtt ] TCP: 192.168.0.111:42884 -> 43.129.25.208:38000 ESTABLISHED CA_Open out:(p0 r0) unack:106249688 mem:(w0 r0) timer:(loss_probe, 0.376s) *rtt:128ms, rtt_min:128ms*
**Rtt** представляет собой сглаженное значение RTT, а **rtt_min** — фактическое значение RTT во время подтверждения текущего отправленного сообщения.
## Четыре: вопросы и ответы
### 4.1 BPF_GLOBAL_DATA не поддерживается
Запуск программы приводит к следующей ошибке:
map 'kprobe.rodata': failed to create: Invalid argument(-22)
Это вызвано тем, что текущее ядро не поддерживает BPF_GLOBAL_DATA. Необходимо перекомпилировать nettrace, добавив при компиляции `NO_GLOBAL_DATA=1`:
make NO_GLOBAL_DATA=1 all
### 4.2 bpf_jiffies64 не поддерживается
Ошибка запуска программы:
unknown func bpf_jiffies64#118
Эта проблема вызвана тем, что текущая версия ядра имеет проблемы с проверкой DEAD CODE. Для решения проблемы необходимо перекомпилировать nettrace и добавить при компиляции `NO_GLOBAL_DATA=1`.
### 4.3 Длина события хранится в стеке
Ошибка запуска программы:
R5 min value is negative, either use unsigned or 'var &= const'
Для повышения эффективности nettrace при выводе событий выводит только часть необходимых данных. В старых версиях ядер иногда возникают
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Комментарии ( 0 )