Дзе назіраць за трафікам кліента OpenVPN на шлюзе

Вы хочаце ведаць, да якіх пунктаў прызначэння даходзіць падключаны кліент, таму адкрываеце абалонку на серверы VPN і ўводзіце ss. Нічога карыснага не з'яўляецца, і выснова, што тунэль зламаны, прыходзіць крыху занадта лёгка. Шлюз OpenVPN з маршрутызацыяй перадае пакеты кліента; ён не завяршае іх TCP-злучэнні і не мае для іх сокетаў. Доказы жывуць у іншым месцы, і якое менавіта месца залежыць ад таго, як абыходзяцца з трафікам пасля выхаду з тунэля.

Вызначце, якую схему вы бачыце

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

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

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

Спачатку прывяжыце адрас да сеансу

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

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

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

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

Чытайце табліцу патокаў на шлюзе з маршрутызацыяй

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

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

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

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

Адзін абмежаваны захоп для пацверджання чытання

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

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

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

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

Журналы проксі і межы ўбачанага

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

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

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