Home Travels Photoalbum Library
Главная стр.
Путешествия
Библиотека
Фотоальбом
@rich62.ru
Home » Библиотека » Network » Проблема доступа после миграции на CP SecurePlatform
Вернуться в «Библиотеку» Проблема доступа после миграции на CP SecurePlatform

Проблема

При переходе с CheckPoint Firewall NG AI R55 (Solaris Spark Edition) на CheckPoint NGX R65 (SecurePlatform), в одной Организации возникли проблемы - спорадические пропадания доступа к внешним ресурсам для отдельных адресов в корпоративной сети. Доступ пропадал на некоторое время (на срок до нескольких часов), после чего появлялся снова. Организация находилась на начальном этапе сегментации LAN и ее основные сетевые ресурсы работали пока в native VLAN1. Приблизительная схема сети представлена на рисунке. LAN Scheme [50K]

Ядром сети и шлюзом «по умолчанию» является коммутатор SW-LAN (Cisco C6509E). С него маршрут 0/0 указывает на CheckPoint (Eth0, 172.16.10.1/16). Кластер имеет еще 2 интерфейса, настроенных в режиме Trunk:

  • Eth1, VLAN3 - Internet (10.10.10.1/24)
  • Eth2, VLAN5 - DMZ (10.10.20.1/24)

Провайдер (ISP), кроме услуги Интернет («access-port», VLAN3), также, предоставляет доступ к L2 VPN-сети, объединяющей удаленные офисы компании. В этом канале проходят 2 линии связи - VLAN40 (VoIP) и VLAN60 (Data). Все линки от ISP «приходят» на L3 коммутатор SW-EXT, который, кроме фильтрации трафика, осуществляет еще и маршрутизацию. Транк с аналогичными номерами VLAN «уходит» в корпоративную сеть, позволяя прозрачно «пробросить» необходимый трафик на требуемые сетевые ресурсы. На интерфейсах коммутатора SW-EXT установлены bpdu-filters, которые запрещают обмен информацией об имеющихся VLAN между двумя VTP-доменами - Организации и ISP.

Для решения проблемы требовалось провести некоторые исследования. Ниже представлена информация по интерфейсам первого из нодов (active node) кластера (адреса заканчиваются на «11»).

[CPNode1]# expert
Enter expert password: 

You are in expert mode now.

[Expert@CPNode1]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:1D:09:01:B1:A0  
          inet addr:172.16.10.11  Bcast:172.16.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6979883 errors:0 dropped:0 overruns:0 frame:0
          TX packets:703445 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          ...
eth1      Link encap:Ethernet  HWaddr 00:1D:09:01:B1:A2  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6463413 errors:0 dropped:0 overruns:0 frame:0
          TX packets:601154 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          ...
eth1.3    Link encap:Ethernet  HWaddr 00:1D:09:01:B1:A2  
          inet addr:10.10.10.11  Bcast:10.10.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:601504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:601106 errors:0 dropped:0 overruns:0 carrier:0
          ...
eth2      Link encap:Ethernet  HWaddr 00:15:17:3D:07:34  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1516981 errors:0 dropped:0 overruns:0 frame:0
          TX packets:644763 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          ...
eth2.5    Link encap:Ethernet  HWaddr 00:15:17:3D:07:34  
          inet addr:10.10.20.11  Bcast:10.10.20.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1473363 errors:0 dropped:0 overruns:0 frame:0
          TX packets:644664 errors:0 dropped:0 overruns:0 carrier:0
eth3      ...
eth4      ...
eth5      ...
lo        ...

При данной конфигурации, наличии корректно настроенных таблиц маршрутизации и правил доступа (ACL), ip-пакеты с адреса 172.16.80.90 за CheckPoint не проходили. Начальная проверка «tcpdump»'ом показала, что на интерфейс Eth0 запросы приходят:

[Expert@CPNode1]# tcpdump | grep 172.16.80.90
tcpdump: listening on eth0
16:01:07.451880 172.16.80.90 > CPNode1: icmp: echo request

43742 packets received by filter
40172 packets dropped by kernel

При просмотре записей таблицы ARP выяснилось, что одни и те же IP-адреса «числятся» за разными интерфейсами - Eth0 и Eth1:

[Expert@CPNode1]# arp -a
? (172.16.80.90) at 00:13:D4:41:19:33 [ether] on eth0
? (172.16.80.90) at 00:13:D4:41:19:33 [ether] on eth1
? (172.16.72.118) at 00:04:76:25:C2:42 [ether] on eth0
? (172.16.72.118) at 00:04:76:25:C2:42 [ether] on eth1
? (172.16.71.83) at 00:18:F3:20:BB:CB [ether] on eth0
? (172.16.60.11) at 00:18:F3:0E:0B:01 [ether] on eth0

Решение

Стало совершенно очевидно, что ip-пакеты «проползают» на интерфейс Eth1 по Native VLAN1 и CheckPoint встает в «ступор». Путем решения проблемы стало разрешение прохождения только нужного VLAN (3) на транковом порту подключения CheckPoint к коммутатору SW-EXT:

SW-EXT#sh run int gi0/1
Building configuration...
...
interface GigabitEthernet0/1
 description Trunk to CPNode1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 3
 switchport mode trunk
end

Доступ к ресурсам и записи в ARP-таблице пришли в норму, работа восстановлена:

[Expert@CPNode1]# arp -a
? (172.16.80.90) at 00:13:D4:41:19:33 [ether] on eth0
? (172.16.80.136) at 00:17:31:4D:2E:42 [ether] on eth0
? (172.16.72.118) at 00:04:76:25:C2:42 [ether] on eth0
? (172.16.20.78) at 00:13:D4:41:19:3F [ether] on eth0

О замеченных неточностях прошу сообщить мне.

©rich62.ru,  2001-2011