Динамический IP-адрес бесплатно или смена IP при смене устройства для подключения к сети
Коротко о главном
Эта статья обычного Петербуржца, пользующегося весьма нестабильным провайдером WestCall, создающим проблемы на ровном месте. А так же имеющего скорость интернета до 100 Mbit/s (в часы «пик» может проседать до 50 Mbit/s) и статический IP адрес (услуга входит в тарифный план).
Суть проблемы
Хронология
[15:30] Браузер, при переходе на yandex.ru, отобразил сначала ошибку «Нет доступа к сети (ERR_NETWORK_CHANGED)», а затем «Веб-страница не доступна (No response from host)».
[15:35] Проблема решилась, однако вместо веб-страницы мне показали страницу провайдера с предложением войти в личный кабинет (или что-то в этом роде, в общем ввести абонентский номер (логин) и пароль) для продолжения использования услуг телефонии. Стандартная процедура при завершении сессии в Личном Кабинете провайдера, или ее истечении.
[15:36] Введя логин и пароль, делаю попытку войти. Неудачно. Появилась надпись «Ошибка авторизации»
[15:43] Ошибка исчезла, меня перенаправили на страницу завершения текущей сессии, после чего потребовали повторного ввода логина и пароля (тоже стандартная процедура, уже привык к ней)
[16:00] Мне удалось «войти в Интернет», однако теперь перекидывает на страницу настроек DHCP для пользователя. Там было сказано, что «Ваш IP-адрес (172.23.XXX.XXX) не попадает в диапазон адресов пользователя» и предложение сменить MAC адрес (они это объясняли тем, что «Ваш MAC-адрес не записан ни на одном из наших серверов» или что-то в этом духе, так как у WestCall стоит привязка по MAC-адресу устройства, а, как вы помните, я переключил интернет-кабель из роутера в компьютер).
[16:05] Изменяю MAC-адрес, привязанный к IP 172.21.XXX.XX (не сразу заметил несоответствие 172.23.XXX.XXX и 172.21.XXX.XX) на текущий MAC. Сохранил.
[16:06] О чудо, мне открыли глаза на то, что у меня, каким-то Робертом Кайо, поменялся IP-адрес! Только не так явно объяснили: «Ваш MAC-адрес (такой-то, да такой-то) уже привязан к другому IP-адресу, отличному от 172.23.XXX.XXX.». В этот момент у меня в квартире родились две Сверхновых прямо подо мной, на моем же стуле.
Да, у меня получилось, я изменил IP, не вставая со своего расплавившегося от двух Сверхновых стула…
[16:10] За мой сгоревший стул уже отвечает провайдер. Дословно:
— Здрасьте. Вот такая-то проблема, такие-то действия производил, назвал данные WinMTR. Объясните почему и исправьте.
— День добрый! Сейчас у нас массовая потеря чего-то там, большинство пользователей не могут выйти в интернет. Сейчас посмотрим. Назовите Ваш лицевой счет и подождите минутку. [Через минуту] А, так у вас MAC адрес другой привязан к IP (тут мой стул сгорел раз 5), сейчас интернет работает?
— [Объясняю ему, что проблема не в MAC- а в IP-адресе]
— А, хорошо, понял, сейчас проверю. Подождите еще минуту. [Через 2 минуты] Проверьте, пожалуйста, сейчас.
[захожу на yandex.ru]
— С грехом пополам, но все грузится. Спасибо, до свидания.
— Всего доброго!
[16:20] Переключаю кабель из ПК обратно в роутер и «вхожу в интернет».
[16:21] Вижу ту же самую ошибку, что и в 16:00 — IP адрес опять изменился. При этом КАК возможно изменить IP, просто переключив кабель из одного разъема в другой, я не представляю.
[16:22] Повторяется все то же самое, что и в 16:10, но без переключения кабеля.
[16:30] Это может показаться черной магией, но спустя 1,5 часа страданий, мне, совместно с провайдером, удается решить эту проблему.
Заключение
Если ваш IP меняется вместе с переключением кабеля, предпримите следующее:
Спасибо за прочтение. Извините, что без картинок. Пока у меня не было интернета, как видите, мне было не до скриншотов 🙂
Клиенты получают неверные настройки (IP-адреса) по DHCP
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Второй вариант чаще всего гораздо удобнее, ведь настройки не придётся прописывать руками. Но наверняка многим приходилось сталкиваться с ситуацией, когда клиентское устройство получает совершенно другой IP-адрес вместо корректных настроек от DHCP-сервера. И тогда очень важно понять, почему так происходит и как всё быстро исправить. В посте я расскажу об этом.
Симптомы
Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.
Диагностика на стороне клиента
Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).
Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного.
Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х
Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.
Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.
Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер
Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.
Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.
Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:
Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на DHCP на сетевом оборудовании.
Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет
Если это так, то стоит вернуться к проверке не только самого IP-адреса, но и всех остальных настроек. И особенно к проверке маски, адреса шлюза по умолчанию и адресов DNS-серверов, так как именно через шлюз устройству предстоит связываться с другими сетями, а с помощью DNS-серверов — преобразовывать доменные имена в IP-адреса.
Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.
Диагностика на стороне сервера
Итак, диагностика на стороне клиента показала, что проблем не обнаружено. Независимо от реализации DHCP-сервера, теперь необходимо пошагово проверить ряд предположений, начиная с самых простых и очевидных.
Запущен ли DHCP как сервис?
В зависимости от ОС, дистрибутива и реализации DHCP-сервера, проверить это можно по-разному. Если сервис остановлен и есть ошибки в конфигурационных файлах, то запустить его не удастся. Это первая отправная точка. Если сервис запущен, можно переходить к следующему шагу.
Приходят ли запросы от клиентов на DHCP-сервер?
Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.
Нет ни запросов, ни ответов?
Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.
Запрос(ы) есть, ответа(ов) нет?
Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).
Второй вариант чаще всего гораздо удобнее, ведь настройки не придётся прописывать руками. Но наверняка многим приходилось сталкиваться с ситуацией, когда клиентское устройство получает совершенно другой IP-адрес вместо корректных настроек от DHCP-сервера. И тогда очень важно понять, почему так происходит и как всё быстро исправить. В посте я расскажу об этом.
Симптомы
Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.
Диагностика на стороне клиента
Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).
Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного.
Вариант 1. Текущий IP-адрес имеет вид 169.254.Х.Х
Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.
Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:
При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.
Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер
Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.
Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.
Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:
Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors.com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на DHCP на сетевом оборудовании.
Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет
Если это так, то стоит вернуться к проверке не только самого IP-адреса, но и всех остальных настроек. И особенно к проверке маски, адреса шлюза по умолчанию и адресов DNS-серверов, так как именно через шлюз устройству предстоит связываться с другими сетями, а с помощью DNS-серверов — преобразовывать доменные имена в IP-адреса.
Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.
Диагностика на стороне сервера
Итак, диагностика на стороне клиента показала, что проблем не обнаружено. Независимо от реализации DHCP-сервера, теперь необходимо пошагово проверить ряд предположений, начиная с самых простых и очевидных.
Запущен ли DHCP как сервис?
В зависимости от ОС, дистрибутива и реализации DHCP-сервера, проверить это можно по-разному. Если сервис остановлен и есть ошибки в конфигурационных файлах, то запустить его не удастся. Это первая отправная точка. Если сервис запущен, можно переходить к следующему шагу.
Приходят ли запросы от клиентов на DHCP-сервер?
Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.
Нет ни запросов, ни ответов?
Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.
Запрос(ы) есть, ответа(ов) нет?
Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.
КЛАДРируем адреса произвольной формы (ч.1 — импорт)
Таким видом у нас в стране можно считать код по справочникам КЛАДР или ФИАС.
Первый из них уже несколько лет считается устаревающим, но отличается более простой структурой и исторически продолжает использоваться во множестве систем, поскольку вполне подходит для большинства задач.
Давайте научимся разбирать строку адреса «туда и обратно», а заодно познакомимся с некоторыми алгоритмическими подходами и их реализацией на SQL.
Получение справочника КЛАДР
База КЛАДР в настоящее время администрируется ФНС и представлена на сайте ГНИВЦ в виде периодически (примерно раз в неделю) обновляемого архива. Для начала мы научимся его скачивать, исправлять некоторые ошибки и преобразовывать в более подходящую для наших задач структуру.
Исходный архив
Чтобы не пытаться обрабатывать архив и обновлять данные в нашей базе повторно, будем сохранять в ней этот таймстамп для последующих сравнений.
Если же таймстамп файла не совпал с сохраненным, распакуем полученный архив:
Результатом будет 7 DBF-файлов в DOS-кодировке:
Переберем все эти файлы, формируя единый скрипт выгрузки данных через psql в COPY-формате:
По итогу мы получаем большой-большой SQL-файл примерно такого вида:
Импорт данных
Защита от параллельной загрузки
В результате такого подхода мы всегда знаем, кто и когда проверял наличие обновлений, и кому это удалось.
Соберем все вместе в единый скрипт:
Реквизиты доступа к базе и КЛАДР-источник в нашем случае будут храниться в app.conf :
Поисковая база
А зачем нам вообще нужна какая-то другая структура? Чем нас не устраивают таблицы в оригинальном КЛАДР-архиве?
хранение адресных объектов (улиц и населенных пунктов) в разных структурах
невозможность наложить эффективные для поиска индексы
Напомню, что оригинальный код КЛАДР, согласно документации имеет вид СС РРР ГГГ ППП УУУУ АА , где:
То есть если вынести признак актуальности в отдельное поле, то у кодов многих объектов (например, городов) в конце окажутся нули, которые стоит безболезненно отсечь. И тогда коды будут иметь строго ограниченный набор длин в соответствии с «уровнем» объекта:
При этом, как видим, коды «вышестоящих» объектов становятся префиксами кодов объектов вложенных.
Что же получилось по структуре?
Это основные таблицы, данные в которые импортируются непосредственно из соответствующих DBF по модели наложения «диффов», описанной в статье «DBA: грамотно организовываем синхронизации и импорты»:
Здесь регулярное выражение используется для отсечения «хвостовых» нулей по маске до необходимой нам длины. То есть нельзя просто так взять 76 000 010 000 и убрать все 4 последних ноля, поскольку 010 тут является значимым кодом города.
Здесь регулярными выражениями мы приводим форматы исходной базы в списки конкретных номеров домов:
Зачем нам понадобятся такие дополнительные структуры, и как их использовать для организации эффективного подстрочного поиска, рассмотрим в следующей части статьи.
Контрагент ООО «ДИНК»
Краткое досье
| ИНН | 7703822254 |
| Находится | г. Москва, наб. Пресненская aдрес |
| Возраст | 5 лет 11 месяцев |
| Деятельность | Торговля оптовая неспециализированная |
| Масштаб деятельности | |
| Учредитель | Барышева Наталья Викторовна (100%; 34,5 тыс. руб.) |
| Руководитель | Лебедева Елена Викторовна (генеральный директор) |
Обратите внимание
Полное досье контрагента
Общие сведения
Полное наименование организации: ООО «ДИНК»
ИНН: 7703822254
ОГРН: 5147746378423
Место нахождения: 123317, г. Москва, наб. Пресненская, 8, стр. 1, пом. 48С КОМ.2
Вид деятельности: Торговля оптовая неспециализированная (код по ОКВЭД 46.90)
Статус организации: коммерческая, ликвидирована (прекращение деятельности юридического лица в связи с исключением из ЕГРЮЛ на основании п.2 ст.21.1 Федерального закона от 08.08.2001 №129-ФЗ)
Организационно-правовая форма: Общества с ограниченной ответственностью (код 12300 по ОКОПФ)
Регистрация в Российской Федерации
Организация ООО «ДИНК» зарегистрирована в едином государственном реестре юридических лиц 6 лет 9 месяцев назад 20 ноября 2014.
Чем занимается организация, виды деятельности
Основной вид деятельности организации: Торговля оптовая неспециализированная (код по ОКВЭД 46.90).
Дополнительно организация заявила следующие виды деятельности:
| 41.20 | Строительство жилых и нежилых зданий |
| 43.99 | Работы строительные специализированные прочие, не включенные в другие группировки |
| 45.1 | Торговля автотранспортными средствами |
| 45.20 | Техническое обслуживание и ремонт автотранспортных средств |
| 46.18 | Деятельность агентов, специализирующихся на оптовой торговле прочими отдельными видами товаров |
| 46.18.99 | Деятельность агентов, специализирующихся на оптовой торговле прочими товарами, не включенными в другие группировки |
| 46.41 | Торговля оптовая текстильными изделиями |
| 46.41.2 | Торговля оптовая галантерейными изделиями |
| 46.43 | Торговля оптовая бытовыми электротоварами |
| 46.49 | Торговля оптовая прочими бытовыми товарами |
| 46.62 | Торговля оптовая станками |
| 46.63 | Торговля оптовая машинами и оборудованием для добычи полезных ископаемых и строительства |
| 46.66 | Торговля оптовая прочей офисной техникой и оборудованием |
| 46.69 | Торговля оптовая прочими машинами и оборудованием |
| 47.41 | Торговля розничная компьютерами, периферийными устройствами к ним и программным обеспечением в специализированных магазинах |
| 47.41.4 | Торговля розничная офисными машинами и оборудованием в специализированных магазинах |
| 47.52.7 | Торговля розничная строительными материалами, не включенными в другие группировки, в специализированных магазинах |
| 47.59.1 | Торговля розничная мебелью в специализированных магазинах |
| 47.78 | Торговля розничная прочая в специализированных магазинах |
| 47.78.1 | Торговля розничная фотоаппаратурой, оптическими приборами и средствами измерений, кроме очков, в специализированных магазинах |
| 47.8 | Торговля розничная в нестационарных торговых объектах и на рынках |
| 47.91.1 | Торговля розничная по почте |
| 47.99 | Торговля розничная прочая вне магазинов, палаток, рынков |
| 52.29 | Деятельность вспомогательная прочая, связанная с перевозками |
| 64.11 | Деятельность Центрального банка Российской Федерации (Банка России) |
| 64.19 | Денежное посредничество прочее |
| 69.10 | Деятельность в области права |
| 69.20 | Деятельность по оказанию услуг в области бухгалтерского учета, по проведению финансового аудита, по налоговому консультированию |
| 70.22 | Консультирование по вопросам коммерческой деятельности и управления |
| 71.11 | Деятельность в области архитектуры |
| 73.11 | Деятельность рекламных агентств |
| 73.20 | Исследование конъюнктуры рынка и изучение общественного мнения |
| 79.11 | Деятельность туристических агентств |
Где находится ООО «ДИНК», юридический адрес
ООО «ДИНК» зарегистрировано по адресу: 123317, г. Москва, наб. Пресненская, 8, стр. 1, пом. 48С КОМ.2. ( показать на карте )
По текущему юридическому адресу других организаций не значится.
Кто владелец (учредитель) организации
Учредителями ООО «ДИНК» являются:
| Учредители | доля | стоимость | с какой даты |
|---|---|---|---|
| Барышева Наталья Викторовна (ИНН: 772021960640) | 100% | 34,5 тыс. руб. | 20.11.2014 |
Кто руководит ООО «ДИНК»
Руководителем организации (лицом, имеющем право без доверенности действовать от имени юридического лица) является генеральный директор Лебедева Елена Викторовна (ИНН: 503211406753).
Кем руководит и владеет организация (числится учредителем)
ООО «ДИНК» не значится учредителем каких-либо российских юридических лиц.
Финансы организации
Уставный капитал ООО «ДИНК» составляет 34,5 тыс. руб.
Организация не применяет специальных режимов налогообложения (находится на общем режиме).
Сведения о суммах недоимки и задолженности по пеням и штрафам за 2019 год
| Налог на добавленную стоимость | 1,42 млн. руб. из них: недоимка по налогу 1,07 млн. руб. пеня 349 тыс. руб. штраф 1 тыс. руб. |
| Налог на прибыль | 50,4 тыс. руб. из них: недоимка по налогу 39,5 тыс. руб. пеня 10,8 тыс. руб. |
| НЕНАЛОГОВЫЕ ДОХОДЫ, администрируемые налоговыми органами | штраф 400 руб. |
| Итого | 1,47 млн. руб. |
Сведения об уплаченных организацией суммах налогов и сборов за 2019 год
| НЕНАЛОГОВЫЕ ДОХОДЫ, администрируемые налоговыми органами | 0 руб. |
| Налог на прибыль | 0 руб. |
| Страховые взносы на обязательное медицинское страхование работающего населения, зачисляемые в бюджет Федерального фонда обязательного медицинского страхования | 0 руб. |
| Налог на добавленную стоимость | 0 руб. |
| Страховые взносы на обязательное социальное страхование на случай временной нетрудоспособности и в связи с материнством | 0 руб. |
| Страховые и другие взносы на обязательное пенсионное страхование, зачисляемые в Пенсионный фонд Российской Федерации | 0 руб. |
| Итого | 0 руб. |
Лица, связанные с ООО «ДИНК»
На основе данных единого государственного реестра юридических лиц прослеживаются следующие взаимосвязи лиц, имеющих прямое или косвенное отношение к организации:
Последние изменения в ЕГРЮЛ
Представленные на этой странице данные получены из официальных источников: Единого государственного реестра юридических лиц (ЕГРЮЛ), Государственного информационного ресурса бухгалтерской отчетности (ГИР БО), с сайта Федеральной налоговой службы (ФНС), Минфина и Росстата. Указанные данные подлежат опубликованию в соответствии с законодательством РФ.
Разработкой программного обеспечения и обработкой информации занимается ООО «Профсофт» (ИНН 3906992381). Используется информация только из официальных открытых источников. Если вы заметили ошибку или некорректную информацию, пожалуйста, свяжитесь с разработчиком.
