Чаму маршрут OpenVPN саступае палітыцы XFRM strongSwan

Канкрэтны маршрут OpenVPN не перакрывае палітыку XFRM: прачытайце маршрут і селектары палітыкі, затым звузьце, выключыце або перайдзіце на інтэрфейс XFRM.

Пакеты могуць ісці па маршруце OpenVPN і ўсё ж трапляць пад палітыку IPsec, і гэтая камбінацыя выглядае як памылка маршрутызацыі з любога боку, акрамя правільнага. Linux вырашае маршрут і потым звяртаецца да асобнай базы палітык бяспекі, таму больш канкрэтны маршрут да месца прызначэння не выцясняе адпаведную палітыку XFRM. Бачны сімптом — трафік, які пакідае хост і ніколі не даходзіць, хаця абодва тунэлі паведамляюць, што яны здаровыя. Існуюць тры варыянты рашэння, і які выбраць залежыць ад таго, які з двух шляхоў павінен несці гэты прэфікс.

Два рашэнні, а не адно

Выбар маршруту адказвае на вузкае пытанне: які наступны хоп і адрас крыніцы павінны несці гэты пакет. База палітык бяспекі адказвае на іншае: ці патрабуе гэты пакет абароны IPsec і пад якімі селектарамі. Абодва працуюць для аднаго пакета, і выкананне першага нічога не кажа пра другое. Вось чаму змена метрыкі або даданне статычнага маршруту могуць пакінуць сімптом нязменным.

Шырокі селектар IPsec — звычайная прычына. Палітыка, якая абараняе 172.16.0.0/12, таксама ахоплівае 172.20.8.0/24, куды адміністратар можа мець намер дабрацца праз тунэль OpenVPN. Намер існуе толькі ў табліцы маршрутызацыі, і база палітык пра яго ніколі не ведала.

Разглядайце гэта як канфлікт паміж двума сканфігураванымі шляхамі абароны, а не як спаборніцтва паміж дзвюма метрыкамі. Выпраўленне належыць таму кампаненту, які быў сканфігураваны з няправільным ахопам.

Прачытайце маршрут, які ядро фактычна выбірае

Пачніце з пошуку, які выконвае ядро, уключаючы адрас крыніцы і любое правіла палітыкі, якое можа накіраваць яго ў іншую табліцу. Маршрут у галоўнай табліцы можа ніколі не разглядацца, калі ранейшае правіла выбірае іншую табліцу, а супастаўленне самага доўгага прэфікса дзейнічае толькі ў межах табліцы, якую выбірае правіла.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Апошняя каманда — тая, што мае значэнне, бо яна друкуе выбраны маршрут разам з адрасам крыніцы, які выкарыстала б ядро. Параўнайце гэты вывад з селектарам, якому адпавядае палітыка IPsec. Калі маршрут паказвае на інтэрфейс OpenVPN, а палітыка ўсё яшчэ адпавядае той жа пары, вы прайгралі канфлікт без здагадак.

Трымайце дампы без старонніх адрасоў, перш чым яны трапяць у тыкет. Табліца маршрутызацыі з прадакшн-хоста нясе ўнутраную тапалогію, і толькі радкі, якія адказваюць на пытанне, варта ўстаўляць.

Прачытайце палітыку, якая таксама дзейнічае

Спіс палітык паказвае кірунак, селектары і шаблон, які вырашае, што адбываецца з адпаведным пакетам. Спачатку чытайце выходны кірунак, затым уваходны бок для зваротнага трафіку, бо аднабаковы выключэнне стварае злучэнне, якое пачынаецца і ніколі не завяршаецца.

ip -s xfrm policy
swanctl --list-sas

Параўнайце селектары ў спісе з прэфіксамі, якія ўзгадніла злучэнне. Адключэнне ўсталявання маршрутаў strongSwan не выдаляе гэтыя палітыкі, а змена метрыкі не змяняе, якую пару крыніцы і прызначэння абараняе палітыка. Гэтыя два псеўдавыпраўленні варта выключыць адразу, бо людзі спрабуюць іх першымі.

Калі ў спісе няма палітыкі для чаканага прэфікса, праблема ў іншым месцы, і табліца маршрутызацыі, верагодна, гаворыць праўду. Калі ў ім ёсць шырэйшая палітыка, якая ахоплівае прэфікс, вы знайшлі перахоп.

Тры варыянты, калі абодва шляхі законныя

Звужэнне селектара IPsec — самы чысты варыянт, калі шырокі прэфікс быў зручнасцю, а не патрабаваннем. Змяншэнне селектара аддаленага трафіку да падсетак, якія сапраўды належаць за IPsec, выдаляе канфлікт адразу для ўсіх хастоў, і гэта каштуе перазапыту ключоў, а не новага кампанента.

Выключэнне тыпу pass — хірургічны варыянт, калі шырокі селектар павінен застацца. strongSwan падтрымлівае асобнае злучэнне, дзіця якога выкарыстоўвае рэжым pass, што паведамляе ядру, што адпаведны трафік не павінен апрацоўвацца IPsec. Адрас аддаленага боку на loopback утрымлівае гэтае злучэнне ад выбару для уваходных партнёраў, а селектары павінны апісваць рэальную дазволеную пару, а не ўсё.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

У прыкладах канфігурацыі strongSwan апісваецца гэты тып палітыкі і пагадненне аб loopback-партнёры. Трэці варыянт — дызайн на аснове маршрутызацыі з інтэрфейсамі XFRM, які прывязвае палітыку да трафіку, што маршрутызуецца праз названы інтэрфейс, а не да глабальнага селектара. Гэта міграцыя, а не дробная праўка, і трафік усё роўна павінен задавальняць узгодненыя селектары.

OptionUse it whenCost
Narrow the selectorThe broad prefix was convenienceA rekey and a policy review
Passthrough childThe broad selector must stayOne exception per intended pair
XFRM interfacePolicy should follow routingA design migration

Дакажыце выключэнне, не аслабляючы астатняе

Пасля загрузкі змены праверце выключэнне і звычайнае месца прызначэння, якое павінна застацца абароненым. Праверце абодва кірункі, затым апусціце тунэль OpenVPN і пацвердзіце, што адбываецца з выключаным трафікам. Выключэнне, якое моўчкі адпраўляе гэты прэфікс адкрыта, калі тунэль не працуе, — гэта рашэнне палітыкі, якое трэба прыняць свядома, а не выявіць падчас інцыдэнту.

Запішыце, які прэфікс выкарыстоўвае які шлях і чаму. Інакш наступны інжынер, убачыўшы шырокі селектар, адкрые тое ж расследаванне, і адказ будзе ляжаць у паведамленні commit, якое ніхто не чытае.

Падобныя артыкулы