Пераход VPN з IOS на ASA: перакладайце пагадненне, а не каманды

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

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

Крок 1: аддзяліце пагадненне ад сінтаксісу

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

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

Крок 2: назвіце аб'екты на кожнай платформе

На IOS XE ланцуг ключоў IKEv2 сілкуе профіль IKEv2, і гэты профіль далучаецца праз крыптакарту або профіль IPsec. На ASA група тунеляў утрымлівае профіль злучэння і яго атрыбуты IPsec, а крыптакарта паказвае на яе, як апісвае кіраўніцтва па профілі злучэння. Гэта розныя графы аб'ектаў з розным наследаваннем, таму пагрудковы адпаведнасць дае канфігурацыю, якая разбіраецца, але не злучаецца.

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

Крок 3: пераносьце ідэнтычнасць, а не толькі адрасы

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

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

Крок 4: узгодніце абарону да пераключэння

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

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

Крок 5: правярайце сэрвіс, а не сінтаксіс

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

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

Што вярнуць

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

Захоўвайце зыходны тэкст разам з тыкетам. Ён дакументуе, што прасілі, а матрыца — што ўзгаднілі.