Аддаленыя карыстальнікі не дасягаюць другога сайта праз VPN-канцэнтратар

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

Транзіт патрабуе трох пошукаў, а не аднаго тунэля

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

Вось чаму праверка кожнага тунэля асобна даказвае так мала. Пінг лакальнага адраса канцэнтратара задзейнічае першае рашэнне, а пінг канцэнтратара з штаб-кватэры — трэцяе. Пакет, які не праходзіць, мае пул карыстальнікаў як крыніцу і другі сайт як прызначэнне, таму спачатку запішыце гэтыя прэфіксы. Тут пул — 10.80.0.0/24, лакальная сетка канцэнтратара — 10.10.0.0/24, а штаб-кватэра — 10.20.0.0/24.

Праштурхніце далёкі прэфікс да аддаленага кліента

На серверы аддаленага доступу OpenVPN кліент даведаецца пра маршруты ў момант падключэння. Без push кліент са спліт-тунэлем адпраўляе 10.20.0.50 на сваю ўласную браму, і пакет ніколі не трапляе ў тунэль.

push "route 10.20.0.0 255.255.255.0"

Праштурхнуты маршрут з'яўляецца, калі кліент падключаецца, таму карыстальнік, які застаецца анлайн, нічога не бачыць, пакуль не перападключыцца. Праверце на кліенце: ip route get 10.20.0.50 у Linux, route print у Windows. Вывад павінен называць інтэрфейс тунэля.

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

Дайце канцэнтратару сапраўдны маршрут выхаду

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Там, дзе плечо сайт-сайт само па сабе OpenVPN, маршрут можа жыць у той канфігурацыі з адрасам тунэля партнёра ў якасці брамы: route 10.20.0.0 255.255.255.0 172.30.0.2. Брама не з'яўляецца неабавязковай. Калі яе прапусціць, наступны хоп апынецца ў рэалізацыйным значэнні па змаўчанні, якое адрозніваецца паміж кліентам з адной аддаленай кропкай і канцэнтратарам з некалькімі партнёрамі.

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

Пашырце далёкі бок на пул карыстальнікаў

Штаб-кватэра ўжо ахоплівае лакальную сетку канцэнтратара, 10.10.0.0/24. Пул карыстальнікаў — гэта другі прэфікс, і ён таксама павінен быць у селектарах, інакш ніякая палітыка не ахоплівае адказ, адрасаваны 10.80.0.25. Кожны партнёр называе адну і тую ж пару набораў прэфіксаў са свайго боку:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

local_ts аднаго боку — гэта remote_ts другога. Скапіруйце блок канцэнтратара ў штаб-кватэру, і пара перавернецца, таму дачэрні SA ніколі не ўзнікне.

Старэйшы сінтаксіс ipsec.conf выкарыстоўвае leftsubnet праз коску. Працуючая асацыяцыя бяспекі захоўвае селектары, якія яна ўзгадніла, таму пераўсталюйце тунэль пасля правак. Селектар, зменены ў 10:00 і правераны супраць SA, якая ўзнялася ў 09:40, усё яшчэ падае, хаця файл канфігурацыі ўвесь час выглядае правільным.

Затым праверце апошні хоп. ip route get 10.80.0.25 на далёкім канчатковым пункце павінен паказваць у тунэль. Калі служба выкарыстоўвае лакальны маршрутызатар як сваю браму па змаўчанні, гэтаму маршрутызатару таксама патрэбны зваротны маршрут, інакш адказ гіне там. Запуск tcpdump -ni eth1 host 10.80.0.25 на гэтым сегменце паказвае, ці пакінуў адказ канчатковы пункт наогул.

Дазвольце паток на канцэнтратары

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Фільтрацыя зваротнага шляху — гэта ціхі збой побач: калі два плечы на розных інтэрфейсах, rp_filter=1 можа скідваць адказ, пакуль лічыльнік правіла прыёму не рухаецца. Параўнайце iptables -vnL FORWARD да і пасля спробы. Правіла, якое ніколі не павялічваецца, не дасягаецца, таму глядзіце на ўзровень ніжэй, а не перапісвайце яго.

Калі транзіт патрэбны толькі адной групе, змясціце маршрут у файл для кожнага кліента ў client-config-dir замест пашырэння глабальнага push. NAT крыніцы на канцэнтратары таксама здымае патрэбу ў зваротным маршруце на далёкім баку, але ён хавае адрас карыстальніка, таму журналы далёкага сайта і правілы на аснове адрасоў перастаюць адрозніваць карыстальнікаў.

Праверце з кліента, затым адкаціце ў адваротным парадку

Праверце порт TCP, а не толькі ICMP, бо ping можа прайсці, пакуль служба застаецца заблакаванай. nc -vz 10.20.0.50 445 і traceroute -n 10.20.0.50 з кліента паказваюць, ці другі хоп — гэта адрас тунэля канцэнтратара. На канцэнтратары tcpdump -ni tun0 host 10.20.0.50 і той жа фільтр на інтэрфейсе сайт-сайт: запыт на абодвух без адказу на любым пераносіць праблему на далёкі бок.

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

Трымайце спіс адкату, бо змяніліся чатыры аб'екты, і тры з іх лёгка забыць: праштурхнуты маршрут, маршрут канцэнтратара, селектары і правілы міжсеткавага экрана. Адмяніце іх у адваротным парадку, пераўсталюйце SA і дазвольце аднаму карыстальніку перападключыцца. Частковы адкат пакідае маршрут, які паказвае на тунэль, што больш не супадае, і гэта цяжэй чытаць, чым зыходную цішыню. Кіраўніцтва OpenVPN 2.6 дакументуе push, route і iroute для вашай версіі.