вторник, 22 февраля 2011 г.

IPSec и фрагментация пакетов

При использовании IPSec необходима инкапсуляция пакетов, что ведет к увеличению их размеров.

 
Если размеры получившегося пакета превышают MTU, то маршрутизатор шифрует пакет, а затем его фрагментирует.  Таким образом, принимающий маршрутизатор, должен сначала собрать все фрагменты воедино, а затем расшифровать получившийся пакет. Процесс сборки обычно происходит на process level, что серьезно влияет на производительность. По этой причине фрагментации пакетов желательно избегать, где это возможно. Существуют несколько способов решения данной проблемы. Некторые требуют настройки маршрутизаторов, другие предполагают изменение настроек на конечных клиентах и серверах.

1.       Изменение MTU на конечных станциях. Возможно установить значение MTU на клиентах и серверах меньше, чем стандартное 1500 байт. Рекомендуемое в таком случае значение MTU равно 1300 байт.  К сожалению, масштабы сети часто не позволяют легко и непринужденно поменять настройки на всех машинах. В таком случае, можно попробовать ограничиться серверами, т.к. по большей части именно они являются генераторами больших пакетов.
2.       Path MTU Discovery
Эта фича была придумана, чтобы избежать необходимости фрагментации в принципе.  Она позволяет узлам определить самое маленькое MTU на пути следования пакетов и использовать его в дальнейшем. В этом случае конечная станция шлет пакеты с выставленным битом DF (запрет на фрагментирование).  Если на пути пакета попадается маршрутизатор, чей MTU меньше размеров пакетов, то этот маршрутизатор отсылает ICMP сообщение  type 3, code 4 Fragmentation needed and DF set. В неиспользуемой части ICMP пакета содержится значение MTU, используемое маршрутизатором.  Передающий хост может использовать это значение для корректировки собственного MTU. К сожалению, очень часто маршрутизаторы настроены подавлять отсылку ICMP сообщений type 3, например, с помощью популярной команды настройки интерфейса no ip unreachables. Лучше этого не делать, а если очень хочется, то использовать ip local route-map (разрешив отправку ICMP type 3, code 4). Если, конечно, IOS поддерживает cef switching для route-map (и если cef для local route-map возможен в принципе?).
3.       VPN Interface MTU
Можно подкорректировать, выставить значение 1300 на туннельном интерфейсе
ip mtu 1300
4.       Look Ahead Fragmentation
Фундаментально решает проблемы фрагментации, изменив порядок фрагментации и шифрования. Получив пакет, маршрутизатор просчитывает размер пакета после инкапсуляции, и в случае превышения MTU сначала  фрагментирует пакет, а затем шифрует получившиеся пакетики. Фича доступна с версии IOS 122(13)T и включена по умолчанию.
5.       TCP Maximum Fragment Size
Единственный способ повлиять на размер входящего пакета в условиях, когда не удается договориться с админами на втором конце. TSP MSS определяет максимальный размер TCP сегмента, что, в конечном итоге, определяет размер пакета. Влияет, естественно, только на TCP трафик.  UDP пакеты в основном не превышают  300  байт  за исключением видео.
По историческим причинам (до изобретения PMTUD) MTU для хостов за пределами локальной сети был равен 1300 байт. Отсюда взялось ограничение TCP MSS в 1260 байт (1300 – 20-byte-IP-header – 20-byte-TCP-header).  После внедрения PMTUD это ограничение было снято.
Каждый  из хостов при установлении TCP соединения анонсирует свой MSS в SYN пакетах(необязательно совпадающие).
Команда конфигурирования интерфейса
ip tcp adjust-mss 1260
принудительно переводит поведение TCP сессий в до-PMTUD эпоху. При использовании этой команды на интерфейсе  маршрутизатор переписывает значения MSS в TCP SYN пакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.

понедельник, 21 февраля 2011 г.

IOS Order of Operations

Валяющийся на Cisco.com документ под названием "NAT order of operation" безобразно устарел. На просторах Инета удалось откопать документ следующего содержания:


Applying ACL on VTI

По результатам испытаний на тестовом стенде (Cisco 1841 IOS  12.4(25c)) место применения ACL на VTI интерфейсах определено как:

Входящий:

Исходящий:

VTI VPN

Ссылки:

Configuring a Virtual Tunnel Interface with IP Security

Virtual tunnel interfaces (VTI) – относительно новая функциональность IOS, которая позволяет создать виртуальный интерфейс для IPSec канала. Это дает возможность управлять IPSec потоками более гибко, удобно и, в конечном счете, просто.
Преимущества IPSec VTI по сравнению с классическим  IPSec:
1.    Сильно упрощается настройка и контроль шифрованного трафика (можно применить QoS, ZBF и т.п.). Обработка нешифрованного трафика идет на виртуальном интерфейсе, шифрованного – на физическом.
2.     IPSec VTI поддерживает  multicast, а, следовательно, и протоколы динамической маршрутизации - OSPF, EIGRP и т.п.
Недостатки IPSec VTI по сравнению с классическим IPSec:
1.    Функционирует только в туннельном режиме
2.    Данная функциональность пока реализована только на Cisco
3.    Поддерживает ТОЛЬКО IP (unicast & multicast)
4.    Не реализована функция Stateful Failover
Преимущества IPSec VTI по сравнению с DMVPN:
1.    Меньше заголовок пакета, чем в DMVPN (GRE+key+IPSec > IPSec VTI)
2.    Проще настраивать
3.    Не требует NHRP
Недостатки IPSec VTI по сравнению с DMVPN:
1.    Не поддерживается прямое Spoke-to-Spoke взаимодействие
 Есть две разновидности VTI:
  • Статический VTI очень похож на реализацию point-to-point GRE туннеля
  • Динамический VTI очень похож на реализацию dial-in, реализованного через virtual templates и расширяющегося до индивидуальных virtual-access

Схема
Конфигурация интерфейсов:
Устройство
Интерфейс
IP адрес
Head
GE0/1
100.100.100.1/30
Head
Tunnel 3
10.10.10.10/31
Branch
Fe0/1
200.200.200.1/30
Branch
Tunnel 0
10.10.10.11/31

Используем конфигурацию sVTI-sVTI.


// На HQ:
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key XXXXXXX address 200.200.200.1
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set myset esp-3des esp-sha-hmac
!
crypto ipsec profile VTI
 set transform-set myset
!
interface Tunnel3
 ip unnumbered GigabitEthernet0/1
 tunnel source 100.100.100.1
 tunnel destination 200.200.200.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!
ip route  BRANCH_LAN Tunnel3 - непосредственно завернем интересующий трафик в туннель

На Branch зеркальная конфигурация.



Проверочные команды:

HQ#show interfaces Tunnel 3
Tunnel3 is up, line protocol is up
  Hardware is Tunnel
  Interface is unnumbered. Using address of GigabitEthernet0/1
  MTU 17883 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 100.100.100.1, destination 200.200.200.1
  Tunnel protocol/transport IPSEC/IP
  Tunnel TTL 255
  Tunnel transport MTU 1443 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "VTI")
  Last input 3d16h, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     504424 packets input, 51915418 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     508805 packets output, 83660684 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out


HQ#show crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel3
Uptime: 23:23:40
Session status: UP-ACTIVE
Peer: 200.200.200.1 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 200.200.200.1
      Desc: (none)
  IKE SA: local 100.100.100.1/500 remote 200.200.200.1/500 Active
          Capabilities:D connid:1021 lifetime:00:36:19
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 159012 drop 0 life (KB/Sec) 4537137/2078
        Outbound: #pkts enc'ed 160783 drop 0 life (KB/Sec) 4537107/2078


   

Подавление нежелательных сообщений Host Unreachable


 Вообще для этого есть команда интерфейса no ip unreachable. Но применять ее следует крайне осторожно, т.к. она не позволяет отрабатывать процессу PMTUD.
 В связи с этим возникает естественное желание использовать ACL. Но ACL'ы к трафику, генерируемому самим маршрутизатором, не применяются, поэтому контролировать ICMP пакеты, сгенерированные маршрутизатором мы с их помощью не можем.

 Для этого существует команда ip local policy route-map.

TCP и BGP


среда, 9 февраля 2011 г.

Полезные ссылки - Troubleshooting

Полезные ссылки - HA

Self-signed certifiactes

Программа для генерации самоподписанных сертификатов живет тут: C:\Program Files\Microsoft Office\Office <version number>\selfcert.exe

пятница, 4 февраля 2011 г.

ZBF и Traceroute


В версии IOS 12.4 при использовании Zone-Based Firewall  для корректной работы утилиты traceroute требуется разрешить прохождение ICMP пакетов port-unreachable (type 3, code 3) и ttl-exceeded(type 11, code 1) без инспекции.

Для этого создаем ACL:

ip access-list extended TRACE
 permit icmp any any port-unreachable
 permit icmp any any ttl-exceeded

ip access-list extended ICMP
 permit icmp any any port-unreachable
 permit icmp any any ttl-exceeded
 permit icmp any any packet-too-big


Класс:

class-map type inspect match-all TRACE
 match access-group name TRACE

class-map type inspect match-all ICMP
 match access-group name ICMP



И объявляем политику так, чтобы эти пакеты не инспектировались, а пропускались как есть:

1.   Внутрь

policy-map type inspect ISP-SELF
 class type inspect  TRACE
  pass
 class type inspect ISP-SELF
  inspect
 class class-default
  drop log


2.   Наружу

policy-map type inspect SELF-ISP
 class type inspect ICMP
  pass
 class type inspect SELF-ISP
  inspect
 class class-default
  drop