Ці праходзіць трафік сапраўды праз VPN? Як гэта праверыць

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

Пачніце з маршруту, па якім пойдзе пакет

Табліца маршрутызацыі — гэта рашэнне, таму спытайце яе пра адзін пункт прызначэння замест таго, каб чытаць усё і здагадвацца. У Linux ip route get называе інтэрфейс і адрас крыніцы, якія выбрала ядро:

ip route get 203.0.113.10
ip route get 10.20.5.7

У Windows Find-NetRoute -RemoteIPAddress 203.0.113.10 карыснейшы за route print -4 па той жа прычыне: ён паведамляе пра маршрут, які перамог, а не пра ўсе існуючыя маршруты. Усё ж праглядзіце табліцу адзін раз дзеля яе радка 0.0.0.0. Пара /1 там азначае, што кліент поўнага тунеля пераписаў маршрут па змаўчанні: опцыя OpenVPN redirect-gateway def1 усталёўвае 0.0.0.0/1 і 128.0.0.0/1 праз тунель, і гэта перамагае існуючы 0.0.0.0/0 па найдоўгай адпаведнасці прэфікса, не выдаляючы фізічны маршрут па змаўчанні. Таму два маршруты па змаўчанні могуць суіснаваць, пакуль усё па-ранейшаму ідзе ў тунель.

Дзве дэталі робяць табліцу хлуслівай. Па-першае, глядзіце на прэфікс, які супаў, а не на колькасць маршрутаў па змаўчанні, бо менавіта метрыка інтэрфейса або пара /1 вызначае пераможцу. Па-другое, злучэнне, якое ўжо існуе, захоўвае шлях, з якім было ўсталявана; пасля ўздыму тунеля адкрытая сесія можа працягваць карыстацца старым маршрутам, пакуль яе не скінуць, і менавіта таму перападключэнне нібы выпраўляе праблему маршрутызацыі. Працуючы кліент — ps ax | grep openvpn — даказвае толькі тое, што працэс запусціўся.

Прасачыце адно ўнутранае і адно публічнае імя

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

traceroute intranet.corp.example
traceroute 1.1.1.1

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

Адфільтраваны ICMP робіць гэтую праверку хлуслівай: зоркі на абодвух шляхах выглядаюць як мёртвы тунель і звычайна азначаюць фаеруол. Праверце TCP-порт там, дзе можна — traceroute -T -p 443 у Linux — і памятайце, што шлях нічога не кажа пра тое, які рэзалвер адказаў: імя можа развязацца лакальна і ўсё роўна быць дасягальным праз тунель.

Рабіце захоп на фізічным адаптары, а не на тунелі

Фізічнае злучэнне — адзінае месца, якое паказвае, што сетка сапраўды бачыць. Пры ўзнятым тунелі сесія да офіса павінна выглядаць як зашыфраваная нагрузка, адрасаваная серверу VPN, а не як злучэнне да 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Першы фільтр ловіць развязанне імёнаў, якое выходзіць лакальна; гэта найбольш частая ўцечка і самая ціхая — старонка ўсё роўна загружаецца, проста рэзалвер убачыў запыт. Другі ловіць звычайны трафік да ўнутранага адрасу, які мусіць існаваць толькі ўнутры тунеля. У Windows pktmon робіць тое ж без драйвера: pktmon filter add -p 53, потым pktmon start --capture --pkt-size 128, потым pktmon stop і pktmon format pktmon.etl -o capture.txt. Гэтыя сцягі крыху адрозніваюцца паміж зборкамі Windows, таму праверце pktmon filter add /? перад тым, як давяраць сінтаксісу.

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

Спытайце знешні сэрвіс, а потым яшчэ раз для кожнай праграмы

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

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Розныя адказы даюць доказ абодвух шляхоў і спосаб праверыць пэўную праграму: прыхіліце яе да інтэрфейса або запусціце ў сеткавай прасторы імёнаў з адным маршрутам і паглядзіце, які адрас зафіксуе далёкі бок. Аднолькавыя адказы — гэта цікавая няспраўнасць: альбо прыхіленне не спрацавала, альбо нешта паміж хастом і далёкім бокам перапісвае адрас крыніцы перад прыходам. У Windows curl --interface патрабуе адрас адаптара, а не яго імя.

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

Выкарыстайце прадстаўленне сервера, каб пацвердзіць піра

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

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

Адрозніце праектнае рашэнне ад уцечкі

Не ўсё па-за тунелем — уцечка. Трафік link-local і шырокавяшчальны застаецца лакальным па праекту, прынтар, знойдзены праз multicast, працягвае абвяшчаць сябе ў LAN, а DHCP мусіць выходзіць лакальна. Праграма, прыхіленая да пэўнага інтэрфейса, наўмысна абыходзіць табліцу маршрутызацыі, і гэта змяняе толькі правіла фаеруола, прастора імёнаў або палітычны маршрут.

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

Калі праверкі разыходзяцца, разыходжанне звычайна называе няспраўнасць:

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