Другі WAN-уваход VPN не працуе, але асноўны працягвае працаваць

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

Кожнаму WAN патрэбны ўласны кантракт уваходу

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

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

Праверце, ці сапраўды адказвае другі WAN

Тэстуйце звонку ад абодвух ліній, а не з машыны за шлюзам, і тэстуйце дакладна тое імя, якое выкарыстоўвае профіль кліента. Для слухача TLS хуткая праверка — openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts якую выконваюць з хоста па-за вашай сеткай. Вам патрэбна завершанае рукапоцісканне, ланцужок якога адпавядае імені ў профілі, а не проста TCP-порт, які прымае злучэнне.

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

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

Сачыце за адказам, а не толькі за запытам

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

Праверце рашэнне маршрутызацыі для трафіку, крыніца якога — другі ўваход. Адказ павінен сыходзіць праз інтэрфейс, на які прыйшоў запыт, або хаця б несці адрас, які далёкі бок прымае як належны да гэтага шляху. На платформах маршрутызацыі па палітыцы гэта азначае правіла, прывязанае да ўваходнага інтэрфейса або да пераўтворанай крыніцы, плюс аператар пераўтварэння, прывязаны да кожнага знешняга інтэрфейса. Рабіце захоп адначасова на абодвух інтэрфейсах, пакуль кліент падключаецца; SYN, які прыйшоў праз правайдэра B, і SYN-ACK, які сышоў праз правайдэра A, вырашаюць пытанне за адзін прагон.

Дайце кліенту спосаб даведацца пра другі ўваход

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

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

Адзін адрас у двух правайдэраў — гэта іншы прадукт

Трымаць адзін публічны адрас дасяжным праз абедзве лініі — гэта паслуга маршрутызацыі, а не пункт у VPN. Яна патрабуе адраснай прасторы, якую абодва правайдэры гатовыя несці, абвешчанай так, каб іх сеткі яе прымалі, і менавіта гэта дае множнае падключэнне з незалежнай ад правайдэра прасторай і BGP. Прызначэнне адраса правайдэра A на інтэрфейс правайдэра B гэтага не дасягае; пакет прыходзіць у сетку, якая ніколі не абвяшчала прэфікс, і адкідаецца вышэй.

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

Што праверыць далей

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

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