Поўны тунэль у strongSwan патрабуе 0.0.0.0/0 на абодвух баках

Поўны тунэль патрабуе 0.0.0.0/0 як remote_ts кліента і як local_ts шлюза, плюс перасыланне, NAT і зваротны маршрут. Праверце ўсе чатыры.

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

Спачатку праверце селектар кліента

Кліент апісвае тое, што хоча абараніць на далёкім баку, як remote_ts, і ўсё, што ён адпраўляе, выходзіць з яго ўласнага прызначанага адраса. Для інтэрнэт-трафіку гэта значэнне павінна ахопліваць пункты прызначэння, да якіх карыстальнік фактычна дабярэцца, што на практыцы азначае ўсю прастору IPv4. Кліент, які ўсё яшчэ пералічвае адну падсетку, просіць раздзелены тунэль, як бы профіль ні называўся ў інтэрфейсе. Бок крыніцы звычайна dynamic, бо адрас прызначаецца ў момант падключэння. Фіксаваная крыніца, запісаная там, ламаецца, як толькі пул зменіцца.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Фрагмент — гэта не поўны файл злучэння, і гэты мяркуе, што аўтэнтыфікацыя, ідэнтычнасці і пул віртуальных адрасоў ужо наладжаны. Селектар крыніцы кліента і адрас, які прызначае сервер, усё яшчэ павінны супадаць, інакш child SA ўзнімецца з абсягам, якога не чакаў ні адзін бок. Загрузіце яго з swanctl --load-all і прачытайце вывад, перш чым меркаваць поспех. Файл, які разбіраецца, усё яшчэ можа быць адхілены з-за селектара, які не перакрываецца з прапановай процілеглага боку.

Праверце селектар шлюза на яго баку

Шлюз чытае тое ж паняцце з адваротнага напрамку. Інтэрнэт-пункты прызначэння лакальныя для шлюза, таму яго local_ts — шырокі, а remote_ts апісвае пул кліентаў. Гэтая інверсія — самая распаўсюджаная памылка ў канфігурацыі поўнага тунэля, і яна праходзіць разгляд, бо абодва радкі паасобку выглядаюць праўдападобна.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

Стары ipsec.conf выкарыстоўвае ролі левага і правага з рознымі ключамі, і радок rightsubnet не з’яўляецца прамой заменай значэння swanctl. Трымайце два сінтаксісы ў асобных файлах, замест таго каб устаўляць адзін у другі. Змешванне іх у адной дырэкторыі — гэта тое, як працоўнае злучэнне ціха вяртаецца пасля перазагрузкі.

Праверце ўзгоднены child SA, а не файл

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Першая каманда паказвае, што загрузіў дэман, другая — усталяваныя child SA, трэцяя — палітыкі, якія прымяніць ядро. Калі файл кажа 0.0.0.0/0, а спіс паказвае адну падсетку, перамовы звузілі абсяг, і перачытванне файла гэтага не патлумачыць. Спыніце child, перазапусціце яго і зноў параўнайце ўсе тры вывады. Child, які вяртаецца з тым жа вузкім абсягам, звужаецца далёкім бокам, а не лакальным файлам, і гэта размова з іншым адміністратарам, а не лакальная праўка.

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

Праверце перасыланне і зваротны маршрут

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

Праверце, што тунэль усё яшчэ не ахоплівае

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

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

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

Падобныя артыкулы