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

Объединение двух сетей с одинаковой адресацией через интернет

Объединить две сети через интернет довольно легко. Создаем site-to-site vpn удобным нам способом и пользуемся. А если надо объединить две сети, в которых совпадают диапазоны используемых адресов? Например, две сети с адресацией 192.168.0.0/24. Поначалу может показаться, что идея глупая и это никому не надо. Но есть для этого и практическое применение — обеспечение бесперебойной работы инфраструктуры офиса на время переезда в другое место.

Одним из первых требований, естественно, будет отсутствие совпадающих IP-адресов — в итоге получится одна виртуальная сеть, в которой никто и догадываться не будет, что она разнесена физически на далекие расстояния. Единственным признаком будет увеличение задержек при доступе к «удаленной» части. Впрочем, это требование при сценарии переезда выполнить легко: одинаковых адресов в сети не было и в процессе переезда им неоткуда взяться.

Второе требование — достаточно широкий интернет-канал с низкими задержками. Желательно все это выполнить в пределах одного интернет-провайдера.

И, естественно, третьим требованием будет 2 сервера/компьютера с двумя нормальными сетевыми картами в каждом.

Если все требования выполнены, можно приступать к установке Debian. Именно на этой платформе мы будем реализовывать виртуальный свитч. Описывать установку debian бессмысленно, мануалов в сети предостаточно, да и визард вполне понятен.

После установки debian, ставим пакеты bridge-utils и tinc. Создаем директории /etc/tinc/mynetwork и /etc/tinc/mynetwork/hosts, где mynetwork — имя вашего соединения. В директории /etc/tinc/mynetwork создаем конфигурационный файл tinc.conf и вписываем туда следующие параметры:

Name = segment1
Mode = switch
ConnectTo = segment2

На втором, соответственно:

Name = segment2
Mode = switch
ConnectTo = segment1

В таком режиме, как можно догадаться, tinc будет работать как обычный свитч: пересылаться будут только те пакеты, которые направлены к хостам в другом сегменте. Для этого tinc будет регулярно рассылать ARP-запросы и поддерживать в актуальном состоянии таблицу MAC-адресов. Если же нужна пересылка абсолютно всего трафика — можно воспользоваться режимом «hub», что собственно и соответствует логике работы обычного хаба.

После того, как созданы конфигурационные файлы, надо сгенерировать ключи для установки защищенного соединения. Для этого выполняем команду:

tincd -n mynetwork -K

Эта команда генерирует private key и public key и сохраняет их в указанном месте (по умолчанию, в директории /etc/tinc/mynetwork хранится private key, а в директории /etc/tinc/mynetwork/hosts — public key. Имя публичного ключа совпадает с именем, заданным в tinc.conf параметром Name. Редактируем файл с публичным ключом и вписываем в первой строке (до начала —— BEGIN RSA PUBLIC KEY):

Address = 1.2.3.4

, где 1.2.3.4 — внешний адрес этого хоста. После этого копируем файлы из директории /etc/tinc/mynetwork/hosts с одного хоста на другой.

В директории /etc/tinc/mynetwork создаем скрипт tinc-up с содержимым:

#!/bin/sh

ifconfig $INTERFACE 0.0.0.0
brctl addif bridge $INTERFACE
ifconfig $INTERFACE up

Этот скрипт будет запускаться при старте демона tincd. Для автоматической установки соединения при старте системы, необходимо вписать имя сети (mynetwork) в файл /etc/tinc/nets.boot.

И, наконец, последнее, что необходимо сделать для того, чтобы все работало — создать, собственно, мост и сделать так, чтобы при старте системы он создавался автоматически. Для этого создаем скрипт /etc/tinc/createbridge со следующим содержимым:

#!/bin/sh

brctl addbr bridge
ifconfig bridge 192.168.0.2 netmask 255.255.255.0
ifconfig eth1 0.0.0.0
brctl addif bridge eth1
ifconfig eth1 up

, где 192.168.0.2 — адрес хоста в сети, а eth1 — интерфейс, к которому подключена локальная сеть. Делаем скрипт исполняемым и добавляем в /etc/network/interfaces в параметры интерфейса eth1 строку:

post-up /etc/tinc/createbridge

Перезагружаем оба сервера и проверяем наличие соединения между хостами. Если соединение не установлено — смотрим логи и проверяем наличие интернета. Если не помогло — читаем мануал :)

Организация DMZ-подсети на cisco ASA 5510 или как мы переходили на Cisco ASA — часть 4

Приоритезацию трафика для voip и skype сделали, наступил следующий этап подготовки к переходу — организация DMZ-подсети. Сама по себе организация DMZ-подсети ничего сложного из себя не представляет: отдельный порт для отдельной физической сети с отдельной адресацией. Естественно, доступа из подсети DMZ в основную подсеть быть не должно, доступ же из основной сети в подсеть DMZ должен быть без ограничений. Еще несколько условий для нашей реализации DMZ:

  1. Не все сервера из DMZ могут свободно ходить в интернет;
  2. Некоторые сервера могут ходить только по определенным адресам;
  3. Некоторые сервера должны иметь полный доступ в интернет;
  4. Скорость доступа в интернет для всех серверов должна быть ограничена;
  5. К некоторым сервисам в локальной сети все же должен быть доступ из DMZ;

Собственно, начнем с начала :) То есть с конфигурирования интерфейса:

interface Ethernet0/1
 nameif DMZ
 security-level 99
 ip address 192.168.15.1 255.255.255.0
 no shutdown

Security-level 99 как раз и отвечает за то, чтобы клиенты из DMZ, по умолчанию, не могли достучаться до локальной сети (она у нас имеет security-level 100). Клиенты из локальной сети, при такой настройке, будут иметь доступ к ресурсам DMZ.

Интерфейс сконфигурирован, пора прописывать правила доступа. Для облегчения восприятия, назовем access-list FROMDMZ — очевидно, что действовать он будет на пакеты исходящие из сети DMZ. Несмотря на запрет доступа из сети с меньшим security-level в сеть с бОльшим, лучше после разрешений доступа в локальную сеть к определенным сервисам, указать явный запрет на весь трафик из DMZ в локальную сеть.

Напомню, что Cisco ASA обрабатывает списки доступа (access-list) до первого совпадения. Таким образом, разрешение в начале списка подействует раньше, чем запрет на весь трафик в конце списка.

Итак, разрешим доступ всей подсети DMZ к почтовым серверам и DNS-серверам во всей локальной сети:

access-list FROMDMZ extended permit tcp 192.168.15.0 255.255.255.0 192.168.0.0 255.255.248.0 eq smtp
access-list FROMDMZ extended permit udp 192.168.15.0 255.255.255.0 192.168.0.0 255.255.248.0 eq domain

Далее запретим весь остальной трафик из DMZ в локальную сеть:

access-list FROMDMZ extended deny ip 192.168.25.0 255.255.255.0 192.168.8.0 255.255.248.0

Разрешим доступ к внешним DNS-серверам:

access-list FROMDMZ extended permit udp any host 8.8.8.8 eq domain
access-list FROMDMZ extended permit udp any host 8.8.4.4 eq domain

Создадим object-group для серверов, которым необходим доступ в интернет без ограничений по адресам:

object-group network DMZ-TO-INTERNET
 network-object host 192.168.15.3
 network-object host 192.168.15.5
 network-object host 192.168.15.8

Чаще всего для разрешения доступа к чему-либо более чем для одного клиента удобнее использовать object-group. В списках доступа важен порядок следования правил и правило с конкретным object-group будет всегда на одном и том же месте. Добавление же новых правил в конкретное место — более сложная операция.

Разрешим им доступ:

access-list FROMDMZ extended permit tcp object-group DMZ-TO-INTERNET any
 access-list FROMDMZ extended permit udp object-group DMZ-TO-INTERNET any

Далее можно разрешать доступ к конкретным внешним IP-адресам и в конце добавить запрет для остального трафика.

access-list FROMDMZ extended permit ip host 192.168.15.23 host 1.2.3.4
 access-list FROMDMZ extended deny ip any any

Учитывая то, что на нашей Cisco ASA настроен костыль, похожий на PBR (см. часть 1), нам придется заставить железяку выбирать интерфейс для трафика из локальной сети в DMZ, иначе весь трафик, адресованный на порты 80, 443, 8080 и др. будет уходить не на тот интерфейс. Для этого достаточно добавить правило:

static (DMZ,LOCAL) 192.168.15.0 192.168.15.0 netmask 255.255.255.0

При рестарте устройства, который в идеале вообще не произойдет никогда, это правило может загрузиться раньше остальных и тогда трафик опять пойдет «не туда». К сожалению, ASA не сохраняет порядок следования правил static. В таком случае это правило надо удалить и добавить заново:

no static (DMZ,LOCAL) 192.168.15.0 192.168.15.0 netmask 255.255.255.0
static (DMZ,LOCAL) 192.168.15.0 192.168.15.0 netmask 255.255.255.0

Костыль, но с этим надо как-то жить… На этой позитивной ноте, переходим к ограничению скорости. Создадим object-group и access-list:

object-group network DMZ-LIMIT
network-object host 192.168.15.3
network-object host 192.168.15.5
network-object host 192.168.15.9
access-list DMZ-LIMIT extended deny ip object-group DMZ-LIMIT 192.168.0.0 255.255.248.0
access-list DMZ-LIMIT extended deny ip  192.168.0.0 255.255.248.0 object-group DMZ-LIMIT
access-list DMZ-LIMIT extended permit ip object-group DMZ-LIMIT any
access-list DMZ-LIMIT extended permit ip any  object-group DMZ-LIMIT

Певые две строчки access-list нужны для исключения трафика в локальную сеть и из нее из будущего ограничения скорости: нам надо ограничивать только скорость доступа в интернет

Создаем class-map и policy-map.

class-map DMZ-LIMIT
 match access-list DMZ-LIMIT
policy-map DMZ-LIMIT
 class DMZ-LIMIT
  police output 4000000 10000

И, наконец, применим все к интерфейсу.

access-group FROMDMZ in interface DMZ
service-policy DMZ-LIMIT interface DMZ

RacoonVPN + Cisco ASA 5510 = Site-to-site IPSEC vpn

В связи с открытием нового офиса пришлось задуматься о канале связи между сетями. На основном офисе в качестве шлюза используется Cisco ASA 5510. На дополнительном необходимо было использовать решение «побюджетнее», т.к. офис сам по себе временный. Остановились на debian 7 :) Задача была простая: обеспечить полноценную работу удаленного офиса — доступ как в основную сеть без дополнительных настроек для пользователей, так и в сеть DMZ. При пробросе двух сетей есть некоторые нюансы, о которых речь пойдет чуть ниже.

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

Материалов по устройству IPSEC VPN в сети предостаточно. Вкратце могу напомнить, что есть 2 фазы установки соединения: защищенное IKE соединение и, собственно, ipsec-туннель.

Имеем:

  • Адреса локальной сети — 192.168.0.0/21
  • Адреса DMZ — 192.168.15.0/24
  • Адреса удаленного офиса — 192.168.30.0

Версия ПО на cisco asa — 8.2

Итак, приступим к настройкам на стороне Cisco. Создадим object-group для локальных сетей — так удобнее их добавлять/удалять в случае необходимости:

object-group network OUR-SUBNETS
 network-object 192.168.15.0 255.255.255.0
 network-object 192.168.0.0 255.255.248.0

Создадим access-list для выделения необходимого нам трафика:

access-list ISP1_cryptomap extended permit ip object-group OUR-SUBNETS 192.168.30.0 255.255.255.0

Пропишем параметры isakmp и ipsec, создадим crypto-map, transfrom-set и tunnel-group, укажем pre-shared-key:

crypto isakmp policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 86400
crypto isakmp identity address
crypto isakmp enable ISP1
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
tunnel-group aaa.bbb.ccc.xxx type ipsec-l2l
tunnel-group aaa.bbb.ccc.xxx ipsec-attributes
 pre-shared-key A_VeRy_SeCuRe_KeY 
crypto map ISP1 1 match address ISP1_cryptomap
crypto map ISP1_map 1 set peer aaa.bbb.ccc.xxx
crypto map ISP1_map 1 set transform-set ESP-AES-256-SHA
crypto map ISP1_map interface ISP1

Не забываем прописать правило для NAT 0:

access-list LANVPN extended permit ip 192.168.30.0 255.255.255.0 192.168.0.0 255.255.248.0
access-list LANVPN extended permit ip 192.168.0.0 255.255.248.0 192.168.30.0 255.255.255.0
access-list DMZVPN extended permit ip 192.168.30.0 255.255.255.0 192.168.15.0 255.255.255.0
access-list DMZVPN extended permit ip 192.168.15.0 255.255.255.0 192.168.30.0 255.255.255.0
nat (LOCAL) 0 access-list LANVPN
nat (DMZ) 0 access-list DMZVPN

При настройке соединения на linux будет лучше отключить firewall совсем — проще дебажить

Теперь переместимся на debian. Начнем с установки необходимого софта.

apt-get install racoon ipsec-tools

Отредактируем в соответствии с выбранными параметрами /etc/racoon/racoon.conf:

path pre_shared_key "/etc/racoon/psk.txt";


padding {
    maximum_length 20;  # maximum padding length.
    randomize off;      # enable randomize length.
    strict_check off;   # enable strict check.
    exclusive_tail off; # extract last one octet.
}

listen {
    isakmp bbb.ccc.ddd.xxx[500];
}

timer {
    # These value can be changed per remote node.
    counter 5;          # maximum trying count to send.
    interval 10 sec;    # maximum interval to resend.
    persend 1;          # the number of packets per a send.

    # timer for waiting to complete each phase.
    phase1 30 sec;
    phase2 15 sec;

}

log warning;


remote aaa.bbb.ccc.ddd {
    my_identifier address bbb.ccc.ddd.xxx;
    peers_identifier address aaa.bbb.ccc.ddd;
    exchange_mode main;
    initial_contact on;
    doi ipsec_doi;
    proposal_check claim; 
    lifetime time 24 hour;
    proposal {
        encryption_algorithm aes 256;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        dh_group 5;
    }
    generate_policy off;
    nat_traversal on;
    passive off;
    dpd_delay 30; 
}

sainfo subnet 192.168.30.0/24 any subnet 192.168.0.0/21 any {
    encryption_algorithm aes 256;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
    lifetime time 24 hour; 
}

sainfo subnet 192.168.30.0/24 any subnet 192.168.15.0/24 any {
    encryption_algorithm aes 256;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
    lifetime time 24 hour;
}

Впишем наш pre-shared key в файл /etc/racoon/psk.txt:

# IPv4/v6 addresses
aaa.bbb.ccc.ddd A_VeRy_SeCuRe_KeY

Отредактируем /etc/ipsec-tools.conf:

#!/usr/sbin/setkey -f

# NOTE: Do not use this file if you use racoon with racoon-tool
# utility. racoon-tool will setup SAs and SPDs automatically using
# /etc/racoon/racoon-tool.conf configuration.
#

## Flush the SAD and SPD
#
 flush;
 spdflush;

 spdadd 192.168.30.0/24[any] 192.168.0.0/21[any] any -P out ipsec esp/tunnel/bbb.ccc.ddd.xxx-aaa.bbb.ccc.ddd/require;
 spdadd 192.168.0.0/21[any] 192.168.30.0/24[any] any -P in ipsec esp/tunnel/aaa.bbb.ccc.ddd-bbb.ccc.ddd.xxx/require;

 spdadd 192.168.30.0/24[any] 192.168.15.0/24[any] any -P out ipsec esp/tunnel/bbb.ccc.ddd.xxx-aaa.bbb.ccc.ddd/unique;
 spdadd 192.168.15.0/24[any] 192.168.30.0/24[any] any -P in ipsec esp/tunnel/aaa.bbb.ccc.ddd-bbb.ccc.ddd.xxx/unique; 

Есть один очень важный нюанс: при создании туннеля для 2 и более подсетей, только у одной подсети может быть указан параметр require в ipsec-tools.conf. У остальных он должен быть unique. Иначе будет поднят туннель только для одной подсети. Много времени ушло на то, чтобы выяснить эту маленькую особенность…

Перезапускаем racoon и setkey:

/etc/init.d/setkey restart
/etc/init.d/racoon restart

Прописываем маршруты:

route add -host aaa.bbb.ccc.ddd dev eth1
ip route add 192.168.0.0/21 via aaa.bbb.ccc.ddd
ip route add 192.168.15.0/24 via aaa.bbb.ccc.ddd
route del aaa.bbb.ccc.ddd dev eth1

И, если никаких ошибок и очепяток допущено не было, идем отдыхать. Если же туннель не поднимается — начинаем построчно сравнивать конфиги на линуксе и cisco. Полезно также будет включить debug в конфиге racoon (log debug; вместо log warning;) и проверить логи.

Проверить статус туннеля на cisco можно командой sh ipsec sa. Мы должны увидеть что-то вроде:

interface: ISP1
    Crypto map tag: ISP1_map, seq num: 1, local addr: aaa.bbb.ccc.ddd

      access-list ISP1_cryptomap extended permit ip 192.168.0.0 255.255.248.0 192.168.30.0 255.255.255.0
      local ident (addr/mask/prot/port): (192.168.0.0/255.255.248.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/0/0)
      current_peer: bbb.ccc.ddd.xxx

      #pkts encaps: 162550535, #pkts encrypt: 162550493, #pkts digest: 162550493
      #pkts decaps: 84864900, #pkts decrypt: 84864899, #pkts verify: 84864899
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 162550536, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 5, #pre-frag failures: 47, #fragments created: 10
      #PMTUs sent: 47, #PMTUs rcvd: 1, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: aaa.bbb.ccc.ddd, remote crypto endpt.: bbb.ccc.ddd.xxx

      path mtu 1492, ipsec overhead 74, media mtu 1500
      current outbound spi: 0351F3AB
      current inbound spi : 462D7034

    inbound esp sas:
      spi: 0x462D7034 (1177382964)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 4915200, crypto-map: ISP1_map
         sa timing: remaining key lifetime (sec): 13076
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0x0351F3AB (55702443)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 4915200, crypto-map: ISP1_map
         sa timing: remaining key lifetime (sec): 13076
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

Немного о Unifi. Запуск unifi controller в виде сервиса в win2k8r2. Фильтр мак-адресов.

Рано или поздно во всех компаниях возникает вопрос расширения зоны покрытия wi-fi сети. Самый просто вариант — покупаем еще одну точку доступа и создаем еще одну сеть. Вариант подходит тем, у кого все сотрудники «стационарны» и не перемещаются из зоны действия одной сети в другую.

Вариант второй: покупаем точку той же модели, что и предыдущая и настраиваем wi-fi repeater. Выглядит просто, но на деле приходится сталкиваться с различными проблемами.

Вариант третий: купить точки Ubiquiti UniFi. Их прелесть в том, что сами точки, по сути, просто передатчики. Вся логика вынесена в отдельную программу-контроллер, которая может быть установлена на windows, linux, mac os. Таким образом, расширяется сеть путем установки новых точек доступа и добавления их в контроллер.

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

 1. Закройте UniFi, если он запущен.

2. Добавьте в переменную PATH путь к Java. Путь будет таким C:\Program Files (x86)\Java\jre6\bin или  C:\Program Files\Java\jre6\bin (либо jre7, в случае использования java 7).

3. Запустите с правами администратора командную строку (cmd.exe) и перейдите в директорию с файлами UniFi (cd «%userprofile%/Ubiquiti Unifi»).

4. Выполните java -jar lib\ace.jar installsvc

5. Запустите сервис.

А вот здесь, если у вас windows server 2008 r2, можно добавить пункт 6 — убедитесь, что сервис не стартует с «говорящей» ошибкой

The unifi controller service terminated with service-specific error: the operation completed successfully.

Проблема заключается в использовании 64-битной версии java. С ней запустить сервис, по какой-то причине, не удается. Для решения этой проблемы, необходимо доустановить jre x86 и изменить в переменной окружения PATH путь к java на директорию, содержащую версию x86 — C:\Program Files (x86)\Java\jre6\bin или C:\Program Files (x86)\Java\jre7\bin. После этого сервис запустится без ошибок.

Еще один вопрос, который может возникнуть — фильтрация MAC-адресов. Многие компании применяют этот метод в качестве одного из способов ограничения доступа в wi-fi сеть. По какой-то причине, разработчики UniFi не включили этот функционал в возможности контроллера. Но он доступен в виде дополнения от команды тестировщиков UniFi — unifi-lab-master.

Качаем дополнение, скачиваем Python 2.7 x86-64, если у вас windows x64  (не 3 ветку!), устанавливаем и добавляем в переменную PATH путь к нему — C:\Python27 по умолчанию. Качаем cURL с поддержкой SSL. Распаковываем его и кладем в директорию со скриптами unifi-lab. Редактируем, при необходимости, конфигурационный файл unifi_lab_production.ini и запускаем unifi_lab.py. В файл unifi_lab_mac_auth.list вносим мак-адреса устройств, которым разрешено подключение к сети (по одному в каждой строке). Файл перечитывается постоянно, поэтому изменения вступают в силу сразу после сохранения.

Для того, чтобы не запускать скрипт вручную, его можно конвертировать в exe при помощи py2exe. После этого создаем задание в планировщике на запуск программы при старте системы, настраиваем его на запуск вне зависимости от входа пользователя и снимаем галочку «Stop the task if it runs longer than 3 days».

Теперь перезагрузки будут не страшны — все запустится автоматически.

Tracert через Cisco ASA виндовым клиентом

В диагностике сетевых проблем сложно переоценить пользу такой простой утилиты как tracert (traceroute). Все мы знаем, что она в своей работе опирается на протокол icmp. И вполне логичным кажется обеспечение работы этого протокола на cisco asa путем «волшебного» inspect icmp. Однако, в случае с tracert это не помогает. Для ее нормального функционирования, необходимо разрешить на внешнем интерфейсе icmp типа time-exceeded от any к any:

access-list FROMOUTSIDE extended permit icmp any any time-exceeded
access-group FROMOUTSIDE in interface OUTSIDE

Только после этого вас ожидает полностью рабочий tracert.

Решение найдено здесь: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml