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, прывязку тунеля, унутраны маршрут і палітыку праграмы. Гэтыя пяць запісаў паказваюць, які ўзровень будзе адказваць за будучую збой без агляду на этыкетку порта.