IPsec през частна WAN: граници на политиките в SRX, които да проверите

Частна WAN може да пренася външните пакети на IPsec тунел, така че адресите на партньора не е задължително да са публични интернет адреси. Променя се пътят, по който минават тези външни пакети, и разрешенията на интерфейса, който ги приема. В SRX външният път за управление, обвързването на тунелния интерфейс и политиката за препращан трафик са три отделни обекта. Отстраняването на проблем в единия, докато другите два са грешни, е обичайната причина тунелът да остава долу.

Запишете първо външния път на IKE

Запишете четири стойности, преди да пипате политиката: адреса на партньора, локалния интерфейс, който приема IKE, контекста на маршрутизация, който достига до партньора, и маршрута, който избира този интерфейс. Пакетите IKE са адресирани до самия SRX, затова им трябва разрешение host-inbound в приемащата зона, а не политика за препращан трафик. Частният адрес на WAN не премахва това изискване, защото пакетът все още завършва на устройството.

Проверете инсталираното състояние с show security ike sa и конфигурацията с show configuration security ike. Първата показва дали фаза 1 съществува; втората — какво според устройството трябва да прави.

Обвържете тунелния интерфейс с правилната политика

VPN, базирана на маршрутизация обвързва тунелен интерфейс с обект VPN и защитените префикси се маршрутизират към този интерфейс. Запишете кой интерфейс, кой маршрут и коя политика разрешава приложенията между съответните зони. Зона с име trust е контейнер за политики и името не доказва, че необходимите пакети за управление или данни са разрешени.

Четете действителните обвързвания, а не стара диаграма: show configuration security ipsec vpn за настройката за обвързване с интерфейс и show configuration security policies за правилата, които сочат към тунелната зона.

Ако защитеният маршрут сочи другаде, тунелът може да е вдигнат, а трафикът никога да не влиза в него. Това е проблем с маршрутизацията в костюм на IPsec.

Дръжте маршрута до партньора в underlay

Маршрутът до външния партньор трябва да се разрешава през underlay, а не рекурсивно през тунела, който той установява. Ако маршрутът до партньора сочи към тунелния интерфейс, пакетите IKE гонят собствения си тунел и фаза 1 никога не завършва. Обратният път за защитения трафик се нуждае от собствен правилен маршрут и политика и обикновено това е липсващата половина, когато една посока работи. Прочетете записа в таблицата за маршрутизация за адреса на партньора и потвърдете, че изходящият интерфейс е WAN интерфейсът.

Проверете го с show route 198.51.100.10, като поставите реалния адрес на партньора, и потвърдете, че следващият хоп не е тунелен интерфейс.

Проверете управлението и услугата по ред

Работете нагоре: състояние на фаза 1, състояние на фаза 2, после реален поток на приложение. show security ipsec sa изброява асоциациите за сигурност, а show security flow session destination-prefix 10.60.0.0/16 показва дали се създават препратени сесии за защитената мрежа.

Здрава връзка за управление и работещ път за данни са два различни резултата, и успешната фаза 2 не казва нищо за това дали политиката разрешава приложението. Тествайте един разрешен поток и един, който политиката трябва да отхвърли, за да се види разликата.

Запишете заедно маршрута до партньора, разрешението host-inbound, обвързването на тунела, вътрешния маршрут и политиката за приложението. Тези пет записа показват кой слой отговаря за бъдещ отказ, без да се разчита на етикет на порт.