Одновременное использование двух провайдеров
Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке ISP1 в главе про Резервирование. С тем лишь отличием, что оба маршрута по умолчанию имеют одинаковую административную дистанцию
Правила NATа не претерпевают изменений. Те же route-map в динамических и статических трансляциях. Но как определить, какой пакет отправлять через какого провайдера? Можно принудительно раскидывать входящие с g0/0 пакеты ещё одним route-map.
Правда в этом случае пакет, попавший в ACLISP1, пойдет на первого провайдера всегда, независимо от того, жив провайдер или нет. Чтобы этого избежать есть возможность в этом route-map применить проверку по 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 добавить такие списки доступа
Таким образом получим:
Это решение, пусть не красивое, но все же полностью решает задачу, не затрагивая сервер (его часто и нельзя затрагивать: например, если это не приложение, а VPN сервер). Потеря здесь явная одна: сервер никогда не знает, с кем реально он общается, а значит нельзя собрать адекватную статистику и т.д.
Если же использовать возможности серверов, то на ум приходит несколько решений, не требующих внешнего NATа.
Первое – сделать на самом деле 2 сервера-партнера, с разными адресами и связанными друг с другом для репликации ещё одним линком. Каждый сервер транслируется в свой адрес, но в случае падения одного из каналов переключается на партнерский адрес.
Не самое простое и дешевое решение.
Второе: задать на одном и том же сервере 2 адреса. Если они из одной подсети, то проблемы с маршрутизацией не будет. Каждый из локальных адресов сервера строго транслируется только одного из провайдеров, т.к. физически сервер один и никакой выгоды по нагрузке мы все равно не получим. Для явного указания выходного интерфейса применяем route-map STRELKA. Тут может возникнуть проблема с самим сервером: часто бывает так, что при ответе сервер использует только первичный адрес интерфейса, независимо от того, на какой адрес пришел запрос.
Характерный пример: VPN сервер. Если в качестве VPN ¬сервера выступает маршрутизатор cisco, то он всегда отвечает с первичного адреса интерфейса.
_________________
Пришло письмо мне от читателя из Литвы, где он сослался на интересную статью. Пожалуй, она дополнит именно серверную часть задачи:
Тут на сайте НИЛа. Автор — Иван Пепельняк, один из ранних CCIE, очень глубокий специалист (его блог «IOS hints and tricks»
Вкратце: на виндузовом сервер можно создать интерфейсы loopback (2 штуки) и сорсировать пакеты от сервисов именно от этих адресов. И транслировать их в разные внешние. Дополнительно надо на маршрутизаторах прописать обратные маршруты в сети этих loopback. Тогда проблема адреса источника будет решена
__________________
Если адреса из разных подсетей, то шлюз по умолчанию все равно один. А значит маршрутизироваться все будет только через один интерфейс и задача полностью решена не будет.
PS Сегодня наконец собрал стенд и ещё раз все проверил, благодаря Вашему интересу! Так что пользуйтесь, дорогие мои :)
Сергей Фёдоров, CCIE Security #22974
Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке 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 {трафик на ISP1}
!
ip access-list extended ACLISP2
permit {трафик на ISP2}
!
route-map STRELKA 10
match ip address ACLISP1
set ip next-hop {GateISP1}
route-map STRELKA 20
match ip address ACLISP2
set ip next-hop {GateISP2}
!
int g0/0
ip policy route-map STRELKA
Правда в этом случае пакет, попавший в ACLISP1, пойдет на первого провайдера всегда, независимо от того, жив провайдер или нет. Чтобы этого избежать есть возможность в этом route-map применить проверку по track
set ip next-hop verify-reachability {GateISPX} {sequence#} track {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 {start-ip-1} {end-ip-1}
ip nat pool OUTPOOL2 {start-ip-2} {end-ip-2}
!
! задаем критерий для 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
