Аварыйны выключальнік блакуе толькі IPv4: чаму IPv6 усё яшчэ выходзіць

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

Двухстэкавыя прылады маюць два незалежныя шляхі выхаду. Блакаванне аднаго з іх — гэта палова блакавання.

Два наборы правілаў, дзве прадвызначаныя палітыкі

У Linux iptables і ip6tables — асобныя табліцы з асобнымі палітыкамі. Пераключэнне ланцугоў INPUT і OUTPUT табліцы IPv4 у DROP нічога не змяняе ў табліцы IPv6, дзе прадвызначана звычайна ACCEPT. Такое ж раздзяленне існуе ў nftables, дзе можна агледзець сямейства і выявіць, што вашыя правілы нясе толькі адно з іх. Гэтая асіметрыя нармальная, і ўся праблема менавіта ў ёй.

Вось чаму аварыйны выключальнік можа выглядаць грунтоўным, а дзейнічаць часткова. Скрыпт, які напісаў правілы IPv4, адпрацаваў, лічыльнікі растуць, радок журнала з’яўляецца, а пакет IPv6 выходзіць праз фізічны інтэрфейс цалкам некранутым.

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

Што вам кажа канфігурацыя інтэрфейса

Старонка даведкі wg-quick уключае правілы IPv6 у прыкладзе канфігурацыі, і прычына — менавіта гэтая прабоіна. Прыклад — не ўпрыгожванне. Ён існуе таму, што адны правілы IPv4 пакінулі б другое сямейства адкрытым.

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

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Калі другі загад друкуе дазвольную палітыку, а першы — DROP, вы знайшлі адказ, не кранаючы кліент. Гэтая асіметрыя і ёсць памылкай.

Чаму аднаго запыту недастаткова

Адно імя можа вярнуць і запіс A, і запіс AAAA, а праграмы выбіраюць не аднолькава. Браўзер можа аддаць перавагу IPv6, калі сетка яго прапануе, і адкаціцца пры збоі, тады як фонавая сінхранізацыя або абнаўляльнік карыстаюцца ўласным рэзалверам і ўласнай перавагай. Таму адзін удалы тэст праз IPv4 даказвае адзін шлях, а не палітыку.

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

Праверце стан, калі тунель не працуе

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

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

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