Што запісваць для VPN паміж пляцоўкамі: селектары і абсяг

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

Наладжанае не значыць узгодненае

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

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

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

Тунелі на аснове маршрутаў выбіраюць інакш

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

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

Трансляцыя належыць у тую ж табліцу

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

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

Прыватны DNS належыць туды ж. Імя, якое развязаецца ў адрас, непрыдатны з адпаведнай пляцоўкі, — гэта памылка дакументацыі з далучанай заяўкай у падтрымку, і ў ёй абвінавацяць тунель.

Далучыце патрабаванне да паслугі

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

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

Ператварыце запіс у план тэставання

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

swanctl --list-sas

Скілета з пяці радкоў звычайна дастаткова, каб запіс заставаўся сумленным. Версія ніжэй змяшчаецца ў заяўку на змену без абрэзкі:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Пінг толькі да шлюза — не прыёмачны тэст. Ён ніколі не праходзіць транзітны шлях, таму можа прайсці, пакуль кожны перанакіраваны паток збойвае. Тэстуйце з хоста на адным баку да паслугі на другім і пацвердзіце, што адказ прыходзіць праз тунель. Калі праходзіць толькі пінг, запіс толькі што знайшоў праблему перанакіравання, для якой быў напісаны. дакументацыя strongSwan пра перанакіраванне тлумачыць, як селектары, маршруты і перанакіраванне ўзаемадзейнічаюць на вузле Linux.