Одновременное использование двух провайдеров на маршрутизаторах cisco (продолжение)
Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке ISP1 в главе про Резервирование. С тем лишь отличием, что оба маршрута по умолчанию имеют одинаковую административную дистанцию
ip route 0.0.0.0 0.0.0.0 Gate(ISP1) track 11 ip route 0.0.0.0 0.0.0.0 Gate(ISP2) track 22
Правила NATа не претерпевают изменений. Те же route-map в динамических и статических трансляциях. Но как определить, какой пакет отправлять через какого провайдера? Можно принудительно раскидывать входящие с g0/0 пакеты ещё одним route-map.
! Заготавливаем списки доступа с «интересным» трафиком. Все знают, что такое ! «интересный» трафик? :) ip access-list extended ACLISP1 permit ! ip access-list extended ACLISP2 permit ! route-map STRELKA 10 match ip address ACLISP1 set ip next-hop route-map STRELKA 20 match ip address ACLISP2 set ip next-hop ! int g0/0 ip policy route-map STRELKA
Правда в этом случае пакет, попавший в ACLISP1, пойдет на первого провайдера всегда, независимо от того, жив провайдер или нет. Чтобы этого избежать есть возможность в этом route-map применить проверку по track
set ip next-hop verify-reachability track
sequence# — это число от 1 до 65535. Если таких возможных next-hop будет много, то они будут упорядочены по этому числу.
Напомню, что в случае если пакет явно не попал в route-map, он будет использовать обычную таблицу маршрутизации.
Ну а теперь давайте попробуем разобраться с двумя очень сложными вопросами: каким образом будут ходить пакеты, если вы не используете явно разделение трафика при помощи route-map на внутреннем интерфейсе. И как сделать так, чтобы пакет, пришедший снаружи на адрес сервера Srv(ISP1) ушел обратно через тот же интерфейс, через который пришёл. Это действительно сложные вопросы. И красивого решения для них нет, поэтому я в своей практике стараюсь избегать таких топологий.
Однако, жизнь может заставить, поэтому разберемся.
Пусть снаружи приходит пакет на интерфейс f0/0 на адрес Srv(ISP1). Благодаря статической трансляции адрес назначения будет изменен на Srv(LAN) и пакет пойдет дальше на сервер. На маршрутизаторе в кеше NAT трансляций появится запись о соответствии Srv(LAN) и Srv(ISP1). Сервер ответит, ответ дойдет обратно до маршрутизатора и…возникнет вопрос: по какому маршруту отправлять пакет в Интернет? В кеше трансляций есть явная запись, какой адрес ставить вместо Srv(LAN) – Srv(ISP1). Но нет ни намека, через какой интерфейс при этом посылать пакет. Для исправления этой неоднозначности надо по какому то критерию разделять приходящий с разных интерфейсов трафик. Этого можно добиться, но способ, по моему мнению, не очень элегантный: надо использовать подмену реальных адресов клиентов на разные пулы внутренних адресов. Надо только подобрать размер этого пула соответственно нагрузке на сервер – по одному адресу на каждого обращающегося, т.к. для внешнего NATa (outside NAT) на маршрутизаторах нельзя сделать РАТ (Port Address Translation), только трансляция адрес в адрес. Тогда всегда точно известно, с какого интерфейса поступил запрос. В качестве критерия для трансляции адреса сервера можно в существующие route-map добавить такие списки доступа
ip access-list extended FORISPX permit ip host Srv(LAN) OUTPOOLX
! задаем пулы для каждого из интерфейсов ip nat pool OUTPOOL1 ip nat pool OUTPOOL2 ! ! задаем критерий для outside NAT ip access-list extended OUTNAT1 permit ip any host Srv(ISP1) ip access-list extended OUTNAT2 permit ip any host Srv(ISP2) ! ! транслируем адреса источника клиентов ip nat outside source list OUTNAT1 pool OUTPOOL1 ip nat outside source list OUTNAT2 pool OUTPOOL2 ! ! дополняем route-map route-map ISP1 permit 10 match interface f0/0 match ip address FORISP1 ! route-map ISP2 permit 10 match interface f0/1 match ip address FORISP2
Это решение, пусть не красивое, но все же полностью решает задачу, не затрагивая сервер (его часто и нельзя затрагивать: например, если это не приложение, а VPN сервер). Потеря здесь явная одна: сервер никогда не знает, с кем реально он общается, а значит нельзя собрать адекватную статистику и т.д.
Если же использовать возможности серверов, то на ум приходит несколько решений, не требующих внешнего NATа.
Первое – сделать на самом деле 2 сервера-партнера, с разными адресами и связанными друг с другом для репликации ещё одним линком. Каждый сервер транслируется в свой адрес, но в случае падения одного из каналов переключается на партнерский адрес.
Не самое простое и дешевое решение.
Второе: задать на одном и том же сервере 2 адреса. Если они из одной подсети, то проблемы с маршрутизацией не будет. Каждый из локальных адресов сервера строго транслируется только одного из провайдеров, т.к. физически сервер один и никакой выгоды по нагрузке мы все равно не получим. Для явного указания выходного интерфейса применяем route-map STRELKA. Тут может возникнуть проблема с самим сервером: часто бывает так, что при ответе сервер использует только первичный адрес интерфейса, независимо от того, на какой адрес пришел запрос.
Характерный пример: VPN сервер. Если в качестве VPN ¬сервера выступает маршрутизатор cisco, то он всегда отвечает с первичного адреса интерфейса.
UPD on 23:45 14.01.2010
Пришло письмо мне от читателя из Литвы, где он сослался на интересную статью. Пожалуй, она дополнит именно серверную часть задачи:
Тут на сайте НИЛа. Автор — Иван Пепельняк, один из ранних CCIE, очень глубокий специалист (его блог «IOS hints and tricks»
Вкратце: на виндузовом сервер можно создать интерфейсы loopback (2 штуки) и сорсировать пакеты от сервисов именно от этих адресов. И транслировать их в разные внешние. Дополнительно надо на маршрутизаторах прописать обратные маршруты в сети этих loopback. Тогда проблема адреса источника будет решена
__________________
Если адреса из разных подсетей, то шлюз по умолчанию все равно один. А значит маршрутизироваться все будет только через один интерфейс и задача полностью решена не будет.
PS Сегодня наконец собрал стенд и ещё раз все проверил, благодаря Вашему интересу! Так что пользуйтесь, дорогие мои 🙂
Сергей Фёдоров, CCIE Security #22974
UPD: Cisco и 2 провайдера
Проблема стара как мир и сегодня мы ее решим 🙂
Дано: 2 провайдера (ISP1 и ISP2), внутренняя сеть и между ними маршрутизатор.
Задача: настроить один основной (ISP1) и один резервный канал (ISP2), при падении первого переключится на второй, при поднятии первого переключится обратно.
UPD: Обновил, дописал ip sla, пока без объяснений.
Будем исходить из того что коммутаторы у нас тоже фирмы Cisco 🙂 и для начала настроим 3 Vlan’а:
Vlan 10 — внутренняя сеть
Vlan 12 — ISP1
Vlan 14 — ISP2
C2970#vlan data
C2970(vlan)#vlan 10 name OurNet
VLAN 10 added:
Name: OurNet
C2970(vlan)#vlan 12 name ISP1
VLAN 12 added:
Name: ISP1
C2970(vlan)#vlan 14 name ISP2
VLAN 13 added:
Name: ISP2
C2970-Servers(vlan)#exit
APPLY completed.
Exiting.
C2970#
Порт номер 1 принадлежит Vlan’у 12 -ISP1, порт 2 принадлежит Vlan’у 14 (ISP2), третий порт транковый — для рутера, остальные порты принадлежат Vlan’у 10 — наша внутренняя сеть.
interface FastEthernet0/1
description -=I=- ISP1 -=I=-
switchport access vlan 12
switchport mode access
no cdp enable
interface FastEthernet0/2
description -=I=- ISP2 -=I=-
switchport access vlan 14
switchport mode access
no cdp enable
interface FastEthernet0/3
description -=I=- RTR -=I=-
switchport mode trunk
no mdix auto
interface FastEthernet0/4
switchport access vlan 10
switchport mode access
no cdp enable
.
interface FastEthernet0/24
switchport access vlan 10
switchport mode access
no cdp enable
С коммутацией разобрались переходим к нашему рутеру, у меня за пример взят Cisco 2811 с иосом c2800nm-adventerprisek9_ivs-mz.124-24.T1.bin (хотя будет работать и на другом рутере с другим ИОС’ом)
interface FastEthernet0/0
no ip address
duplex auto
speed auto
no cdp enable
!
interface FastEthernet0/0.12
description -=I=- Internet over ISP1 -=I=-
encapsulation dot1Q 12
ip address 164.122.12.9 255.255.255.248
ip access-group ACL_INET_OUT_ISP1 out
ip nat outside
ip virtual-reassembly
no cdp enable
!
interface FastEthernet0/0.14
description -=I=- Internet over ISP2 -=I=-
encapsulation dot1Q 14
ip address 122.164.8.17 255.255.255.248
ip access-group ACL_INET_OUT_ISP2 out
ip nat outside
ip virtual-reassembly
no cdp enable
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.10
description to -=I=- LAN -=I=-
encapsulation dot1Q 10
ip address 10.10.10.200 255.255.255.0
ip nat inside
ip virtual-reassembly
no cdp enable
Настроим пулы для NAT’а:
ip nat pool ISP1-PUBLIC-IP 164.122.12.9 164.122.12.9 netmask 255.255.255.248
ip nat pool ISP2-PUBLIC-IP 122.164.8.17 122.164.8.17 netmask 255.255.255.248
Акцесс-листы (ACL):
ACL’и для интерфейсов, чтобы никто не прорвался 🙂
ip access-list extended ACL_INET_OUT_ISP1
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
permit ip host 164.122.12.9 any
deny ip any any log-input
ip access-list extended ACL_INET_OUT_ISP2
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
permit ip host 122.164.8.17 any
deny ip any any log-input
ACL’и для тех кто в сети:
ip access-list extended ACL_NAT-INET_OUT_ISP1
remark /—————————————
remark Black Hole RFC 1918
remark —————————————/
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
remark /—————————————
remark SMTP For Exchange
remark —————————————/
permit tcp host 10.10.10.254 any eq smtp
deny tcp any any eq smtp log-input
remark /—————————————
remark WSUS
remark —————————————/
permit ip host 10.10.10.251 any
remark /—————————————
remark Full Aceess for Odmins
remark —————————————/
permit ip host 10.10.10.10 any
remark /—————————————
remark Access for Exchange
remark —————————————/
permit ip host 10.10.10.254 any
remark /—————————————
remark Deny SMTP for TI (gate)
remark —————————————/
deny tcp host 10.10.10.249 eq smtp any log-input
remark /—————————————
remark Access to Internet for TI (gate)
remark —————————————/
permit ip host 10.10.10.249 any
remark /—————————————
remark Self
remark —————————————/
permit ip host 164.122.12.9 any
remark /—————————————
remark Deny All
remark —————————————/
deny ip any any log-input
Route-map:
route-map NAT-TO-ISP1 permit 10
description -= Routing/NAT to ISP1, outgoing traffic =-
match ip address ACL_NAT-INET_OUT_ISP1
match interface FastEthernet0/0.12
!
route-map NAT-TO-ISP2 permit 10
description -= Routing/NAT to ISP2, outgoing traffic =-
match ip address ACL_NAT-INET_OUT_ISP2
match interface FastEthernet0/0.14
И вот теперь самое интересное — трекинг:
track 100 list boolean and
object 101
object 102
object 103
object 104
delay down 2 up 3
!
track 101 interface FastEthernet0/0.12 line-protocol
delay down 2 up 5
!
track 102 interface FastEthernet0/1 line-protocol
delay down 2 up 5
!
track 103 ip route 164.122.12.9 255.255.255.248 reachability
delay down 2 up 5
!
track 104 ip sla 104
delay down 2 up 5
!
track 200 list boolean and
object 201
object 202
object 203
object 204
delay down 2 up 3
!
track 201 interface FastEthernet0/0.14 line-protocol
delay down 2 up 5
!
track 202 interface FastEthernet0/1 line-protocol
delay down 2 up 5
!
track 203 ip route 122.164.8.17 255.255.255.248 reachability
delay down 2 up 5
!
track 204 ip sla 204
delay down 2 up 5
ip route 0.0.0.0 0.0.0.0 164.122.12.9 10 tag 100 name -=[ISP1]=- track 100
ip route 0.0.0.0 0.0.0.0 122.164.8.17 20 tag 200 name -=[ISP2]=- track 200
а теперь собственно то, чем мы проверяем доступность наших шлюзов:
ip sla 104
icmp-echo 164.122.12.9 source-interface FastEthernet0/0.12
request-data-size 1
timeout 700
threshold 600
frequency 30
ip sla schedule 104 life forever start-time now
ip sla 204
icmp-echo 122.164.8.17 source-interface FastEthernet0/0.14
request-data-size 1
timeout 700
threshold 600
frequency 30
ip sla schedule 204 life forever start-time now