Tag Archives: сети

Новые технологии ломают интернет. Часть 1.

Иногда долго работая в ИТ, начинаешь видеть, как вещи ломаются. Как технологии, которые раньше работали как часы, перестают работать. Наблюдать как новые технологии ломают то, что хорошо работало, вызывает грусть. Потому что, когда тебе нужно забить гвоздь ты берешь молоток. И оказывается, что молоток перестал заколачивать гвозди и теперь к одной задаче заколотить гроздь, возникает другая — найти молоток. Это не прогресс новых технологий, а регресс. В этом посте будет несколько примеров таких технологий. Пост разделен на две части для удобства. Это первая часть.

Спиритуальное продолжение этого поста

1. SPF, DKIM не работают без DMARC.

ОК, здесь все работает, только обязательно связке.

Для защиты от спама используются следующие DNS записи:

  • SPF— указывает какой сервер может отправлять почту с домена. Защищает поле MAIL FROM. Это поле передается в SMTP сессии и не видно почтовому клиенту.
  • DKIM — указывает публичный ключ. Защищает поле FROM. Это поле передается в теле письма и видно почтовому клиенту.

Проблема в том, что SPF и DKIM не работают без DMARC.

Пример.

  1. Злоумышленник регистрирует DNS домен fake-bank.org
  2. Злоумышленник создает в домене записи:
    • A — mail.fake-bank.org IN 1.1.1.1
    • MX — mail.fake-bank.org
    • SPF — v=spf1 mx ip4:1.1.1.1 -all. Публикуется в корне fake-bank.org.
    • DKIM — v=dkim1;p=pubkey. Публикуется в поддомене selector._domainkey.fake-bank.org.
  3. Злоумышленник шлет подделанное письмо жертве притворяясь настоящим банком
  4. Почтовый сервер получает письмо от злоумышленника
    MAIL FROM: fraud@fake-bank.org - RFC5321.MailFrom
    FROM: manager@bank.org - RFC5322.From
    DKIM: d=fake-bank.org
  5. Почтовый сервер проверяет MX запись. Письмо было отправлено с сервера mail.fake-bank.org. Который отвечает за отправку писем в домене.
  6. Почтовый сервер проверяет SPF запись. Письмо было отправлено с домена fake-bank.org. Который разрешает отправку писем севером mail.fake-bank.org
  7. Почтовый сервер проверяет DKIM запись. Заголовки и письмо не менялись. Потому что публичный ключ домена fake-bank.org подтверждает это.
  8. Почтовый сервер пропускает письмо как валидное.
  9. Клиент открывает письмо и видит, что оно отправлено от менеджера его банка.
  10. Происходит подлог. И это проблема безопасности.

Вывод.

  • Без DMARC записи SPF и DKIM не работают. Нужно использовать DMARC совместно с SPF и DKIM. Именно DMARC задает действие при котором SPF или DKIM не проходят проверку.
    DMARC позволяет использовать соответствие (alignment) поля FROM: полю MAIL FROM:.
  • DMARC указывает действие (p=), которое должен совершить получатель письма, если DKIM и SPF не проходят проверку. Если один из них проходит, то письмо валидное.
  • Чтобы прошла DKIM проверка. Домен в DKIM заголовке письма (DomainKey-Signature: a=rsa-sha1;s=selector;d=fake-bank.org) должен соответствовать домену в поле FROM (bank.org).
  • Чтобы прошла SPF проверка. Домен в RFC5321.MailFrom (MAIL FROM) или RFC5321.EHLO/HELO поле SMTP должен соответствовать домену в поле FROM (bank.org).
  • Если ни одна из проверок не проходит, то письмо невалидное. Клиент применяет политику, указанную в записи DMARC.
  • В рассматриваемом примере проверка DKIM не пройдет.

DMARCv=dmarc1;p=none. Публикуется в поддомене _dmarc.bank.org. Защищает получаетеля сфабрикованного письма от домена bank.org от злоумышленника.

Проверка записи DMARC

nslookup -type=TXT _dmarc.bank.org

Проверка записи SPF

nslookup -type=TXT bank.org

Проверка записи DKIM

nslookup -type=TXT selector._domainkey.bank.org

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10

2. HTTP2 connection reuse и reverse proxy

HTTP2 использует TLS1.2 и выше для шифрования и аутентификации. Клиент по TLS указывает в поле SNI к какому серверу идет подключение. Таким образом адрес сайта передается два раза: в TLS Client Hello поле SNI и в HTTP заголовоке Host.

Небольшое отклонение: в новом HTTP они перевели HTTP/1.1 Host заголовок в HTTP/2 :authority заголовок. И с их использованием возникают проблемы. 😐
Использование заголовка :authority в HTTP2 для той роли, что играл заголовок Host в HTTP1.1 имеет объяснение. Название идет из RFC 3986, в котором authority имеет следующий вид
authority = [ userinfo "@" ] host [ ":" port ]
Однако часть userinfo обозначается устаревшей и запрещается к использованию в HTTP2. Т.е. в authority будет включен имя хоста и порт опционально.

А еще в HTTP3 версии (т.е. в следующей после HTTP2) они убрали поддержку передачи открытым тексктом (в HTTP2 была такая возможность) и перевели на транспортный протокол UDP.

HTTP2 использует постоянное подключение. При подключении к одному северу на один порт клиент предпочтительно будет использовать установленное подключение.
Из-за этого может произойти объединение (HTTP2 coalescing). Два сервера за обратным прокси начинают выглядеть для клиента как один. Т.е. в HTTP2 когда адрес резолвится в IP адрес и совпадает с предыдущим IP и сертификат совпадает с предыдущим сертификатом, то используется текущее соединение. В HTTP1.1 каждый запрос создавал новое подключение. И это проблема безопасности.

Пример

  • Обратный прокси (HAProxy)
  • Два HTTPS веб сайта опубликованы на нем: site1.example.org и site2.example.org
  • Прокси использует использует SNI из запроса для направления на веб сервер (SNI proxy)
    • site1 располагается на веб сервере .1
    • site2 располагается на веб сервере .2
  • Оба веб сайта используют один wildcard *.example.org сертификат
  1. Клиент веб браузер подключается к первому сайту site1.example.org
  2. Клиент получает адрес обратного прокси
  3. Клиент запускает этап согласования TLS
  4. Прокси получает TLS Client Hello
  5. В SNI запроса указан сайт подключения — site1.example.org
  6. Прокси пропускает запрос на веб сервер .1
  7. Клиент получает сертификат сайта *.example.org
  8. Клиент успешно подключается
  9. Клиент запрашивает подключение ко второму сайту site2.example.org
  10. Веб браузер видит, что IP адрес и сертификат те же самые
  11. Клиент использует HTTP2 установленное соединение
  12. Клиент пропускает этап согласования TLS
  13. Прокси не получает TLS Client Hello
  14. Прокси использует существующее подключение
  15. Прокси пропускает запрос на веб сервер .1 вместо .2
  16. Веб сервер .1 получает данные, предназначенные для веб сервера .2. И это проблема.
  17. Клиент получает ошибку 404

Для данной ситуации был создан специальный код HTTP 421. Веб сервер может его отправить, если определит, что клиент запрашивает не тот сервер. Но это не всегда работает.

Misdirected Request
The client needs a new connection for this request
as the requested host name does not match the Server Name Indication (SNI)
in use for this connection.

Вывод.

Отключить HTTP2 на стороне сервера. Если это возможно. Например HTTP2 также не поддерживает аутентификацию Windows authentication (NTLM/Kerberos/Negotiate) там сломаны картинки

Чтобы в IIS отключить HTTP2:

  1. Пуск → regedit
  2. Открыть путь: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  3. В папке Parameters, правой кнопкой мыши создать 2 новых DWORD (32-bit) значения:
  4. EnableHttp2Tls
    EnableHttp2Cleartext

  5. Проверить что оба зачения установлены в 0(отключено) изменив нажав правую кномку мыши и выбрав «Изменить…»
  6. Перезагрузить систему

Другой вариант. Использовать разные сертификаты. Или использовать разные IP адреса.

Начиная с 1 сентярбя 2020 браузеры перестанут принимать сертификаты дольше чем на 398 дней.

Источник 1
Источник 2
Источник 3
Источник 4
Источник 5
Источник 6
Источник 7
Источник 8
Источник 9
Источник 10
Источник 11
Источник 12
Источник 13
Источник 14
Источник 15
Источник 16
Источник 17
Источник 18
Источник 19
Источник 20
Источник 21

Вторая часть.

HTTP Boot замена PXE

Ранее в блоге был пост про PXE загрузку. Установка Windows по сети. За подробностями можно перейти почитать. Если вкратце. Настроив DHCP сервер можно указать клиенту сетевое расположение установочного образа системы (NBP).

Прогресс не стоит на месте и на место PXE приходит HTTP Boot. Про сравнение двух подходов и пойдет речь.

Первое, что нужно знать про HTTP Boot — он работает только на системах UEFI версии 2.5 и выше. Поэтому если у вас по-прежнему используется BIOS возможно следует обновиться. Тем более что крупнейший производитель чипов Intel собирается прекратить поддержку BIOS после 2020. Напоминание, что переключение с BIOS на UEFI загрузку требует изменения в установленной ОС.

Дальше вспомним про работу PXE.

Загрузка в PXE

Процесс загрузки PXE использует несколько протоколов.

  1. DHCP
    1. Клиент передает опцию PXEClient
    2. Сервер передает опцию сервера загрузки и опцию имени файла загрузки
  2. TFTP
    Клиент скачивает образ Network Bootstrap Program (NBP)
  3. Запуск исполняемого образа
    Передача управления ему. Дальнейшая загрузка использует протоколы, реализованные в самом образе. Так для Windows это SMB протокол.

Читать далее

Настройка прокси сервера на CentOS

ЦЕЛЬ

Веб прокси сервер.

Требования::

  • Зашифровать подключение через HTTPS.
  • Аутентификация по пользователю/паролю.
  • Расщепление горизонта (split horizon), т.е. проксирование только определенных веб сайтов.

ИСПОЛЬЗУЕМЫЕ РЕШЕНИЯ

  • Прокси сервер
    • Squid
    • nginx
  • Шифрование HTTPS
    • Let’s encrypt
  • Аутентификация
    • PAM
  • Расщепление горизонта
    • PAC
    • plain text
  • Браузер
    • Firefox (поддерживается Chrome)
  • Веб сайт
    • 2ip.ru

ИМПЛЕМЕНТАЦИЯ

  1. Установка прокси сервера
  1. Squid
  2. nginx
  • Настройка прокси сервера HTTP
    1. Без аутентификации
    1. Squid
    2. nginx
  • Проверка
  • PAM basic аутентификация
    1. Squid
    2. nginx
  • Проверка
  • Настройка расщепления горизонта
    1. Plain text
    2. PAC
    3. nginx
    4. Проверка
  • Получение сертификата
    1. nginx
    2. Let’s encrypt
  • Настройка прокси сервера HTTPS с PAM basic аутентификацией
    1. Squid
    2. PAC
    3. Проверка
  • Настройка обновление сертификата автоматически
  • АДРЕСА

    • proxy.example.org — DNS имя прокси сервера
    • 1.1.1.1 — IP адрес прокси сервер внешний (перед NAT)
    • 10.1.1.4 — IP адрес прокси сервер внутренний (за NAT)
    • 195.201.201.32 — IP адрес 2ip.ru (проверка внешнего IP)
    • 2.2.2.2 — IP адрес клиента браузера внешний

    1. УСТАНОВКА ПРОКСИ СЕРВЕРА

    В качестве прокси сервера проверим Squid и nginx.

    1.1. SQUID

    Примечание: вся действия будут производиться под пользователем root. Это не безопасно. Для защиты рекомендуется использовать отдельного пользователя и команду sudo.

    Команда установки

    yum install squid

    1.2. NGINX

    Для работы прокси и аутентификации в nginx нужно установить модули. nginx по умолчанию не понимает метод HTTP CONNECT, поэтому HTTPS проксирование без модуля работать не будет. Для установки модулей nginx придется пересобрать из исходников.

    Команда установки

    yum install nginx

    Узнаем версию nginx

    nginx -V

    смотрим вывод nginx version

    Узнаем опции, с которыми был скомпилирован nginx

    nginx -V

    смотрим вывод configure arguments

    Устанавливаем зависимости для компиляции PCRE, ZLIB, OPENSSL

    yum groupinstall 'Development Tools'
    yum install zlib zlib-devel pcre pcre-devel openssl openssl-devel pam-devel

    Скачиваем исходный код nginx
    Примечание: версию используем ту же, что в выводе команды выше

    mkdir -p /root/sources/nginx
    cd /root/sources/nginx
    wget http://nginx.org/download/nginx-1.14.0.tar.gz
    tar zxf nginx-1.14.0.tar.gz

    Скачиваем модуль PAM
    Примечание: используем PAM модуль из репозитория проекта

    mkdir -p /root/sources/http_auth_pam_module
    cd /root/sources/http_auth_pam_module
    wget https://raw.githubusercontent.com/sto/ngx_http_auth_pam_module/master/ngx_http_auth_pam_module.c
    wget https://raw.githubusercontent.com/sto/ngx_http_auth_pam_module/master/config

    Скачиваем модуль HTTP CONNECT
    Примечание: используем модуль для версии из команды выше. Репозиторий проекта

    mkdir -p /root/sources/http_proxy_connect_module
    cd /root/sources/http_proxy_connect_module
    wget https://raw.githubusercontent.com/chobits/ngx_http_proxy_connect_module/master/patch/proxy_connect_1014.patch
    wget https://raw.githubusercontent.com/chobits/ngx_http_proxy_connect_module/master/ngx_http_proxy_connect_module.c
    wget https://raw.githubusercontent.com/chobits/ngx_http_proxy_connect_module/master/config

    Применим патч http_proxy_connect_module

    cd /root/sources/nginx/nginx-1.14.0
    patch -p1 < /root/sources/http_proxy_connect_module/proxy_connect_1014.patch

    Настраиваем сборку ngnix из исходного кода с модулями
    Примечание: параметры могут отличаться от ваших.

    ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' --add-module=/root/sources/http_auth_pam_module --add-module=/root/sources/http_proxy_connect_module

    Примечание: Для получения команды нужно взять опции компиляции из вывода команды выше и добавить к ним два модуля —add-module=/root/sources/http_auth_pam_module —add-module=/root/sources/http_proxy_connect_module

    Собираем nginx из исходных кодов
    ВНИМАНИЕ: Команда установки сама заменит файлы в папках. Если у вас на этом nginx сервере запущено что-то оно может перестать работать.

    make
    make install

    Читать далее

    Wireshark дешифрока HTTPS

    Все больше в современных сетях используется шифрование с помощью TLS. Благодаря чему в ПО захвата пакетов, таком как Wireshark, невозможно увидеть внутренности пакета. В этом посте рассказывается про асимметричное шифрование, TLS в версии 1.3 и как можно расшифровать его пакеты в Wireshark.

    Содержание:

    • Введение в шифрование с открытым ключом
    • Реализация шифрования в TLS
    • Отличие TLS версии 1.3
    • Дешифровка TLS с помощью Wireshark

    Введение.

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

    Существуют два ключа (псевдослучайная последовательность данных). Для простоты они называются открытый и закрытый ключи. Они связаны между собой таким образом, что шифрование с помощью одного ключа, можно расшифровать с помощью другого.

    Практически это выглядит так. Клиент запрашивает данные у сервера. Сервер шифрует данные с помощью своего закрытого ключа и передает клиенту. Клиент берет открытый ключ сервера и расшифровывает данные. Клиент шифрует данные с помощью открытого ключа сервера и передает их серверу. Сервер расшифровывает данные с помощью своего закрытого ключа. Для этой работы клиенту нужно знать открытый ключ сервера. Он его берет из сертификата сервера.


    Читать далее

    Skype for Business и Juniper SRX внешний доступ

    Небольшой пост по конкретной проблеме в взаимодействии Skype for Business и Juniper SRX.

    Проблема: Показ экрана работает внутри сети. Показ экрана не работает при подключении снаружи.

    Проблема оказалась в следующем:

    Что происходит по шагам:

    1. SfB клиент инициирует TCP подключение отправив SYN сегмент
    2. SfB сервер сбрасывает это TCP подключения отправив RST сегмент
    3. Juniper записывает эту TCP сессию на удаление через 2 секунды
    4. Клиент снова инициирует TCP подключение с теми же самими параметрами (IP адрес источника, IP адрес получателя, порт и протокол)
    5. Сервер принимает TCP подключение
    6. Но для Juniper эта та же самая сессия, помеченная для удаления
    7. Спустя приблизительно 1,5 секунды с момента установления TCP сессии Juniper разрывает сессию
    8. Все следующие пакеты от клиента будут отбрасываться Juniper потому что они не подпадают ни под одну отслеживаемую сессию. И они не смогу создать новую сессию потому что не содержат SYN флага.

    Проблемы могло бы не быть, если выполнялось одно из условий:

    • Клиент Skype for Business инициировал каждое новое соединение TCP с новым портом
    • SRX закрывал TCP сессию сразу при получении RST сегмента

    К счастью, в SRX существует возможность отключить 2 секундное ожидание перед разрывом TCP сессии. Существует даже отдельная KB на сайте Juniper посвященная этой проблеме [2].

    В разделе конфигурации security flow tcp-session есть параметры изменяющие работу с TCP сессиями. Нас интересует настройка rst-invalidate-session. Если ее включить, то соединение будет разрываться сразу при получении RST сегмента.

    Решение кратко:
    В режиме конфигурации SRX ввести

    set security flow tcp-session rst-invalidate-session
    commit
    exit

    Источник 1

    Источник 2

    Filezilla ENETUNREACH или как антивирусы сканируют трафик

    По запросу «Filezilla ошибка ENETUNREACH» поисковая система выдает, что проблема в антивирусе (Касперский) и для ее решения необходимо добавить filezilla.exe в исключения (доверенные приложения). На форуме этого FTP клиента описывается механизм как антивирус анализурует трафик приложения. Дальше будет приведен перевод:

     Касперский перенаправляет весь сетевой трафик через свой процесс avp.exe по адресу 127.0.0.1 порт 1110.

    Как просходит нормальное FTP подключение без сетевого сканирования:

    1. Filezilla создает управляющее TCP-соединение до адреса 93.184.216.23
    2. Операционная система назначает адрес источника IP пакета как адрес исходящего интерфейса допустим 10.0.0.123
    3. После установления соединения для передачи команд Filezilla создает соединение для передачи данных
    4. Адреса источника и получателя IP пакета используются те же, что и в управляющем соединении Т.е. у соеденения для передачи данных адрес источника будет 10.0.0.123, а получателя — 93.184.216.23.

    Читать далее

    Коллектор sFlow на Logstash

    В данном посте будет описана процедура установки коллектора sFlow на базе ELK на CentOS 7 для сбора трафика со свитча Juniper.

    Компоненты:

    • Logstash — система принимающая данные, фильтрующая их и передающая их в Elasticsearch.
    • Elasticsearch — база данных, которая хранит информацию и осуществляет по ней поиск.
    • Kibana — служит для визуального представления данных, хранящихся в Elasticsearch.

    Взаимодействие компонентов выглядит так:

    10.10.10.10 — адрес сервера CentOS, где установлен ELK

    Читать далее

    Juniper SRX IPsec Site-to-Site VPN и Split-DNS

    В данной статье будет рассматриваться настройка VPN между офисами (site-to-site) и особенности, если трафик возникает на самом SRX на примере Split-DNS.

    В Juniper SRX существуют два варианта организации site-to-site VPN: на основе политик (policy based) и на основе маршрутов (route based). Они отличаются способом, по которому трафик попадает в туннель. Здесь будет рассматриваться route based VPN при котором на основании маршрутов в таблице маршрутизации SRX будет принимать решение об включении трафика в туннель. Эти маршруты могут быть получены автоматически (за счет протоколов динамической маршрутизации), но здесь будет показан самый простой ручной вариант, на основе статических маршрутов.

    Когда филиал соединен с центральным офисом, или, когда все серверы расположены в центре обработки данных, до которого организован site-to-site VPN, один из вопросов сетевой доступности является DNS сервер компании. В данном случае речь идет про ситуацию, когда одни и те же доменные сетевые имена для внутрисетевых клиентов и для внешних клиентов разрешаются по-разному. Этот процесс называется split-DNS, когда домен компании обслуживают два DNS сервера: один для клиентов изнутри, второй для клиентов снаружи.

    Клиенты в филиале как правило получают сетевые настройки от DHCP сервера. В филиале SRX может выполнять роль DHCP сервера. В этом случае опция 6 — «DNS сервер» может содержать адрес как внутреннего DNS сервера компании, так и самого SRX. Для чего это может понадобиться? Если в VPN туннель вы направляете только трафик до внутренних серверов и сервисов, то логично, что запросы на внутренний сервер DNS отправлялись только для доменных имен внутренних ресурсов. Именно поэтому выдавать клиентам филиала адрес SRX как DNS сервера позволит регулировать на самом SRX на какой DNS сервер отправлять запрос. Это функция называется Proxy DNS.

    Читать далее

    VPN сервер на основе StrongSwan на CentOS

    В последних версиях мобильной и настольной ОС компании Apple появилась полноценная поддержка VPN подключений по IKEv2. В системах компании Microsoft она была реализована еще с Windows 7. Таким образом можно предположить, что IKEv2 станет мультиплатформенным стандартом для виртуальных сетей, заменив устаревший и небезопасный PPTP.

    В данной статье будет описана настройка StrongSwan как сервера IKEv2 VPN, а также проверено подключение к нему с Windows и MacOS.

    VPN сервер и клиенты IKEv2 могут аутентифицировать себя как по ключам, так и по сертификатам. Причем для каждой стороны можно задать свой выбор. Для уменьшения требований, предъявляемых к клиентам, было выбрано чтобы сервер StrongSwan аутентифицировал клиентов по логину и паролю, а VPN клиенты аутентифицировали сервер по сертификату, выданному доверенным центром сертификации.

    Последовательность действий:

    1. Получение сертификата для сервера StrongSwan
    2. Установка и настройка сервера StrongSwan
    3. Проверка подключения к серверу с Windows и MacOS

    Читать далее

    Два сетевых механизма связанных с NAT

    В данном посте пойдет речь про два не связанных напрямую между собой сетевых механизма: Hairpin NAT и Proxy ARP. Стоит заметить, что их использование необходимо только в определенных случаях NAT, далее будет описано подробнее.

    Hairpin NAT


    Сценарий: веб сервер и клиент находятся за общим NAT. Веб сервер опубликован на внешнем адресе 80.80.80.80 на порту 80. Внутренние IP адреса у клиента и сервера из одной подсети 10.10.10.0/24.

    Клиент не может подключиться к веб серверу по внешнему адресу. При этом от других клиентов (с мобильного телефона, из дома и пр.) доступ работает.

    Читать далее