Архив рубрики: Networks

Как МТС подменяет DNS-ответы для своих клиентов

Один из самых простых вариантов проверки чего-нибудь сетевого «извне» на рабочем месте — проверить это на телефоне. Недавно возникла необходимость проверить доступен ли снаружи один из поддоменов компании и, как обычно, чтобы не лезть на внешние DNS-сервера, я решил воспользоваться одной из утилит под Android для получения информации от DNS-серверов (Ping & Net).

Проверка показала, что A-записи для домена есть, их две и указывают они на амазоновские айпишники, где у нас тоже есть часть сервисов. Начали разбираться и искать эти адреса, не смогли найти и решили все же сходить в наш DNS. Оказалось, что такого поддомена у нас нет во внешней сети!

Проверил ответ от гугловского DNS — тоже пусто. Решил попробовать спросить напрямую у DNS-серверов МТС, но не с телефона, а с рабочего ПК. Естественно, они отклонили запросы (сервера 134.17.1.1 и 134.17.1.0). Запрос несуществующего имени, отправленный напрямую к этим DNS-серверам с телефона из сети МТС, возвращает адреса A-записей 52.214.129.184 и 52.209.63.28. Соответственно, если вы пытаетесь зайти на любой несуществующий домен из сети МТС — у вас открывается прекрасная «информативная» рекламная страница МТС (portal.ncnd.mts.by) с (внезапно!) ошибкой 404 и кучей рекламного контента (который, на секундочку, тратит ваш трафик, если у вас не безлимит). ИМХО, такие действия вводят пользователей в заблуждение: ошибка 404 — совсем не то же самое, что «домен не найден».

В качестве одной «ложки меда в бочке дегтя» можно назвать то, что на этой же странице можно управлять данной «услугой». Т.е. отписаться от этого чудо-портала. После отписки DNS-сервера отвечают, что такого домена нет, но мобильные браузеры все равно каким-то образом редиректят на portal.ncnd.mts.by и при этом не могут его открыть. МТС, такой МТС…

Route-based IPSEC VPN между Ubuntu 18.04 (libreswan) и Cisco Router

В корпоративном секторе, особенно в больших компаниях с более, чем одним офисом зачастую возникает необходимо в site-to-site VPN-соединениях. Конечно, большинство провайдеров предлагает вам «прямую связь» через их оборудование. Но как-то так сложилось, что надежность этого решения зависит только от самого провайдера и из-за некорректных действий одного-единственного админа может зависеть целостность вашей сети. Такие объединения сетей частенько выполняются просто на уровне отдельного тегированного VLAN. И если кто-то внезапно (вполне может быть по неосторожности) скрестит вашу сеть с другими или просто снимет теги на портах — вы рискуете получить в свою сеть трафик от многих клиентов провайдера, а они, в свою очередь, получат беспрепятственный доступ в вашу сеть. Именно по этой причине доверять стоит только собственноручно поднятому IPSEC VPN. Если что-то пойдет не так — VPN просто развалится и сети будут изолированы друг от друга.

В каких случаях Route-based VPN удобнее, чем обычный site-to-site? Например, если вы хотите предоставить N хостам из одной сети доступ к ресурсам в другой сети, но создавать для этого клиентские соединения неудобно. Также, если у вас много подсетей с одной из сторон (или с обеих) и вы не хотите плодить IPSEC SA (как произойдет в случае обычного Policy-based IPSEC VPN). Или, например, вы хотите пробросить весь трафик нескольких клиентов через роутер в другой стране. Во всех этих случаях полезно и удобно будет использовать Route-based VPN.

Итак, начнем с оборудования. В моем случае это был Cisco Router серии ASR с одной стороны и сервер с Ubuntu 18.04 с другой. Цель — пустить трафик N клиентов в интернет через удаленный сервер. Начнем с Ubuntu:

  1.  Установим libreswan.
    apt-get install libreswan
  2. Разрешим форвардинг пакетов и отключим редиректы.
    echo "net.ipv4.ip_forward = 1" | tee -a /etc/sysctl.conf
    echo "net.ipv4.conf.all.accept_redirects = 0" | tee -a /etc/sysctl.conf
    echo "net.ipv4.conf.all.send_redirects = 0" | tee -a /etc/sysctl.conf
    for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done
  3. Применим настройки.
    sysctl -p
  4. Создадим в /etc/ipsec.d/ файл с конфигурацией нашего VPN и поместим в него следующий контент:
    nano /etc/ipsec.d/route-based-ipsec-vpn.conf
    
    config setup
        protostack=netkey
    conn vpn
        authby=secret
        pfs=no
        rekey=yes
        keyingtries=3
        type=tunnel
        auto=start
        ike=aes256-sha1;modp1536
        phase2alg=aes256-sha1;modp1536
        left=11.11.11.11
        right=22.22.22.22
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        mark=5/0xffffffff
        vti-interface=vti01
        vti-routing=no
    Если один из ваших роутеров находится за NAT (например left), вам необходимо заменить в директиве left адрес на внутренний адрес интерфейса (left=10.0.0.1) и добавить директиву leftid с реальным адресом (leftid=11.11.11.11).  И, конечно, пробросить порты UDP 500, 1701 и 5000 на этот роутер. В противном случае туннель не поднимется.

    Краткие пояснения по конфигурационному файлу:
    authby=secret — авторизация по паролю, а не по сертификатам;
    vti-interface=vti01 — интерфейс, который будет создан автоматически при создании туннеля;
    vti-routing=no — не создавать маршруты на интерфейс туннеля автоматически.

  5. Далее необходимо придумать сгенерировать стойкий пароль на много символов (все равно вам его запоминать не надо) и внести его в файл.
    nano /etc/ipsec.d/route-based-ipsec-vpn.secrets
    
    11.11.11.11 22.22.22.22: PSK "%908A2R5vX9O694aoxh1"
  6. Делаем ipsec restart и ipsec verify. После ipsec verify у нас должно появиться что-то типа этого:
    Verifying installed system and configuration files
    
    Version check and ipsec on-path                         [OK]
    Libreswan 3.23 (netkey) on 4.15.0-1021-aws
    Checking for IPsec support in kernel                    [OK]
     NETKEY: Testing XFRM related proc values
             ICMP default/send_redirects                    [OK]
             ICMP default/accept_redirects                  [OK]
             XFRM larval drop                               [OK]
    Pluto ipsec.conf syntax                                 [OK]
    Two or more interfaces found, checking IP forwarding    [OK]
    Checking rp_filter                                      [ENABLED]
     /proc/sys/net/ipv4/conf/all/rp_filter                  [ENABLED]
     /proc/sys/net/ipv4/conf/default/rp_filter              [ENABLED]
     /proc/sys/net/ipv4/conf/eth0/rp_filter                 [ENABLED]
     /proc/sys/net/ipv4/conf/ip_vti0/rp_filter              [ENABLED]
      rp_filter is not fully aware of IPsec and should be disabled
    Checking that pluto is running                          [OK]
     Pluto listening for IKE on udp 500                     [OK]
     Pluto listening for IKE/NAT-T on udp 4500              [OK]
     Pluto ipsec.secret syntax                              [OK]
    Checking 'ip' command                                   [OK]
    Checking 'iptables' command                             [OK]
    Checking 'prelink' command does not interfere with FIPS [OK]
    Checking for obsolete ipsec.conf options                [OK]
    

    Если failed нигде не написано — можно жить.

  7. Заставляем трафик прятаться за айпишник нашего интерфейса при выходе наружу (в данном примере внешний интерфейс — eth0) при помощи iptables:
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  8. Прописываем маршруты в нашу удаленную сеть (предположим, что на другом конце есть сети 192.168.0.0/24 и 192.168.10.0/24).
    ip route add 192.168.0.0/24 dev vti01
    ip route add 192.168.10.0/24 dev vti01
  9. На этом этапе настройка Ubuntu закончена и мы переходим к настройке Cisco ASR. Продолжение следует (линк на него будет в конце этой статьи).

При написании этого материала помог личный опыт, статья https://libreswan.org/wiki/Route-based_VPN_using_VTI и гугл.

Не открывается web-интерфейс HP 1910. Свитч не пингуется.

Если у вас достаточно крупная сеть и вы используете коммутаторы HP 1910, то вы тоже могли столкнуться с такой проблемой: в определенные моменты времени вы просто не можете открыть админку коммутатора и даже пинговать его не можете. Но при этом, с других компьютеров/серверов он вполне может открываться и пинговаться. И более того, если вы будете долго и упорно его пинговать — вам он тоже начнет отвечать! Причины этой, на первый взгляд непонятной проблемы, очень просты: у свичей HP 1910 очень маленькая ARP-таблица — 256 записей. Со временем, при работе в сети >256 хостов, она может заполниться на 100% и может случиться так, что ваш адрес туда не попадет.

Как это лечить:

  1. Для начала, необходимо все же попасть на свитч с какого-нибудь адреса (например, с DHCP-сервера — чаще всего запись о нем есть в ARP-таблице).
  2. Заходим в ARP-management и удаляем все динамические записи.
  3. Добавляем там же необходимые нам статические записи (например, IP-адрес и MAC того компьютера/сервера, с которого чаще всего осуществляется доступ к свичам). Полезно будет также добавить IP и MAC шлюза по умолчанию — это защитит от внезапного появления в сети еще одного шлюза (но в этом случае лучше еще и статическую запись MAC с привязкой к порту сделать).

После этого свитч всегда будет отвечать на ваши пинги и веб-интерфейс будет открываться без проблем.

Обновление прошивки HP 1910 через COM-порт

Иногда на коммутаторах HP 1910 бьются файлы прошивок. Чаще всего это, по всей видимости, происходит из-за износа флэш-памяти и в таких случаях программно ему уже не помочь. Но бывают случаи, когда он «просто почему-то побился» и коммутатор можно оживить путем форматирования флэш-памяти и заливки новой прошивки.

Для форматирования флэшки необходимо подключиться консольным кабелем, настроить соединение (38400, 8, 1, N) и нажать при загрузке Ctrl+B. Таким образом мы попадем в BootWare-меню. В нем необходимо нажать Ctrl+F и согласиться с форматирование флэшки. Желательно перед этим убедиться в наличии у вас свежей прошивки в виде файла *.bin :)

Далее перезагружаем коммутатор и снова входим в BootWare. На этот раз он сделает это сам — прошивки-то нет. В Bootware выбираем пункт 2 «Enter Serial SubMenu». Т.к. файл прошивки весит более 10 Мб — лучше переключить Serial-интерфейс на скорость 115200. Для этого жмём и снова 5 (пункт 115200). И тут настает время задуматься над тем, каким именно образом мы будем слать на него файл. Далеко не всё ПО умеет слать файлы в COM-сессию. Putty, например, такого не делает. Для этого придется найти старенький, но так необходимый HyperTerminal (последний раз он входил в комплект Windows XP). В нем создаем новое подключение, выбираем параметры 115200, 8, None, 1, None (см. скриншот).

Далее жмем «ОК» и подключаемся. Выходим на один уровень выше (пункт 0). И выбираем пункт 2 — Update Main Application File. Коммутатор переходит в режим приема файла, а мы нажимаем «Transfer»->»Send File», выбираем в окошке прошивку коммутатора и протокол Xmodem:

Отдыхаем минут 40 и по окончанию передачи на запрос коммутатора выдаем имя файла. После этого выходим на основной уровень меню, File Control (4), Display All Files (1). Проверяем, чтобы напротив нашего файла прошивки стоял флаг М.

После этого выходим в главное меню и загружаемся (1). Если флэшка умерла не совсем — коммутатор загрузится и будет работать еще долго.

Загрузка cisco 4000 в ROMMON.

В процессе различных экспериментов с версиями прошивок cisco ISR 4000 может возникнуть ситуация, когда девайс перестает реагировать на ваши действия (в т.ч. в консоли). Т.е. он вполне себе отображает процесс загрузки, на него можно даже по ssh зайти… Правда, после входа по ssh не появляется стандартного приглашения командной строки. Что делать и как жить дальше?

Все довольно просто. Надо подключиться консольным кабелем к циске, выключить ее секунд на 30, открыть com-порт, например, в PuTTY, включить девайс. После появления первых строк текста в консоли — надо нажать Break и дождаться прерывания процесса загрузки с появлением приглашения ROMMON. Выглядит это примерно так:

Initializing Hardware ...

System integrity status: 00000610
Rom image verified correctly


System Bootstrap, Version 15.4(3r)S5, RELEASE SOFTWARE
Copyright (c) 1994-2015 by cisco Systems, Inc.

Current image running: Boot ROM0

Last reset cause: PowerOn
Cisco ISR4331/K9 platform with 4194304 Kbytes of main memory


no valid BOOT image found
Final autoboot attempt from default boot device...
Warning: filesystem is not clean
Warning: filesystem is not clean
File size is 0x1bcc9bfc


monitor: command "boot" aborted due to user interrupt


rommon 1 >

Если нажатие кнопки Break не помогает, можете воспользоваться соответствующей командой из меню PuTTY (Special command -> Break)

После появления приглашения можно выполнить команду dir bootflash: для просмотра файлов прошивок на флэшке и загрузить нужный образ (тот, с которым все было хорошо) командами:

BOOT=bootflash:isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin

sync

confreg 0x2102

reset

В этом случае, isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin — это файл образа в памяти устройства.

Если при попытке просмотра файлов командой dir bootflash: у вас появляется сообщение «Please reset before continuing», то простой reset вам не поможет. Необходимо выполнить следующее:

confreg 0x0

reset

После этих двух команд, циска перезагрузится в ROMMON без дополнительных плясок. Ну а дальше выполняем те же пункты, которые указаны сверху, загружаемся и не забываем указать нужный образ для загрузки с последующим сохранением конфигурации :)