Адказ VPN паміж пляцоўкамі не ідзе праз тунель

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

Абодва кірункі маршрутызуюцца асобна

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

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

Далёкі хост нічога не ведае пра ваш тунель

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

Другога інтэрфейса дастаткова, каб зламаць гэта, нават калі маршрут існуе. NAS з кіраўніцкім каналам у іншай VLAN, сервер з рэзервовым uplink, правіла палітыкі, якое адпраўляе адзін дыяпазон крыніц у другую табліцу: любое з гэтага можа перахапіць адказ. У Linux ip rule show і ip route show table all паказваюць правілы і табліцы, якія стандартны спіс хавае.

Чытайце рашэнне на той машыне, якая адпраўляе адказ

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

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

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

У Windows эквіваленты — Find-NetRoute -RemoteIPAddress 10.10.5.10 для рашэння і Get-NetRoute для табліцы. Маршрут, дададзены праз New-NetRoute з вышэйшай метрыкай за маршрут па змаўчанні, прайграе ціха, таму чытайце слупок метрыкі, а не запіс. Затым пацвердзіце пакетамі: tcpdump -ni any "host 10.10.5.10 and tcp port 445" на далёкім LAN-інтэрфейсе паказвае запыт, а той жа фільтр з боку тунеля паказвае, ці вярнуўся адказ. Запыт бачны без адказу — значыць адказ быў накіраваны ў іншае месца або скінуты; адказ на няправільным інтэрфейсе дае вам віноўніка раней, чым вы дакранецеся да маршруту.

Калі шлюз сервера не з’яўляецца канчатковым пунктам VPN

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

У шлюза ёсць свой другі фільтр. Зваротная фільтрацыя шляху ў Linux скідае пакеты, крыніца якіх недасягальная праз інтэрфейс, з якога яны прыйшлі, а гэта менавіта форма законнага асіметрычнага зваротнага шляху. кіраўніцтва strongSwan па перасылцы патрабуе net.ipv4.ip_forward і паслабленага net.ipv4.conf.all.rp_filter менавіта з гэтай прычыны. Строгае значэнне 1 на любым са шлюзаў ціха ламае правільны маршрут, і nstat -az паказвае скідванні, калі вы ведаеце, куды глядзець.

Маршрут або трансляцыя, потым праверка ў абодвух кірунках

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

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

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

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