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

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

Два спосабы, якімі сетка можа на вас паўплываць

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

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

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Адкуль маршрут можа ўзяцца яшчэ да існавання тунеля

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

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

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

Праверце шлях, які ядро фактычна выбірае

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

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

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

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

Вырашыце, дзе павінна жыць прымусовае выкананне

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

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

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

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