Направіць асобную падсетку філіяла праз інтэрнэт-выхад SonicWall у галаўным офісе

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

Пачніце з селектара, а не з маршруту

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

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

Дадайце палітыку філіяла, затым абараніце яе парадак

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

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

Завяршыце шлях у галаўным офісе

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

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

Вырашыце, што робіць група, калі тунель падае

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

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

Праверце з трох кліентаў, затым чыста адкаціце

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

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

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

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