![[Home]](/static/root.gif)
Лазал я тут по ебею, и неожиданно попался моему взору 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 году, и софт есть на торрентах, но это архивы для установки уже поверх существующей системы, а вот чтоп с нуля на флэшку можно было закатать пришлось поискать, но в итоге все получилось - Juniper links все работает, после недельного траха с тоннелем на работу😊 Об этом и хочу рассказать😊
Вобщем нужен мне тоннель на работу, поверх которого у меня 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 можно засунуть в такой виртуальный роутер дабы он не анонсировал что ни попадя, и че бы он там ни принял эти анонсы в этом виртуальном роутере так и остануца и не попадут в глобальную таблицу маршрутизации.
Вроде бы на этом все мои страдания по скрещиванию законьчилис, теперь собственно
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 кусками, ибо у меня там накручено помимо этого еще дохрена чего и все целиком портянка та еще и слишком будет лишним перегружено.
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.
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.