VRF и IPSec через GRE
-
Здравствуйте
[, @Imm] Даже при разделении VRF классическая IOS/IOS-XE не полностью изолирует сеансы IKE/IPsec по vrf, когда IP удаленного узла одинаковы. VRF используется для маршрутизации (FVRF/IVRF), а не для создания независимых контекстов IKE... В результате несколько статических туннелей ipsec к одному и тому же IP узла (ваш случай) не поддерживаются для активной/активной работы и могут перезаписывать друг друга... https://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-2mt/sec-vrf-aware-ipsec.html С моей точки зрения, если вы хотите активный/активный режим через 2 интернет-провайдера, вам нужен DMVPN. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı. -
Здравствуйте,
[M02@rt37]
Спасибо за ответ. Но проблема в том, что в головном офисе у меня есть один маршрутизатор с двумя интернет-провайдерами, а у меня есть около 10 филиалов, где у меня только один интернет-провайдер. Мне нужно каким-то образом сообщить маршрутизатору в головном офисе, как выполнять маршрутизацию WAN.
Я уже пробовал PBR\Local-in PBR, но это не сработало. -
PBR? Проверьте, какой интернет-провайдер используется по предпочтению маршрута; я имею в виду использование статических маршрутов с отслеживанием (основной туннель с более низким AD, резервный с более высоким AD)... С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı. -
Здравствуйте,
[M02@rt37]
Спасибо за ответ. Но как мне настроить маршрутизацию? У меня около 10 офисов с одним интернет-провайдером (например, 111.11.11.1).
Как я могу сообщить маршрутизатору головного офиса, что он может одновременно подключиться к этому IP-адресу через интернет-провайдера 1 и интернет-провайдера 2, чтобы иметь активные/активные туннели? -
Здравствуйте, Есть несколько вариантов, как это реализовать, но сначала я хотел бы получить ответы на несколько дополнительных вопросов, чтобы предложенное решение позволяло работать другим возможным сервисам без дополнительных сложностей. 1. Подтвердите, что ваша конфигурация представляет собой головной офис с двумя интернет-провайдерами и несколькими удаленными филиалами, каждый из которых имеет одного интернет-провайдера. 2. Интернет-провайдеры в головном офисе предоставляют подключение через Интернет или через частную сеть MPLS? А как насчет интернет-провайдеров в филиалах? 3. Если в HQ используется Интернет, предоставляете ли вы также доступ в Интернет для пользователей HQ через эти линии? Если да, выполняете ли вы также NAT на маршрутизаторе? 4. С этой настройкой VPN вы хотите только прямые IPsec-туннели между филиалами и головным офисом или также прямые IPsec-туннели между филиалами? 5. Можете ли вы использовать IKEv2 вместо IKEv1? В настоящее время я не вижу причин, по которым вы бы выбрали IKEv1, однако я спрашиваю, чтобы понять, какие у вас есть варианты. 6. За маршрутизатором филиалов и маршрутизатором головного офиса (на стороне LAN) у вас есть домен динамической маршрутизации? Если да, то какой протокол используется? 7. Имеется ли динамическая/BGP-маршрутизация на стороне WAN, в головном офисе и филиалах, или это статическая маршрутизация? 8. Вы хотите, чтобы два туннеля между определенным филиалом и штаб-квартирой работали в режиме «активный/активный» или «активный/резервный»? Спасибо, Кристиан.
-
Здравствуйте,
@Cristian Matei
, спасибо за ответ. Я могу перейти на IKEv2, если это поможет, IKEv1 был добавлен до меня. Этот маршрутизатор предназначен только для VPN-соединения Site-2-Site, без NAT или доступа в Интернет через этот маршрутизатор. Да, есть BGP, и туннели должны работать в режиме Active\Active. -
Здравствуйте, Хотя существует достаточно вариантов для решения вашей задачи, я предложу самый простой из них, предполагая, что вам нужны только туннели «хаб-колесо», без туннелей «колесо-колесо», поскольку вы не ответили на этот вопрос. Использование VRF добавляет ненужную сложность как для маршрутизации, так и для IPsec, использование GRE с ключом туннеля добавляет ненужную нагрузку, использование DMVPN не решает вашу проблему, и DMVPN не требуется в соответствии с вашим запросом. Проблема, которую вам нужно решить, независимо от использования IKEv1 или IKEv2, заключается в способности концентратора различать на уровне IKE (а именно идентичности IKE), что один и тот же IP-адрес удаленной стороны фактически требуется для двух разных туннелей. Предлагаемая конфигурация использует IKEv2, не потому, что вы не могли бы решить проблему с помощью IKEv1, а потому, что нет смысла поддерживать реализацию IKEv1, если только вам не нужно обеспечить обратную совместимость, что не является вашим случаем. Я прикрепляю конфигурацию концентратора и отдельного филиала, очевидно, измените IP-адреса, интерфейсы, IKEV2 ID, PSK. После этого включите какой-нибудь предпочтительный протокол динамической маршрутизации, однако, если вы используете BGP через WAN / подслой, не рекомендуется использовать BGP через туннели IPsec (выберите EIGRP или OSPF), также я не рекомендую использовать маршрутизацию IKEv2, поскольку вам нужен функциональный и быстрый сценарий балансировки нагрузки при отказе. Не устанавливайте IP MTU на туннеле вручную, он будет самонастраиваться на основе алгоритмов, используемых в IPsec Transform-Set. Как только туннель заработает, вы можете проверить это с помощью команды
show interface Tunnel100
и посмотреть строку
Tunnel transport MTU
. После того, как вы увидели значение MTU, которое будет одинаковым для всех ваших сайтов и туннелей (при условии, что MTU подложки одинаковое, т. е. 1500, если это широкополосный Интернет), просто вычтите 40 и используйте это значение в качестве значения TCP MSS на туннеле (установите TCP MSS на обеих сторонах туннеля). КОНФИГУРАЦИЯ HUB: crypto ikev2 proposal IKEV2_TEST_PROPOSAL encryption aes-gcm-256 prf sha512 group 24
!
crypto ikev2 policy IKEV2_TEST_POLICY proposal IKEV2_TEST_PROPOSAL
!
crypto ikev2 keyring IKEV2_TEST_KEYRING peer ALL address 0.0.0.0 0.0.0.0 pre-shared-key local cisco pre-shared-key remote cisco !
crypto ikev2 profile IKEV2_TUNNEL100_PROFILE match identity remote fqdn domain primary.com identity local fqdn hub.primary.com authentication remote pre-share authentication local pre-share keyring local IKEV2_TEST_KEYRING
!
crypto ikev2 profile IKEV2_TUNNEL110_PROFILE match identity remote fqdn domain secondary.com identity local fqdn hub.secondary.com authentication remote pre-share authentication local pre-share keyring local IKEV2_TEST_KEYRING
!
crypto ikev2 nat keepalive 10
crypto ikev2 diagnose error 500
crypto ikev2 dpd 10 3 on-demand
crypto ikev2 limit max-in-negotation-sa 500
crypto ikev2 limit queue sa-init 500
crypto ikev2 cookie-challenge 500
!
crypto ipsec transform-set IPSEC_TEST_TSET esp-gcm 256 mode tunnel
!
crypto ipsec profile IPSEC_TUNNEL100_PROFILE set transform-set IPSEC_TEST_TSET set ikev2-profile IKEV2_TUNNEL100_PROFILE
!
crypto ipsec profile IPSEC_TUNNEL110_PROFILE set transform-set IPSEC_TEST_TSET set ikev2-profile IKEV2_TUNNEL110_PROFILE
!
interface GigabitEthernet0/0 ip address 192.168.12.1 255.255.255.0 no shutdown
!
interface GigabitEthernet0/1 ip address 192.168.13.1 255.255.255.0 no shutdown
!
interface Tunnel100 ip address 100.100.100.1 255.255.255.0 tunnel source GigabitEthernet0/0 tunnel mode ipsec ipv4 tunnel destination 192.168.24.4 tunnel protection ipsec profile IPSEC_TUNNEL100_PROFILE
!
interface Tunnel110 ip address 100.100.110.1 255.255.255.0 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel destination 192.168.24.4 tunnel protection ipsec profile IPSEC_TUNNEL110_PROFILE КОНФИГУРАЦИЯ ВЕТВИ-1: crypto ikev2 proposal IKEV2_TEST_PROPOSAL encryption aes-gcm-256 prf sha512 group 24
!
crypto ikev2 policy IKEV2_TEST_POLICY proposal IKEV2_TEST_PROPOSAL
!
crypto ikev2 keyring IKEV2_TEST_KEYRING peer ALL address 0.0.0.0 0.0.0.0 pre-shared-key local cisco pre-shared-key remote cisco !
crypto ikev2 profile IKEV2_TUNNEL100_PROFILE match identity remote fqdn domain primary.com identity local fqdn branchone.primary.com authentication remote pre-share authentication local pre-share keyring local IKEV2_TEST_KEYRING
!
crypto ikev2 profile IKEV2_TUNNEL110_PROFILE match identity remote fqdn domain secondary.com identity local fqdn branchone.secondary.com authentication remote pre-share authentication local pre-share keyring local IKEV2_TEST_KEYRING
crypto ikev2 nat keepalive 10
crypto ikev2 diagnose error 500
crypto ikev2 dpd 10 3 on-demand
crypto ikev2 limit max-in-negotation-sa 500
crypto ikev2 limit queue sa-init 500
crypto ikev2 cookie-challenge 500
!
crypto ipsec transform-set IPSEC_TEST_TSET esp-gcm 256 mode tunnel
!
crypto ipsec profile IPSEC_TUNNEL100_PROFILE set transform-set IPSEC_TEST_TSET set ikev2-profile IKEV2_TUNNEL100_PROFILE
!
crypto ipsec profile IPSEC_TUNNEL110_PROFILE set transform-set IPSEC_TEST_TSET set ikev2-profile IKEV2_TUNNEL110_PROFILE
!
interface GigabitEthernet0/1 ip address 192.168.24.4 255.255.255.0 no shutdown
!
interface Tunnel100 ip address 100.100.100.4 255.255.255.0 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel destination 192.168.12.1 tunnel protection ipsec profile IPSEC_TUNNEL100_PROFILE
!
interface Tunnel110 ip address 100.100.110.4 255.255.255.0 tunnel source GigabitEthernet0/1 tunnel mode ipsec ipv4 tunnel destination 192.168.13.1 tunnel protection ipsec profile IPSEC_TUNNEL110_PROFILE Спасибо, Кристиан. -
@Cristian Matei
Спасибо за ответ, Но мне нужно как-то назначить 192.168.24.4 через обоих интернет-провайдеров, как будет выглядеть маршрутизация WAN на HUB? -
Здравствуйте, Да, вы можете сделать это с помощью конфигурации маршрутизации WAN/underlay, статического ECMP или BGP ECMP Multipath на стороне концентратора, чтобы обеспечить наличие обоих путей ISP на стороне концентратора, установленных в RIB для каждой удаленной подсети WAN. Если вы все равно используете BGP с ISP, используйте BGP ECMP Multipath, а не дополнительно настраивайте статические маршруты через оба ISP для каждого удаленного филиала WAN IP. IPsec-трафик из удаленного филиала для Tunnel1 будет поступать на ваш ISP1 на концентраторе, а IPsec-трафик из удаленного филиала для Tunnel 2 будет поступать на ваш ISP2 на концентраторе из-за маршрутизации подстилающего уровня от филиала к разным IP-адресам концентратора, маршрутизируемым через разных ISP. IPsec-трафик из концентратора в удаленное отделение для Tunnel1 будет выходить на вашем ISP1 в концентраторе, а IPsec-трафик из концентратора в удаленное отделение для Tunnel 2 будет выходить на вашем ISP2 в концентраторе, благодаря ECMP-маршрутизации и распределению нагрузки CEF из концентратора в отделение с тем же IP-адресом, маршрутизируемым через разных интернет-провайдеров. Спасибо, Кристиан.
-
Надеюсь, вы уже попробовали, вы пробовали vrf aware в конфигурации туннеля: crypto isakmp profile ISAKML-PROFILE vrf isp2 BB
=====Preenayamo Vasudevam=====
***** Оцените все полезные ответы *****
Как обратиться за помощью к сообществу Cisco -
Здравствуйте,
@balaji.bandi
, спасибо за ответ.
Да, я пробовал, но это не помогло. -
Здравствуйте, Наличие каждого WAN-провайдера на стороне концентратора в отдельном VRF (GRT и пользовательский VRF) устраняет проблему балансировки нагрузки IPsec-пакетов от концентратора к одному и тому же удаленному филиалу для двух туннелей, однако такое разделение VRF не является обязательным, см. мой предыдущий пост. Помимо использования или неиспользования VRF для подстилающего уровня, мое предлагаемое решение заключалось в использовании разных идентификаторов IKEv2 для каждого туннеля от концентратора к филиалу вместе с SVTI, чтобы оба туннеля могли успешно запуститься. Ваша предлагаемая конфигурация, похоже, не использует отдельные идентификаторы IKEv2, по этой причине вы используете GRE над IPsec с уникальным ключом туннеля GRE /per tune, чтобы оба туннеля могли запуститься, что добавляет ненужную нагрузку всего в 8 байт, поскольку вы используете транспортный режим (4 байта для заголовка GRE + 4 байта для значения поля ключа GRE), а если бы вы использовали туннельный режим, накладные расходы составили бы 28 байт (20 байт для нового заголовка IP + 4 байта для заголовка GRE + 4 байта для значения поля ключа GRE). В конце концов, вы выбираете то решение, которое вам больше подходит, я просто хотел убедиться, что вы знаете о всех вариантах, а также о последствиях (плюсах и минусах) выбранного решения. Что бы вы ни выбрали, я рекомендую выполнить следующие дополнительные настройки для всех ваших профилей IPsec, чтобы избежать ситуаций, когда пакеты теряются, и вам приходится тратить много времени на их поиск, о чем я сначала не упомянул: crypto ipsec profile VRF-ISP2-IKEv2-IPSec-Profile set security-association dfbit clear Спасибо, Кристиан.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти