2019-03-17 Networking-Blog

IPSEC between cisco and juniper behind nat with dynamic IP and cisco DVTI aka Cisco Dynamic Virtual Interface / IPSEC между cisco и juniper за натом на динамическом IP с использованием DVTI на cisco

Лазал я тут по ебею, и неожиданно попался моему взору juniper J 4350, за 5 тыщь вместе с доставкой - погуглил/почитал - по сути своей это софтроутер, по железу ни что иное как обычный четвертый пень в немного необычном конструктиве, унутри сплошной тантал - ломаца можно сказать нечему, за пару баксов с того же ебея можно туда вотнуть проц на 3.8GHz и памяти до 4 гигов, правда заюзать можно только 3.5 ибо i686, ну да не суть и того хватает с головой, вобщем во всех отношениях пиздатый аппарат😊 voip только можно сказать отсутствует, но с этим у жуниреров всегда было никак, есть какието платы пашущие тока с аваевским CM который мне нах не нужен, но с этим я решил смирица приставив сбоку циску с голосовыми портами, ктому же она у меня итак есть, ну и взял я его вобщем.

До него у меня дома роутером была cisco 2851, впринципе никаких проблем с ней небыло - всем хороша, кроме ната - больное место всех бранчевых кошек, торренты нисчадно его насиловали плодя тысячи сессий как я гайки(таймауты) там ни закручивал - всеравно периодически это ушатывало ее сраный процессор от калькулятора ситизен в полку😊 Это тоже от части способствовало покупке жунипера, у него заявлено 225килопакетов/с и 250к сессий на коробку с 2 гигами оперативы и какаято умопомрачительная по цискиным меркам цифра в 10000 новых сессий в секунду😊 у кошки просто 10000 сессий на нате уже проблема, если в секунду это уже пиздец ей в ту же секунду😊 Ну нада думать, калькулятор VS четвертый пень, хоть и селерон там на 2.53GHz но всеравно небо и земля😊 На практике вобщем то так и получилось - он этих торентов ваще никак не ощющает - что есть что нет - разница в загрузке плавает в районе 5 процентов. Кучу времени потратил на поиски софта - роутер приехал с убитой флешкой, не мог даже загрузица, заменить не проблема - там обычная CF на гиг-два пойдет а вот софт найти оказалось не так просто - довольно таки древний аппарат который вытеснили SRX'ы у которых ноги вобщем то и растут из J серии, точнее так то он по сути не сильно древний - поддержку дропнули тока в 2018 году, и софт есть на торрентах, но это архивы для установки уже поверх существующей системы, а вот чтоп с нуля на флэшку можно было закатать пришлось поискать, но в итоге все получилось, все работает, после недельного траха с тоннелем на работу😊 Об этом и хочу рассказать😊

Вобщем нужен мне тоннель на работу, поверх которого у меня BGP почти прямо в кору в бэкбон. Дома у меня динамический серый IP. Все было легко и просто когда была кошка, так как с другой стороны тоже была кошка - все работало сполпинка поверх dmvpn что не удивительно ибо кошка с кошкой и кошковский dmvpn для такого и предназначен😊 Но тут вместо кошки жунипер - и резко возникает вопрос - КАК БЛЯТЬ ТЕПЕРЬ ЗДЕЛАТЬ этот сраный тоннель😊 Я не спец по всяким бранчевым решениям, у меня большие сети, большие маршрутизаторы, и физические каналы, а всякие vpn это все не мое, но тем не менее я сетевик - почитал порыл - задолбался - милионы блять howto и примеров как зделать практически любые тоннели между кошкой и джунипером да и не тока, но без динамических IP и ната - ну да блять, там и делать то нехер - прописал с двух сторон хоть гре хоть ipip да что угодно - и постят эти howto кругом, кому они нах нужны тока, а вот с динамикой из за ната уже все не так просто😊 В итоге я понял что блять единственный интероперабельный вариант в такой ситуации это IPSEC в туннельном режиме. Никогда до этого не ковырял IPSEC, попробовал вывернуца приставив сбоку кошку за джунипером - но DMVPN споткнулся на двойном нате, пришлось таки в срочном порядке осваивать IPSEC😊

На джунипере как ни странно все оказалось достаточно просто, а вот со стороны кошки постоянно получались какието косяки😊 Собственно сам IPSEC поднять получилось без проблем, проблемы возникали с тоннелем😊 У кошки вариантов этого ипсека тьма на все случаи жизни, если с другой стороны кошковское же решение😊 а вот если нет то начинаюца нестыковки😊

Сначала затык вышел с IPSEC внутри VRF😊 У меня там по сути был так называемый Front Door VPN - тоесть один конец тоннеля торчит в VRF c интернетом, другой в VRF с бэкбоном, так вот IPSEC в VRF не заработал, в global работал, в VRF нет - видать баг иоса какой то потому что дома так работал как и написано у кошки, а где нада нет😊

Так как там где нада это была не основная задача а иос подбираеца под основную таки - пришлось все это дело оттуда вообще вынести на какуюнить другую подходящую хрень😊 Подходящая хрень в виде древней ободранной и страшной как сама моя жизнь циски 3725 нашлась под чьим то столом, в состоянии "пинали лет 5 ногами" пока она там валялась, но тем не менее она включилась, матерясь на хренова крутящиеся вентиляторы, нада отдать ей должное😊 вентиляторы смазал😊 через пару дней смазка видать попала куда нада и мат убрался😊 В добавок таким образом надобность в одном vrf отпала и интернет я засунул в global дабы не усложнять себе жизнь😊

В итоге первое что реально заработало на ней собсно IPSEC через cryptomap на интерфейсе, с двумя ip на концах и поверх этого GRE тоннель - работает, но не красиво ибо умом то понимаеш что GRE тут лишний оверхед, а мне и сам IPSEC тоже лишний оверхед ибо шифровать мне там нечего - нужен только транспорт - нада убрать значит😊 Начал искать как - нарыл кошкин DVTI aka Dynamic Virtula Interface - вроде бы что нужно - жунипер судя по всему имеет то же самое и может гонять routing protocol прямо поверх тунельного интерфейса.

Но и тут вышел косяк - если в proxy identify вписать какой то конкретный ip то все работает, но со стороны жунипера шифруеца не весь траффик попадающий в интерфейс а только тот что попадает в proxy identify - тоесть route based VPN нихрена не получается. Если в proxy identify поставить 0.0.0.0/0 как и должно быть то интерфейс поднимался, но без роутинга - тоесть кошка без понятия какие адреса на встречном конце - ситуация сама по себе прикольная - интерфейс есть, а маршрута через него нет😊 И ниче с этим сделать нельзя - интерфейс динамический - берет настройки с virtual-template, ip с лупбэка через unnumbered - тоесть никак в конфигурации маршрут через него указать нельзя, как и адреса на другом конце😊 Можно настроить xauth и раздавать адреа из пула, но у меня там BGP и нужен статический IP, а создавать пул из 1 адреса тоже как то не красиво😊 Хрен его знает каким образом это работает между кошками но судя по howto и примерам в интернете как то работает. Я нашол только одно упоминание что такая проблема между кошками имеет место быть, и там же нашол решение - запустить до кучи какойнить мульткастовый routing протокол на интерфейсе, конкретно там был rip, но не нравица мне он и я попробовал ospf - и прокатило😊 По ospf кошка быстро снюхалась с жунипером и выяснила какой адрес на другом конце тоннеля, после чего уже стало возможным поднять BGP😊 но это просто на словах, а по факту есть куча ньюансов😊

Первый это собсно вообще наличие ospf на данном участке - учитывая что тоннель домой, роутер домашний и посему как правило на нем есть дефолт, и на бэкбоне есть дефолт😊 и вдобавок да малоли что я там наконфигурю из сетей, и учитывая что ospf фильтрации можно сказать не поддается - нада как то это изолировать от бэкбона, в котором тоже собсно ospf, а бэкбон изолировать от этого участка, ибо если я проанонсирую случайно дефлот в бэкбон из дома это будет ни что иное как пиздец😊 Благо решение нашлось и быстро.

cisco может имеить кучу ospf процессов, причем не связанных друг с другом, посему делаем так - для туннельного интерфейса отдельный ospf процесс, с distance 210, и все - его задача только выяснить что на другом конце тоннеля, ну и до кучи проанонсировать свою сторону но жуниперу это не нужно - там можно статически написать как локальный так и удаленный ip на туннельном интерфейсе, но малоли - может кому еще понадобица.

Тем не менее нам нада как то обмениваца маршрутами с маршрутизаторами входящими в бэкбон. Так как по ospf нельзя ибо как написано выше опастно делать мы это будем по протоколу BGP ибо фильтруеца он как угодно, а на кошке будем делать двухстороннюю редистрибьюцию bgw<->ospf 1.

Juniper как циско иметь кучу независимых ospf процессов не может, зато может по другому - там есть виртуальные роутеры - чтото типа кошкиных VRF тока круче😊 И ospf можно засунуть в такой виртуальный роутер дабы он не анонсировал что ни попадя, и че бы он там ни принял эти анонсы в этом виртуальном роутере так и остануца и не попадут в глобальную таблицу маршрутизации.

Вроде бы на этом все мои страдания по скрещиванию законьчилис, теперь собственно

Конфигурация Cisco side:

version 12.4
service nagle
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
service sequence-numbers
no service dhcp
!
hostname frontdoor-vpn
!
boot-start-marker
boot-end-marker
!
logging userinfo
logging buffered 8192 debugging
logging rate-limit 100 except warnings
no logging monitor
enable secret 5 хервам
enable password 7 херасдваопять
!
no aaa new-model
clock timezone MSK 3
no ip source-route
ip arp proxy disable
no ip gratuitous-arps
ip icmp rate-limit unreachable 1000
ip icmp rate-limit unreachable DF 100
ip cef
!
!
!
!
ip vrf backbone
 rd 42916:1
!
no ip bootp server
ip domain timeout 1
ip name-server 91.193.236.3
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
login on-failure log
!
!
!
!
!
!
!
!         
!
!
!
!
!
!
!
!
!
ip tcp ecn
ip tcp selective-ack
ip tcp synwait-time 10
ip tcp path-mtu-discovery
! 
crypto keyring DVTI-KEYRING 
  local-address FastEthernet0/0
  pre-shared-key address 0.0.0.0 0.0.0.0 key херасдвавамтрианесеркерткей
crypto logging session
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
!
crypto isakmp policy 20
 hash md5
 authentication pre-share
!
crypto isakmp policy 30
 authentication pre-share
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 20 periodic
crypto isakmp profile DVTI-ISAKMP-PROF
   keyring DVTI-KEYRING
   match identity address 0.0.0.0 
   virtual-template 1
!
crypto ipsec security-association replay disable
!
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac 
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac 
crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac 
crypto ipsec transform-set ESP-NULL-MD5 esp-null esp-md5-hmac 
crypto ipsec transform-set ESP-NULL-SHA esp-null esp-sha-hmac 
crypto ipsec transform-set ESP-DES esp-des 
crypto ipsec fragmentation after-encryption
!
crypto ipsec profile IPSEC-PROF
 set transform-set ESP-DES-MD5 ESP-DES-SHA ESP-AES-SHA ESP-NULL-SHA ESP-NULL-MD5 ESP-DES 
 set isakmp-profile DVTI-ISAKMP-PROF
!
!
buffers tune automatic
!
!
!
interface Loopback0
 ip vrf forwarding backbone
 ip address 100.64.6.1 255.255.255.224
!
interface FastEthernet0/0
 ip address 91.193.236.27 255.255.255.248
 duplex auto
 speed auto
 no mop enabled
 hold-queue 512 in
!
interface FastEthernet0/1
 ip vrf forwarding backbone
 ip address 91.195.204.250 255.255.255.128
 ip verify unicast source reachable-via rx
 ip ospf 1 area 0.0.0.0
 duplex auto
 speed auto
 no mop enabled
 hold-queue 512 in
!
interface Virtual-Template1 type tunnel
 ip vrf forwarding backbone
 ip unnumbered Loopback0
 ip mtu 1492
 ip tcp adjust-mss 1328
 ip ospf network point-to-point
 ip ospf 2 area 0.0.0.0
 tunnel source FastEthernet0/0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF
 hold-queue 256 out
!
router ospf 2 vrf backbone
 router-id 100.64.6.1
 log-adjacency-changes
 passive-interface default
 no passive-interface Virtual-Template1
 distance 210
!
router ospf 1 vrf backbone
 router-id 91.195.204.250
 log-adjacency-changes
 redistribute connected subnets
 redistribute bgp 42916 subnets
 passive-interface default
 no passive-interface FastEthernet0/1
!
router bgp 42916
 bgp router-id 91.193.236.27
 bgp log-neighbor-changes
 neighbor 91.193.236.25 remote-as 42916
 neighbor 91.193.236.25 description uplink_to_bgw0
 neighbor 91.193.236.30 remote-as 42916
 neighbor 91.193.236.30 description uplink_to_bgw1
 maximum-paths ibgp 2
 !        
 address-family ipv4
  redistribute connected
  neighbor 91.193.236.25 activate
  neighbor 91.193.236.25 maximum-prefix 32 50 restart 1
  neighbor 91.193.236.30 activate
  neighbor 91.193.236.30 maximum-prefix 32 50 restart 1
  maximum-paths ibgp 2
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf backbone
  redistribute connected
  redistribute ospf 1 vrf backbone match internal external 1 external 2 nssa-external 1 nssa-external 2
  neighbor 100.64.6.2 remote-as 42916
  neighbor 100.64.6.2 transport connection-mode passive
  neighbor 100.64.6.2 update-source Loopback0
  neighbor 100.64.6.2 activate
  neighbor 100.64.6.2 next-hop-self
  neighbor 100.64.6.2 prefix-list no-default-route in
  neighbor 100.64.6.2 prefix-list no-default-route out
  neighbor 100.64.6.2 route-map vpn_bgp_out out
  neighbor 100.64.6.2 maximum-prefix 32 16 restart 10
  no synchronization
  bgp redistribute-internal
 exit-address-family
!
no ip forward-protocol nd
no ip forward-protocol udp nameserver
no ip forward-protocol udp domain
no ip forward-protocol udp time
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs
!
!
no ip http server
no ip http secure-server
!
ip access-list standard REMOTE-CONSOLE
 permit 10.32.75.177
 permit 91.193.236.32 0.0.0.31
!
!
ip prefix-list no-default-route seq 5 permit 0.0.0.0/0 ge 1
logging filter flash:logfilter.tcl  
!
route-map vpn_bgp_out permit 10
 set origin igp
!
!
!
control-plane
!
!
!         
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
 access-class REMOTE-CONSOLE in vrf-also
 exec-timeout 35791 0
 password 7 даскокажтутапаролейтоблять:)
 login
 transport input all
!
process cpu statistics limit entry-percentage 30 size 600
ntp clock-period 17180646
ntp server 91.193.236.10
ntp server 91.193.237.1
!
end

Впринципе тут все понятно - vrf backbone это собственно vrf воткнутый в бэкбон через FastEthernet0/1, на нем поднят ospf процесс номер 1 по которому и происходит обмен маршрутами с маршрутизаторами входящими в бэкбон.

Интернет в глобале по BGP с двух бордеров, через FastEthernet0/0, Он собсно и на бэкбоне есть но сделано так потому что в случае какой либо аварии пока жив хоть один бордер и комутаторы на аплинках интернет будет работать и тоннель соотвественно тоже, и я смогу попасть в сеть на работе. В этом и весь смысл Front Door VPN.

дальше чуть подробней по части самого ipsec:

crypto keyring DVTI-KEYRING 
  local-address FastEthernet0/0
  pre-shared-key address 0.0.0.0 0.0.0.0 key херасдвавамтрианесеркерткей

Авторизация и обмен ключами - слушать IKE на интерфейсе FastEthernet0/0 который смотрит на бордеры, ну и авторизация по pre shared key - "херасдвавамтрианесеркерткей" по сути чтото вроде пароля - должен быть одинаковым с ообоих сторон, вместо 0.0.0.0 0.0.0.0 можно задать адрес/подсеть для которых этот pre shared key будет применяца, ну а с нулями будет один на всех.

crypto isakmp policy 10
 encr aes
 authentication pre-share
!
crypto isakmp policy 20
 hash md5
 authentication pre-share
!
crypto isakmp policy 30
 authentication pre-share

Политики шифрования и хеширования для phase 1 ipsec, применяюца последовательно пока чтото не найдеца чтото общее с удаленной стороной. Я в итоге шифрование отключил вообще, отключил бы и хеширование но нельзя, по стандарту если отключено и то и то то включается и то и то что то там по дефолту😊 но это все лучше чем и то и то учитывая что на этой 3724 криптоакселератора нет и даже без шифрования с md5 хешированием она выдает всего мегабит 20 при этом гордо стоя колом/раком - проц в полку и на консоль отвечает с задержкой секунд в 10😊 но нада отдать должное - ни bgp ни ospf при этом не валяца как я ее не мучал😊 Впринципе дело даже не в мегабитах а в задержках - моя работа сводица практически к ssh терминалам 99% - для этого и 1 мегабита достаточно, а вот задержки чем меньше тем лучше, так вот с шифрованием задержки были порядка 6 ms, с отключенным 1.5-2 ms. С aes было еще хуже. Ну и вдобавок у меня по этому тоннелю еще и голос ходит на рабочий телефон дома, впринципе ему эти 6 мс тоже долампочи но почему бы не сократить если можно😊

crypto isakmp profile DVTI-ISAKMP-PROF
   keyring DVTI-KEYRING
   match identity address 0.0.0.0 
   virtual-template 1

Собсно IKE профиль, применяеца потом в итоге в IPSEC профиле, который в свою очередь применяется уже к интерфейсу, самое значимое тут для нас это virtual-template 1 - номер virtual-template интерфейса с которого клонируются настройки реального интерфейса когда соединение установица.

crypto ipsec security-association replay disable

отключаем защиту от replay атак - лишняя нагрузка на процессор - пусть атакуют я всеравно там ниче не шифрую😊

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac 
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac 
crypto ipsec transform-set ESP-AES-SHA esp-aes esp-sha-hmac 
crypto ipsec transform-set ESP-NULL-MD5 esp-null esp-md5-hmac 
crypto ipsec transform-set ESP-NULL-SHA esp-null esp-sha-hmac 
crypto ipsec transform-set ESP-DES esp-des 

Так называемый у кошки transform-set, по сути набор алгоритмов которыми можно шифровать/хешировать траффик, по сути это уже phase 2 ипсека, тут просто то что сложилось в ходе экспериментов😊

crypto ipsec profile IPSEC-PROF
 set transform-set ESP-DES-MD5 ESP-DES-SHA ESP-AES-SHA ESP-NULL-SHA ESP-NULL-MD5 ESP-DES 
 set isakmp-profile DVTI-ISAKMP-PROF

ipsec профиль - обьединяет pase 1 и pase 2 в одну кучу, и применяется потом уже на virtual-template интерфейсе.

interface Loopback0
 ip vrf forwarding backbone
 ip address 100.64.6.1 255.255.255.224

Петлевой интерфейс - используется в качестве unnumbered на virtula-template и соотвественно на туннельном тоже, поэтому он в vrf backbone, адреса на другом конце туннеля следует брать из этого диапазона.

interface Virtual-Template1 type tunnel
 ip vrf forwarding backbone
 ip unnumbered Loopback0
 ip mtu 1492
 ip tcp adjust-mss 1328
 ip ospf network point-to-point
 ip ospf 2 area 0.0.0.0
 tunnel source FastEthernet0/0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF
 hold-queue 256 out

Virtual-template для туннельных интерфейсов, тут собственно применяется ipsec профиль который IPSEC-PROF, так же прописан ospf процесс 2 с area 0 для выяснения адресов на удаленной стороне тоннеля, сам интерфейс в vrf backbone тоже, ну ip unnumbered с петлевого интерфейса, и самое интересное - ip mtu 1492 и ip tcp adjust-mss 1328, их задача убрать фрагментацию, ipsec вносит оверхед, mtu 1492 потому что дома у меня pppoe до провайдера, ip tcp adjust-mss 1328 потому что оно точно пролезит в mtu 1492 и еще потому что я гдето нарыл умную статью по поводу ipsec performance в которой было опытным путем доказано и теоретически обосновано почему 1328 наиболее оптимально в случае ipsec не смотря на то что оно чуть меньше чем можно было бы сделать, если без подробностей то там еще играет роль выравниевание пакета по границам, и 1328 в этом плане золотая середина😊

router ospf 2 vrf backbone
 router-id 100.64.6.1
 log-adjacency-changes
 passive-interface default
 no passive-interface Virtual-Template1
 distance 210
!
router ospf 1 vrf backbone
 router-id 91.195.204.250
 log-adjacency-changes
 redistribute connected subnets
 redistribute bgp 42916 subnets
 passive-interface default
 no passive-interface FastEthernet0/1

OSPF процессы - первый работает на туннельных интерфейсах, второй в бэкбоне, redistribute bgp 42916 subnets - какрас редистрибьюция из bgp в ospf, 42916 процесс BGP по номеру автономной системы как это принято. distance 210 в ospf 2 еще одна предосторожность - даже если мы чето всосем и это пересечется с тем что уже есть маршрут не будет замещен потому что distance больше чем у остальных протоколов.

router bgp 42916
 bgp router-id 91.193.236.27
 bgp log-neighbor-changes
 neighbor 91.193.236.25 remote-as 42916
 neighbor 91.193.236.25 description uplink_to_bgw0
 neighbor 91.193.236.30 remote-as 42916
 neighbor 91.193.236.30 description uplink_to_bgw1
 maximum-paths ibgp 2
 !        
 address-family ipv4
  redistribute connected
  neighbor 91.193.236.25 activate
  neighbor 91.193.236.25 maximum-prefix 32 50 restart 1
  neighbor 91.193.236.30 activate
  neighbor 91.193.236.30 maximum-prefix 32 50 restart 1
  maximum-paths ibgp 2
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf backbone
  redistribute connected
  redistribute ospf 1 vrf backbone match internal external 1 external 2 nssa-external 1 nssa-external 2
  neighbor 100.64.6.2 remote-as 42916
  neighbor 100.64.6.2 transport connection-mode passive
  neighbor 100.64.6.2 update-source Loopback0
  neighbor 100.64.6.2 activate
  neighbor 100.64.6.2 next-hop-self
  neighbor 100.64.6.2 prefix-list no-default-route in
  neighbor 100.64.6.2 prefix-list no-default-route out
  neighbor 100.64.6.2 route-map vpn_bgp_out out
  neighbor 100.64.6.2 maximum-prefix 32 16 restart 10
  no synchronization
  bgp redistribute-internal
 exit-address-family

BGP часть, 2 сессии к бордерам в глобале - 91.193.236.25 и 91.193.236.30, от них принимаем дефолт, анонсировать ниче не нада так как directly connected и маршруты до нас на них итак есть.

А под address-family ipv4 vrf backbone собственно конфигурация сессии с juniper.

ip prefix-list no-default-route seq 5 permit 0.0.0.0/0 ge 1
!
route-map vpn_bgp_out permit 10
 set origin igp
!

Ну собсно route-map меняющий origin и префикс-лист описанные выше.

С кошкой вроде все, дальше juniper кусками, ибо у меня там накручено помимо этого еще дохрена чего и все целиком портянка та еще и слишком будет лишним перегружено.

Конфигурация juniper side:

root@J> show configuration interfaces
st0 {                                   
    no-traps;                           
    unit 0 {                            
        description IPSEC-VPN_to_AS42916;
        family inet {                   
            mtu 1492;                   
            address 100.64.6.2/32 {     
                destination 100.64.6.1; 
            }                           
        }                               
    }                                   
}                                       

Это собственно туннельный интерфейс, mtu такой же как с другой стороны, хоть juniper и не рекомендует его менять, а вместо этого крутить mss тем не менее причин для этого не вижу, вдобавок если мту не совпадет то ospf со стороны кошки не поднимеца пока ей не сказать игнорировать сей факт, а у джунипера там иту по дефолту аж 9k, так что учитывая отсутствие внятного обьяснения причин рекомендации не менять со стороны juniper у меня будет так. Так же нет внятного обьяснения ПОЧЕМУ БЛЯТЬ на туннельном интерфейсе отсутствует reverce path filtering как класс? на других есть тут нет - забыли чтоли😊 junos bla bla lba... extensive continuous testing bla bla lba... ага... пиздатая лапша доширак😊

 root@J> show configuration routing-options 
static {
    route 91.193.236.27/32 {
        next-hop pp0.0;
        no-readvertise;
    }
    route 172.16.0.0/12 {
        discard;
        no-readvertise;
    }
    route 10.0.0.0/8 {
        discard;
        no-readvertise;
    }
    route 100.64.0.0/10 {
        discard;
        no-readvertise;
    }
    route 169.254.0.0/16 {
        discard;
        no-readvertise;
    }
    route 192.168.0.0/16 {
        discard;
        no-readvertise;
    }
    route 0.0.0.0/0 next-hop pp0.0;
}
router-id 100.64.5.5;
forwarding-table {
    no-indirect-next-hop;
}
instance-import import-from-inst-AS42916-VPN;
root@J> show configuration protocols bgp      
traceoptions {
    file bgp.log size 4m files 4;
}
hold-time 180;
no-advertise-peer-as;
mtu-discovery;
log-updown;
local-as 42916;
group iBGP {
    type internal;
    description "AS internal peers";
    neighbor 100.64.6.1 {
        description "IPSEC VPN to AS42916 on work";
        import [ default-route-reject nexthop-peer ];
        export [ default-route-reject reject-uplink nexthop-self redistribute-directly-connected redistribute-ospf ];
        peer-as 42916;
    }
}

BGP в сторону кошки - тут впринципе все стандартно, ну разьве что не обращайте внимания на redistribute-ospf - как я говорил выше у меня там много чего еще, в том числе и оспф никак не связанный с этой кошкой и тоннелем. hold-time я подкрутил до кошкиного значения. Тем не менее так скажем - идеология настройки BGP у juniper немного другая нежели у cisco, и на мой взгляд лучше, тем что на корню отсекает распиздяйство😊 тут нельзя просто взять и влепить пир - нада создать группу, указать тип группы - iBGP/eBGP, и уже только в группе можно сконфигурировать пир, на cisco тоже так можно, и я к этому и пришол со временем, еще за долго до знакомства с junos вообще, ибо на тех же бордерах где куча пиров конфигурация превращаеца в длиннющую портянку, что:

Вот только на циске можно != обязан, поэтому нужна некоторая дисциплина чтоп не допускать такого, а тут хош не хош а придется.

root@J> show configuration policy-options    
policy-statement default-route-reject {
    from {
        route-filter 0.0.0.0/0 exact;
    }
    then reject;
}
policy-statement import-from-inst-AS42916-VPN {
    term instance {
        from instance AS42916-VPN;
    }
    term local {
        from protocol local;
        then accept;
    }
    term direct {
        from protocol direct;
        then accept;
    }
    then reject;
}
policy-statement nexthop-peer {
    then {
        next-hop peer-address;
    }
}
policy-statement nexthop-self {
    then {
        next-hop self;
    }
}
policy-statement redistribute-directly-connected {
    term direct {
        from protocol direct;
        then accept;
    }
    term local {
        from protocol local;
        then accept;
    }
}
policy-statement redistribute-ospf {
    term ospf {
        from protocol ospf;
        then accept;
    }
}
policy-statement reject-uplink {
    term to_pp0.0 {
        to interface pp0.0;
        then reject;                    
    }
    term from_pp0.0 {
        from interface pp0.0;
        then reject;
    }
}

Собственно политики фильтрации анонсов, а так же импорта маршрутов с виртуального роутера. Разжовывать тут вобщем то нефиг - итак все понятно, ну и все есть в документации если че.

root@J> show configuration security ike      
respond-bad-spi 5;
proposal AS42916_IKE-PROPOSAL {
    authentication-method pre-shared-keys;
    dh-group group1;
    authentication-algorithm md5;
    encryption-algorithm des-cbc;
    lifetime-seconds 86400;
}
policy AS42916_IKE-POLICY {
    mode main;
    proposals AS42916_IKE-PROPOSAL;
    pre-shared-key ascii-text "херасдвавамтрианесеркерткей"; ## SECRET-DATA
}
gateway AS42916-BACKBONE_IKE_GW {
    ike-policy AS42916_IKE-POLICY;
    address 91.193.236.27;
    dead-peer-detection {
        interval 10;
        threshold 2;
    }
    nat-keepalive 20;
    local-identity inet 100.64.6.2;
    external-interface pp0;
}

root@J> show configuration security ipsec  
vpn-monitor-options {
    interval 60;
    threshold 3;
}
proposal AS42916_IPSEC-PROPOSAL {
    protocol esp;
    authentication-algorithm hmac-md5-96;
}
policy AS42916_IPSEC-POLICY {
    perfect-forward-secrecy {
        keys group1;
    }
    proposals AS42916_IPSEC-PROPOSAL;
}
vpn AS42916-BACKBONE {
    bind-interface st0.0;
    df-bit copy;
    vpn-monitor {
        optimized;
        destination-ip 100.64.5.1;
    }
    ike {
        gateway AS42916-BACKBONE_IKE_GW;
        no-anti-replay;
        ipsec-policy AS42916_IPSEC-POLICY;
    }
    establish-tunnels immediately;
}

Весь IPSEC - phase 1 и 2 в одном флаконе😊 Тоже особо разжовывать нечего - 91.193.236.27 адрес кошки с которой пытаемся поднять тоннель, st0.0 - тунельный интерфейс описанный выше, establish-tunnels immediately - поднять тоннель сразу не дожидаясь траффика через него - ибо мы и не дождемся туда никакова траффика без маршрутизации по bgp, н разьве что сам bgp туда начнет ломица дабы поднять сессию, но и то не факт если интерфейс в дауне. и как я уже говорил я убрал шифрование, делается это убиранием encryption-algorithm из proposal AS42916_IPSEC-PROPOSAL... неожиданно😊 ну и плюс настроены dead peer detection и vpn монитор. Так же здесь ньюанс касательно фрагментации опять таки - в vpn AS42916-BACKBONE df-bit copy; - копирует dont fragment бит из нешифрованного пакета в уже шифрованный и инкапсулированный, и если тот потом не лезит в mtu шлет icmp источнику пакета с намеком что нужно пакет помельче😊 А по дефолту он сам их начинает нарезать и фрагментировать, а df срезает, тоесть при таком раскладе pmtu discovery работать не будет, да и производительность страдает, поэтому делаем так.

root@J> show configuration security flow     
route-change-timeout 60;
tcp-mss {
    all-tcp {
        mss 1452;
    }
    ipsec-vpn {
        mss 1328;
    }
}

Аналог кошкиного ip tcp adjust-mss, тоесть на стадии tcp хэндшейка правит MSS в пакете, тут у жунипера тоже другая идеология, и на мой взгляд малость ебнутая на всю сука башку по сравнению с кошкой - нельзя выставить эту хрень для интерфейса - можно только для всех - то что all-tcp, и для ipsec - то что в ipsec-vpn, а то что у меня там еще 16 гигабитных интерфейсов с нормальным мту в 1500 или с junbo frame в 9000 с 6 подсетями их неебет ниразу - сказали всем 1452 - значит 1452 блять. Я блять канешна понимаю что можно отмазаца сказав это блять ZBF а не роутер, на что скажу я вам ПНХ!!! - по джуниперовской диаграмке прохождения пакета через сей девайс в flow режиме маршрутизация происходит ДО создания сессии, так что mss с интерфейса выхватить можно, да и если его передернуть в packet mode то это сука роутер, чистокровный блять не подкопаешся, более того тока таким он и был до версии junos 9.четотам, пока туда не начали вкорячивать функционал screenos, а с MPLS он и по сей день может работать только в packet-mode, видать при портировании чето пошло не так, возможно отсутствие MPLS в screenos как класса😊 ЧЕМ ДУМАЛИ хуйзнает вобщем.

ладна возвращаясь к значениям - all-tcp mss 1452 потому что как уже говорил - к провайдеру у меня pppoe, у которого mtu 1492, mss соответственно за вычетом ip заголовков получается 1452. ну а про mss для ipsec я уже писал когда комментировал конфигурацию кошки.

root@J> show configuration routing-instances 
AS42916-VPN {
    instance-type no-forwarding;
    interface st0.0;
    routing-options {
        router-id 100.64.6.2;
    }
    protocols {
        ospf {
            export redistribute-directly-connected;
            area 0.0.0.0 {
                interface st0.0;
            }
        }
    }
}

А это тот самый виртуальный роутер с ospf в сторону кошки. особо разжовывать вобщем то нечего, делаете виртуальный роутер, instance-type no-forwarding потому что роутить мы там ниче не будим, нам нада просто изолировать ospf процесс, засовываете в него туннельный интерфейс который st0.0, ospf как обычно, и экспортируете потом оттуда directly connected маршруты в основную таблицу, иначе не будет работать маршрутизауия через st0.0 в основном таблице так как его там не будет, и вобщем то все. Надо заметить значительно элегантней, проще и понятнее чем чрезжопный route-leaking между vrf'ами ака кусками MPLS'а притянутого зауши в кошках.

Зоны и межзоновые политики расписывать не буду - итак примеров милион, вдобавок пока вы это не сделаете никакой ipsec вас волновать не будет все равно😊 единственное что для ipsec в зоне с внешним интерфейсом необходимо разрешить сервис ike а в зоне с st0.0 протоколы ospf и bgp, иначе не взлетят ipsec/ospf/bgp, примерно так:

root@J> show configuration security zones       
security-zone untrust {
    screen untrust-screen;
    host-inbound-traffic {
        system-services {
            ike;
        }
    }
    interfaces {
        pp0.0;
        ge-0/0/3.0;
    }
}
security-zone AS42916-VPN {
    screen vpn-screen;
    host-inbound-traffic {
        system-services {
            ping;
            traceroute;
        }
        protocols {
            ospf;
            bgp;
        }
    }
    interfaces {
        st0.0;
    }
}

Отладка всего этого на кошке:

позырить ассоциации:

frontdoor-vpn#show crypto isakmp sa detail 
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
25    91.193.236.27   217.170.124.98           ACTIVE des  md5  psk  1  14:40:59 DN  
       Connection-id:Engine-id =  25:1(software)
24    91.193.236.27   217.170.124.98           ACTIVE des  md5  psk  1  13:51:59 DN  
       Connection-id:Engine-id =  24:1(software)
frontdoor-vpn#

это phase 1

frontdoor-vpn#show crypto session detail 
Crypto session current status

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

Interface: Virtual-Access3
Session status: UP-ACTIVE     
Peer: 217.170.124.98 port 4500 fvrf: (none) ivrf: (none)
      Phase1_id: 100.64.6.2
      Desc: (none)
  IKE SA: local 91.193.236.27/4500 remote 217.170.124.98/4500 Active 
          Capabilities:DN connid:25 lifetime:14:40:18
  IKE SA: local 91.193.236.27/4500 remote 217.170.124.98/4500 Active 
          Capabilities:DN connid:24 lifetime:13:51: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 7205856 drop 888 life (KB/Sec) 4505494/2776
        Outbound: #pkts enc'ed 5749529 drop 0 life (KB/Sec) 4511285/2776

frontdoor-vpn#

это phase 2

обе можно без detail.

Отладка на juniper:

show log kmd, если мало то выткаем trace options в security ike/ipsec, по другому никак.

root@J> show security ike security-associations detail 
IKE peer 91.193.236.27, Index 8220970,
  Role: Responder, State: UP
  Initiator cookie: b0a109742b07d571, Responder cookie: 082e78874ec9c94a
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 10.245.255.2:4500, Remote: 91.193.236.27:4500
  Lifetime: Expires in 49543 seconds
  Peer ike-id: 91.193.236.27
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : md5 
   Encryption            : des-cbc
   Pseudo random function: hmac-md5
  Traffic statistics:
   Input  bytes  :                 1368
   Output bytes  :                  552
   Input  packets:                   15
   Output packets:                    3
  Flags: Caller notification sent 
  IPSec security associations: 0 created, 12 deleted
  Phase 2 negotiations in progress: 0

IKE peer 91.193.236.27, Index 8220971,
  Role: Initiator, State: UP
  Initiator cookie: f187e6faaf5a084d, Responder cookie: d1a9b4a8057f4c27
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 10.245.255.2:4500, Remote: 91.193.236.27:4500
  Lifetime: Expires in 52483 seconds
  Peer ike-id: 91.193.236.27
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : md5 
   Encryption            : des-cbc
   Pseudo random function: hmac-md5
  Traffic statistics:
   Input  bytes  :                 3940
   Output bytes  :                 4784
   Input  packets:                   15
   Output packets:                   27
  Flags: Caller notification sent 
  IPSec security associations: 12 created, 0 deleted
  Phase 2 negotiations in progress: 0


root@J> 

посмотреть phase 1.

root@J> show security ipsec security-associations detail  
  Virtual-system: root
  Local Gateway: 10.245.255.2, Remote Gateway: 91.193.236.27
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
    DF-bit: copy
    Direction: inbound, SPI: 9bef1366, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 2405 seconds
    Lifesize Remaining:  4598873 kilobytes
    Soft lifetime: Expires in 1790 seconds
    Mode: tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-md5-96, Encryption: None
    Anti-replay service: disabled
    Direction: outbound, SPI: 1cbddc78, AUX-SPI: 0
                              , VPN Monitoring: UP
    Hard lifetime: Expires in 2405 seconds
    Lifesize Remaining:  4598873 kilobytes
    Soft lifetime: Expires in 1790 seconds
    Mode: tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-md5-96, Encryption: None
    Anti-replay service: disabled

root@J> 

посмотреть phase 2.