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

1. Вызначце, для чаго патрэбен другі скок

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

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

2. Зрабіце ўнутраны канец дасяжным праз знешні тунель

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

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

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

3. Трымайце DNS на тым жа шляху

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

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

4. Задайце MTU, пакуль карыстальнікі не выявілі гэта за вас

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

ip link set dev wg1 mtu 1280 — гэта грубое рашэнне, а абмежаванне MSS на перасылальніку — акуратнейшае. Паўтор спробы злучэння зусім не рашэнне.

5. Праверце збой, які вы сапраўды атрымаеце

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

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

Падобныя артыкулы