Ланцуг з двух VPN: што ён хавае і колькі каштуе
Укладзеныя тунелі мяняюць, хто бачыць які канец, а не хто бачыць вас. Правядзіце ўнутраны канец праз знешні тунель, затым праверце DNS, MTU і запасны шлях.
Два ўкладзеныя тунелі не робяць вас ананімным. Яны дзеляць назіранні паміж двума пастаўшчыкамі, таму ні адзін не бачыць ваш хатні адрас і пункт прызначэння разам. Гэта сапраўдная, але вузкая перавага, і яна прыходзіць з праблемамі маршрутызацыі, 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. Праверце збой, які вы сапраўды атрымаеце
Наўмысна абарвіце знешні тунель і паназірайце, што адбудзецца. Ланцуг, які маўкліва вяртаецца на прамы шлях, калі знешні скок памірае, горшы за адсутнасць ланцуга, бо ён уцякае менавіта ў той момант, калі вы верылі, што ахова ёсць. Патрэбныя паводзіны — гэта выключальнік, які спыняе ўвесь трафік. Запішыце вынік, бо вы не захочаце выяўляць яго зноў пасярод інцыдэнту.
Затрымка і другая кропка адмовы — гэта пастаянныя выдаткі. Два скачкі таксама азначаюць дзве чаргі падтрымкі, калі нешта ламаецца ў нязручную гадзіну.