Как проверить пинг dns сервера
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.
Диагностика сетевой связности (ping, arp, traceroute)
В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.
В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ip addr или ifconfig выведут IP-адрес и маску сети:
В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.
Теперь проверим, указан ли шлюз по умолчанию. Команды ip route или route покажут имеющиеся маршруты:
В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом default, либо адресом 0.0.0.0). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.
Синтаксис команды ping IP/имя опции:
Скриншот №3. Синтаксис команды
В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.
Часто используемые параметры:
- ping –c количество — указать количество пакетов, которое будет отправлено адресату (по умолчанию пакеты отправляются до тех пор, пока пользователь не прервет выполнение команды. Этот режим можно использовать, чтобы проверить стабильность сетевого соединения. Если параметр RTT будет сильно изменяться в ходе проверки, значит где-то на протяжении маршрута есть проблема);
- ping –s количество — указать размер пакета в байтах. По умолчанию проверка производится малыми пакетами. Чтобы проверить работу сетевых устройств с пакетами большего размера, можно использовать этот параметр;
- ping –I интерфейс — указать сетевой интерфейс, с которого будет отправлен запрос (актуально при наличии нескольких сетевых интерфейсов и необходимости проверить прохождение пакетов по конкретному сетевому маршруту).
В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:
Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.
Часто используемые параметры:
- arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
- arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.
Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
- traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
- traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
- traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
- traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve --status:
Используемый сервер также будет указан в настройках интерфейса, в разделе DNS Servers. В более старых версиях Ubuntu потребуется проверить содержимое файлов /etc/resolve.conf и /etc/network/interfaces. Если сервер не указан, воспользуйтесь статьей для ОС Ubuntu 18.04 или CentOS, чтобы скорректировать настройки.
Проверить работу сервиса разрешения имен нам помогут утилиты nslookup или dig. Функционально они почти идентичны: G-вывод утилиты dig содержит больше диагностической информации и гибко регулируется, но это далеко не всегда нужно. Поэтому используйте ту утилиту, которая удобна в конкретной ситуации. Если эти команды недоступны, потребуется доставить пакеты на CentOS/RedHat:
yum install bind-utils
sudo apt install dnsutils
После успешной установки сделаем тестовые запросы:
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Скриншот №11. Отправка тестового запроса 1
Скриншот №12. Отправка тестового запроса 2
Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
Часто используемые параметры:
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
Все существующие в интернете веб-ресурсы сообщаются друг с другом посредством цифровых IP -адресов, а те читабельные и дружественные пользователю адреса, которые вы видите в адресной строке браузера есть ничто иное как своего рода псевдонимы. За их преобразование в понятные компьютерам IP -адреса отвечает специальная служба, именуемая DNS . Ее настройки предоставляются интернет-провайдером, однако ничто не мешает вам их сменить, перейдя на альтернативные DNS .
Среди которых наиболее популярными являются Google Public DNS , Яндекс DNS и CloudFlare .
Замена адресов DNS не представляет сложности, но этого может оказаться недостаточно, нужно еще убедиться, что сетевой трафик действительно проходит через настроенные сервисы. К сожалению, в Windows нет очевидного способа это сделать, хотя сама возможность такой проверки поддерживается.
Перейдите в любом браузере по указанному выше адресу и нажмите кнопку «Standart test», чтобы запустить стандартный тест.
В результате в колонке ISP вы получите имя службы DNS , которую используете в данный момент.
Если оно соответствует имени установленной вами ДНС-службы, значит всё в порядке. Есть еще расширенный тест (Extended test) , но отличается он только большим количеством запросов, гарантирующим обнаружение большего числа серверов.
Примечание: перед выполнением теста отключите VPN, если его используете, поскольку тогда результаты будут отличаться.Второй способ не столь удобен и информативен.
Для проверки DNS вы можете воспользоваться встроенной консольной утилитой nslookup.
Открыв командную строку, выполните в ней сначала команду chcp 1251 , а затем команду nslookup .
Я уже писал, о том, что такое IP-адреса и как проверить, под каким адресом вас видит внешний мир. Однако часто этой информации недостаточно для того, чтобы понять, какой все-таки адрес присвоен вашей сетевой карте, а также провести диагностику проблем подключения. Приведу список команд, которые можно использовать. (также у меня на сайте можно прочитать про визуальную настройку сетевых подключений)
Для начала необходимо открыть командную строку. Делается это так: нажимаете кнопку пуск, выбираете пункт "выполнить".
Альтернативные способ - нужно нажать клавишу Win (между Ctrl и Alt) и R одновременно, этот способ работает также и на Висте
Появляется окошко, в которое нужно вписать cmd и нажать ОК
Появляется та самая командная строка
В ней можно набирать и "вводить" команды, нажимая Enter. Результаты можно копировать - если нажать правую кнопку можно выделить нужный кусок, далее нужно еще раз нажать правую кнопку мыши.
Команда ping
Первая команда, с которой нужно познакомиться - это ping, проверяющую доступность заданного адреса. Введите команду ping 127.0.0.1. Должно получиться что-то такое (если команда не ping не работает, то, возможно, решить проблему поможет инструкция по исправлению ошибки cmd no command):
C:\Documents and Settings\Администратор>ping 127.0.0.1
Обмен пакетами с 127.0.0.1 по 32 байт:
Ответ от 127.0.0.1: число байт=32 время
Как мы видим, на адрес 127.0.0.1 было отправлено 4 пакета, и они все достигли цели. Что же это был за адрес и почему я был уверен, что пакеты дойдут? Ответ прост - пакеты никуда не отправлялись, а оставались на вашем компьютере. Этот адрес специфичен и используется для loopback - пакетов, не уходящих никуда вовне. Отлично, можем теперь "пропинговать" адрес этого сайта: 212.193.236.38
C:\Documents and Settings\Администратор>ping 212.193.236.38
Обмен пакетами с 212.193.236.38 по 32 байт:
Ответ от 212.193.236.38: число байт=32 время=3мс TTL=55
Ответ от 212.193.236.38: число байт=32 время=3мс TTL=55
Ответ от 212.193.236.38: число байт=32 время=3мс TTL=55
Ответ от 212.193.236.38: число байт=32 время=3мс TTL=55
Статистика Ping для 212.193.236.38:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 3мсек, Максимальное = 3 мсек, Среднее = 3 мсек
C:\Documents and Settings\Администратор>
Можно заметить только одно отличие - пакеты доходили не мгновенно, а за 3 миллисекунды. Надеюсь, у вас тоже не было никакой задержки при доставке пакетов, а главное - вы не увидели строчки типа
Появление таких строчек означает, что часть пакетов теряется. Это свидетельствует о проблемах на линии или не сервере, к которомы вы обращаетесь.
Команда ipconfig
Следующая важная команда - ipconfig. Введите ее. У меня получилось вот так:
Настройка протокола IP для Windows
Ethernet - Ethernet адаптер:
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.17.240
C:\Documents and Settings\Администратор>
В данном случае получился адрес 192.168.17.139. Можно этот адрес тоже пропинговать (вы пингуйте свой) - пакеты должны доходить мгновенно. Основной шлюз - это адрес, на который компьютер отправляет пакеты, не найдя подходящего адреса в своей сети. Так, в моем случае все пакеты, кроме пакетов на 192.168.17.* будут отправлены на 192.168.17.240, а тот компьюьтер уже должен решить, что с ними делать и куда их переправлять дальше. Примечание: локальная сеть, то есть те адреса, пакеты на которые не отправляются на шлюз, определяется при помощи маски - нолик на последнем месте и 255 на всех предыдующих как раз и означает, что может буть произвольным последнее число в IP-адресе.
Одно из стандартных действий при поиске проблем подключения - пропинговать свой шлюз. Если пакеты до него не доходят, то, видимо, проблема где-то рядом, например, поврежден или плохо воткнут сетевой шнур. Также стоит знать, где физически находится компьютер с вашим основным шлюзом - у провайдера, где-то в доме, а, может, это - можем в вашей квартире. Примечание: некоторые компьютеры настроены не откликаться на запросы команды ping. Поэтому отсутствие пинга - не стопроцентная гарантия отсутствия связи с адресом.
Более подробную информацию можно получить командой ipconfig /all. У меня получилось:
C:\Documents and Settings\Администратор>ipconfig /all
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : sander
Основной DNS-суффикс . . . . . . : MSHOME
Тип узла. . . . . . . . . . . . . : смешанный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
Порядок просмотра суффиксов DNS . : MSHOME
Ethernet - Ethernet адаптер:
Описание . . . . . . . . . . . . : Broadcom 440x 10/100 Integrated Controller
Физический адрес. . . . . . . . . : 00-16-D4-63-03-65
Dhcp включен. . . . . . . . . . . : да
Автонастройка включена . . . . . : да
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.17.240
DHCP-сервер . . . . . . . . . . . : 192.168.17.240
DNS-серверы . . . . . . . . . . . : 212.192.244.2
Аренда получена . . . . . . . . . : 2 февраля 2009 г. 11:00:28
Аренда истекает . . . . . . . . . : 9 февраля 2009 г. 11:00:28
C:\Documents and Settings\Администратор>
Самую полезную информацию я выделил жирным. DHCP-сервер выделил мне динамиеский адрес на основе моего MAC-адреса или физического адреса. Мои DNS-сервера - это 212.192.244.2 и 212.192.244.3.
Другие команды
Команда tracert позволяет проследить путь пакетов от вашего компьютера до цели. Попробуйте, например протрассировать путь до этого сайта: tracert it.sander.su. Строки в выводе трассировки есть точки, через которые проходит пакет на своем пути. Первой точкой будет ваш шлюз. Использование команды tracert позволяет найти источник проблем при связи с каким-либо адресом. Пакеты, посылаемые командой tracert, имеют показатель TTL - time to live - целое положительное число. Каждый маршрутизатор на пути уменьшает этот показатель на 1, если TTL падает до нуля, то трассировка заканчивается. По умолчанию используется начальный TTL равный 30, задать другое значение можно опцией -h.
Посмотреть таблицу маршрутизации можно командой route print, однако я не буду подробно останавливаться на ней - это тема отдельной статьи.
Команда netstat позволяет просмотреть список установленных соединений. В режиме по умолчанию команда пытается преобразовывать все IP-адреса в доманные имена (при помощи службы DNS), что может работать медленно. Если вас устраивает числовой вывод, вызывайте команду netstat -n. Если вас также интересуют открытые порты на вашем компьютере (что означает, что он готов принимать соединения по этим портам), то вызовите команду с ключом -a: например, netstat -na. Можно также вызвать команду netstat -nb, чтобы посмотреть, какие процессы установили соединения. Команда netstat -r эквивалентна команде route print.
Команда netsh позволяет изменить настройки сети через командную строку. Введите команду netsh interface ip show address. У меня получилось:
C:\Documents and Settings\Администратор>ipconfig /all
Настройка интерфейса "Ethernet"
DHCP разрешен: да
Метрика интерфейса: 0
Запоминаем название (Ethernet) и теперь командой netsh interface ip set address name="Ethernet" source=static addr=192.168.0.33 mask=255.255.255.0 gateway=192.168.0.1 gwmetric=30 задаем IP-адрес. Для динамического подключения: netsh interface ip set address name="Ethernet" source=dhcp. На этом сайте также можно прочитать об интерактивной настройке параметров сети
Решение проблем с соединениями в сетях Windows (часть 3)
Когда вы вводите эту команду, Windows отправит ping запрос на адрес 127.0.0.1. Независимо от IP адреса вашей машины, Windows всегда будет использовать 127.0.0.1 в качестве адреса локального хоста. Таким образом, альтернативой вышеприведенной команде является команда:
После ввода этой команды вы должны увидеть результаты успешно выполненного запроса ping, равно как и для других ping команд. Пример использования данной команды показан на рисунке A.
Рисунок A: Вы должны увидеть результат успешно выполненного запроса ping, когда опрашиваете адрес локального хоста
Опрос адреса локального хоста ничего не дает для диагностирования проблем взаимодействия с удаленным узлом. Однако он позволяет убедиться в том, что локальный стек TCP/IP работает корректно. Если вы опросите адрес локального хоста и получите отчет об ошибке, говорящий о том, что с опрашиваемым узлом нет связи, это практически всегда означает неправильную настройку TCP/IP, или что определенная часть локального TCP/IP стека повреждена. На собственном опыте могу сказать, что обычно эту проблему можно решить путем удаления существующего TCP/IP протокола с компьютера, и повторного введения этого протокола.
Опрос основного шлюза
В предыдущей части этой серии я упоминал о том, что существует несколько аспектов TCP/IP настройки, которые вам нужно запомнить или записать и иметь под рукой во время исправления проблем. К этой информации относятся IP адреса основного шлюза или предпочитаемого DNS сервера.
Предположив, что узлы, с которыми вы хотите связаться, расположены в удаленной сети или другом сегменте вашей корпоративной сети, то в этом случае вам нужно попробовать опросить основной шлюз. Это можно выполнить простым добавлением IP адреса основного шлюза в команду ping. К примеру, если вы посмотрите на рисунок B, вы заметите, что в моей конфигурации TCP/IP адрес основного шлюза будет 147.100.100.100. После этого я просто опрашиваю (ping) этот адрес. В результате этого проводится проверка того, что локальная машина может связаться с основным шлюзом. Это также говорит вам о том, что коммуникации на локальном узле работают, как должно, по крайней мере, на уровне IP адреса.
Рисунок B: Опрос основного шлюза проверяет, что IP пакеты могут достичь основного шлюза сети
Опрос DNS сервера
Итак, к настоящему моменту мы убедились в том, что коммуникация на уровне IP между локальным компьютером и основным шлюзом работает. Однако это не гарантирует того, что имена узлов разрешаются в IP адреса. В первой части этой серии я показывал, как можно использовать полное доменное имя (FQDN) в сочетании с командой ping для проверки того, что DNS сервер выполняет свою работу. Существует пара других способов, с помощью которых вы легко можете проверить разрешение DNS имен.
Во-первых, вы можете опросить IP адрес DNS сервера, как показано на рисунке C. Это не гарантирует того, что разрешение имен работает корректно, однако это позволяет убедиться в том, что локальная машина корректно взаимодействует с DNS сервером.
Рисунок C: Следует убедиться в том, что узел может взаимодействовать с вашим DNS сервером
Во-вторых, вы можете использовать команду Nslookup, чтобы убедиться в том, что разрешение имен работает корректно. Для этого просто введите команду Nslookup, за которой должно идти полное доменное имя удаленного узла. Команда Nslookup должна суметь разрешить полное доменное имя в IP адрес, как показано на рисунке D.
Рисунок D: Команда Nslookup говорит вам, способен ли ваш DNS сервер разрешать имя хоста
Вышеприведенный рисунок сначала может ввести в заблуждение, если вы не привыкли к работе с командой Nslookup. Изначально, кажется, что в этом окне есть отчет об ошибке. Однако если присмотреться, видно, что первая часть вернувшейся информации относится к локальному DNS серверу. Это можно сказать, так как указанный IP адрес совпадает с IP адресом DNS сервера. Однако, нижний раздел вернувшейся информации предоставляет вам IP адреса того узла, который вы запрашивали. Если этот IP адрес есть в списке, DNS запрос был успешным.
Если процесс разрешения имени был неудачным, то возникла проблема с DNS. Действительная проблема может быть любой из ряда проблем, связанных с DNS сервером. К примеру, адрес ретрансляции сервера DNS может быть неверным или у DNS сервера может отсутствовать доступ к интернету, который ему необходим для связи с DNS серверами более высокого уровня. Также DNS служба сервера DNS могла быть остановлена. Однако, как правило, такой тип проблем влияет и на других клиентов, поскольку несколько клиентов зависят от одного DNS сервера.
Если DNS разрешение имен успешно, очень важно проверить вернувшийся во время процесса разрешения имени IP адрес. Это можно сделать путем сравнения вернувшегося IP адреса с действительным IP адресом, используемым удаленным узлом. Эти IP адреса должны совпадать, но существуют условия, при которых может возникать несовпадение, в результате чего имеет место сбой коммуникации.
Если вы встретитесь с несовпадением IP адреса, это может указывать на заражение клиента вредоносным ПО, либо это может указывать на заражение DNS. DNS заражение – это процесс, в котором кэш DNS наполняется недействительными или неправильными IP адресами.
Если вы столкнетесь с такой проблемой, то я рекомендовал бы вам просканировать клиентскую машину на предмет вредоносного ПО. Очень важно сканировать на предмет вирусов и шпионских программ, поскольку оба этих типа вредоносного ПО могут вызывать такую проблему. Если на машине не обнаружено вредоносного ПО, попытайтесь сбросить DNS кэш. Вы можете сбросить кэш DNS путем ввода следующей команды:
Пример выполнения этой команды показан на рисунке E.
Очень важно помнить, что только тот факт что DNS кэш содержит неточные IP адреса не означает, что имеет место DNS заражение. Иногда узлам присваиваются новые IP адреса, а DNS КЭШу требуется определенное время, чтобы узнать о внесенных изменениях.
Рисунок E: Если подозреваете, что ваш DNS кэш может содержать неточную информацию, то его нужно сбросить
Заключение
В этой части я объяснил, как можно убедиться в том, что стек локального протокола TCP/IP работает корректно. Затем я рассказал о том, как тестировать способность локального узла связываться с DNS сервером и сервером основного шлюза, и как тестировать разрешение имени хоста. В следующей части этой серии статей я расскажу о других распространенных проблемах, которые можно обнаружить с помощью команды ping, а также начну разговор о проблемах маршрутизации.
Автор: Брайн Позей (Brien Posey)
Постовой
Семейство Лада 110 – это современное продолжение классического стиля ОАО АВТОВАЗ, воплощённое в различных кузовных версиях – седан, хэтчбек, универсал – от непринуждённо-классической до спортивно-динамичной. Автомобили этого семейства дебютировали много лет назад, но до сих пор являются самыми продаваемыми моделями сегмента рынка, ориентированного на российского потребителя.
Этот пост October 29, 2008 at 7:47 pm опубликовал molse в категории Настройка компьютера, Общие статьи для сисадминов. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.
Читайте также: