Пашырэнне сайта VPN: прайдзіце зваротны маршрут за шлюзам

Трафік з філіяла заканчваецца на шлюзе, LAN якога не ўтрымлівае праграмы, да якой трэба было дабрацца. Сервер знаходзіцца ў другім цэнтры даных, за ўнутранай сувяззю, якую VPN ніколі не наладжваў. Даданне яшчэ аднаго прэфікса на блізкі шлюз нічога не дае для гэтага выпадку, бо далёкі шлюз — гэта канчатковы пункт шыфравання, а не апошні маршрутызатар. Шлях патрабуе маршруту далей, допуску на далёкай мяжы бяспекі і рашэння аб вяртанні ў самой сетцы прызначэння.

Далёкі шлюз — гэта канчатковы пункт шыфравання

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

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

Чытайце абодва напрамкі палітыкі тунэля

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

Запісвайце крыніцу і прызначэнне як адрасы, а не як назвы сайтаў. Неадназначнасць тут пазней вернецца як загадкавая асіметрыя.

Дадайце маршрут далей і пацвердзіце допуск

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

Праверце з філіяла, затым пераправерце стары шлях

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

Прызначце ўладальніка кожнаму з трох участкаў і зваротнаму маршруту ўнутры сеткі прызначэння. Шлях з чатырма ўладальнікамі правальваецца ў прамежках паміж імі.