Што паказвае адказ STUN, калі VPN працуе на маршрутызатары
Адрас тунеля на маршрутызатары — гэта не лакальны адрас браўзера. Прасачыце, як кожны запыт маршрутызуецца і пераўтвараецца, перш чым чытаць, што паведамляе адбівальнік.
Калі тунель знаходзіцца на маршрутызатары, машына, на якой працуе браўзер, наогул не мае інтэрфейсу тунеля. Спытайце ў гэтай машыны яе лакальныя адрасы — і атрымаеце прыватны адрас LAN і вяртанне, нічога падобнага на адрас VPN. Тым не менш STUN-сервер на іншым баку ўсё яшчэ можа паведаміць нешта значнае пра шлях, і тое, што ён паведамляе, цалкам залежыць ад таго, як менавіта гэты запыт быў маршрутызаваны і пераўтвораны.
Менавіта на гэтым варта спыніцца. «Браўзер не валодае адрасам VPN» адказвае на пытанне пра інтэрфейсы, а адбіты адрас — гэта адказ пра шлях праз пераўтварэнне. Змешванне гэтых двух сцвярджэнняў спараджае ўпэўненыя высновы пра раскрыццё, якіх доказы не падтрымліваюць.
Дзве прылады, два наборы інтэрфейсаў
У канфігурацыі з маршрутызатарам тунель заканчваецца на маршрутызатары, а кліент LAN адпраўляе звычайны трафік на свой шлюз па змаўчанні. Спіс інтэрфейсаў кліента застаецца кароткім: адзін прыватны адрас, магчыма другі для іншай сеткі, і вяртанне. Рызыка не ў тым, што адзін з іх выпадкова аказваецца адрасам тунеля; яна ў тым, што запыт выходзіць шляхам, які вы не выбіралі.
Спытайце кліент які маршрут прыме пэўная мэта замест пытання пра тое, якія інтэрфейсы існуюць. Адказ называе шлюз і адрас крыніцы, які выкарыстае ядро, і гэта ўжо больш інфарматыўна, чым любы пералік адрасоў.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsДыяпазоны дакументацыі — добрыя мэты для тэстаў, бо яны ніколі не развязаюцца ў рэальны сэрвіс. Параўнайце, што кажа кліент, з тым, што кажа маршрутызатар, і лічыце любое разыходжанне доказам таго, што палітычная маршрутызацыя, правіла падзеленага тунеля або другі маршрут па змаўчанні робіць нешта, што вы не ўлічылі.
Што дазволена гаварыць адказу Binding
RFC 8489 вызначае запыт і адказ Binding, дзе сервер паведамляе адрас крыніцы транспарту, які ён назіраў для гэтага запыту. Гэта сцвярджэнне пра адну пятёрку ў адзін момант, а не перапіс інтэрфейсаў кліента. Таму ўсё цікавае адбываецца паміж кліентам і пунктам назірання.
Гэты разрыў запаўняецца маршрутызацыяй і пераўтварэннем. Маршрутызатар, які робіць source-NAT для зыходнага трафіку, замяняе прыватную крыніцу кліента сваім адрасам на зыходным інтэрфейсе. Калі гэты інтэрфейс — тунель, адбівальнік бачыць адрас тунеля. Калі пакет выключаны з тунеля, адбівальнік бачыць тое, што стварыла пераўтварэнне WAN. Той жа кліент, той жа адбівальнік, розны адказ.
Тры выпадкі, якія выглядаюць аднолькава і не з’яўляюцца такімі
Карысная розніца не паміж публічным і прыватным, а ў тым, які пункт прымянення апрацаваў пакет. Разбярыце выпадкі з адкрытымі ўласнымі табліцамі маршрутызатара, бо адзін браўзер можа стварыць усе тры ў залежнасці ад правіла, якое вы забыліся напісаць.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Толькі другі выпадак парушае патрабаванне, што пэўны трафік ніколі не выходзіць напрамую, і толькі першы і трэці раскрываюць ідэнтыфікатар з боку тунеля. Ні адзін з трох радкоў не з’яўляецца сцвярджэннем пра паводзіны канкрэтнага правайдэра: ці дасягальны прыватны адбівальнік наогул, залежыць ад маршрутызацыі, дазволеных IP аднаго боку і палітыкі фаеруола з абодвух бакоў.
Наяўнасць уліковага запісу ў таго ж правайдэра нічога з гэтага не даказвае. Варта таксама памятаць, што маршрутызаваны запыт можа захаваць LAN-крыніцу кліента, калі нішто яе не пераўтварае, таму поле крыніцы трэба прасачыць, а не меркаваць па схеме тапалогіі.
Збор — гэта не выбар
WebRTC збірае адрасы-кандыдаты для спробы, і кандыдат, які з’явіўся ў дыягнастычным спісе, можа ніколі не несці медыя. Чытанне спісу як «вось што даведаўся партнёр» перабольшвае доказы. Выбраная пара — гэта тое, што фактычна несла сесію, і яна знаходзіцца ў іншым полі.
Правяральнік выхаду HTTPS адказвае на яшчэ адно пытанне: які адрас крыніцы ўбачыў вэб-сервер для гэтага запыту. Гэта карысная перакрыжаваная праверка менавіта таму, што ён выкарыстоўвае іншы пратакол і часта іншую мэту, чым UDP-адбівальнік, а разыходжанне паміж імі звычайна паказвае на правіла маршрутызацыі, а не на памылку.
Вызначце палітыку, потым чытайце адказ
Запішыце намер перад тэставаннем: які трафік павінен ісці праз тунель, які можа выходзіць напрамую, якія сямействы адрасоў у межах, і што павінна адбывацца, калі тунель не працуе. Без гэтай базавай лініі кожнае назіранне неадназначнае, бо вы не можаце аддзяліць уцечку ад шляху, які самі свядома дазволілі.
Затым задавайце па адным пытанні. Які маршрут прымае гэта мэта. Які адрас паведамляе гэты адбівальнік. Якую пару кандыдатаў выбрала сесія. Трымайце адказы побач з палітыкай і датуйце іх, бо абнаўленне прашыўкі можа змяніць паводзіны па змаўчанні так, што ціха анулюе леташнюю выснову.
Маршрутызатар па-ранейшаму моцны пункт прымянення, бо ён бачыць трафік, які кліент не можа абыйсці, не перанастроіўшы самога сябе. Гэта не абяцанне, што кожнае поле ў кожным пратаколе прыкладання нічога не раскрывае, і гэта не замена таму, каб запісаць шляхі, якія вы вырашылі дазволіць.