IPv6 лакальны адрас спасылкі не працуе праз VPN: чаму fe80 спыняецца на спасылцы
Адрас fe80:: мае сэнс толькі на адной спасылцы. Паглядзіце, чаму маршрутызаваны VPN не можа яго перанесці, як выглядае збой і які адрас выкарыстоўваць замест.
Вы ўзнімаеце тунель, робіце ping fe80::1 з тунелем у якасці зыходнага інтэрфейса — і нічога не вяртаецца. Гэта не правіла міжсеткавага экрана, якое вы забылі. Лакальны адрас спасылкі мае сэнс толькі на адзінай спасылцы, дзе ён сфарміраваны, а маршрутызаваны VPN — не тая спасылка. Адрас fe80::1 аддаленага маршрутызатара жыве на аддаленым сегменце лакальнай сеткі; вы знаходзіцеся на адзін крок далей на іншым сегменце, і IPv6 не мае ніякага механізму, каб маршрутызатар наогул перасылаў пакеты лакальнай спасылкі.
Прэфікс fe80 апісвае межы дзеяння, а не дыяпазон
Лакальны адрас спасылкі — гэта fe80::/10, і вызначальная ўласцівасць тут не лік, а межы дзеяння. Адрас сапраўдны толькі на адной спасылцы, і кожны інтэрфейс фарміруе яго з уласнага ідэнтыфікатара; менавіта таму дзве незвязаныя машыны ў дзвюх незвязаных сетках могуць абедзве адказваць на fe80::1 без найменшага канфлікту. Прэфікс па сутнасці кажа “на нейкай спасылцы”; сама спасылка прыходзіць з кантэксту.
На хаце гэты кантэкст — зона, або ідэнтыфікатар меж, які вы дадаеце пасля знака працэнта: fe80::1%eth0 у Linux, fe80::1%3 або fe80::1%12 у Windows і ў інструментах, якія паказваюць індэксы інтэрфейсаў. Ядро развязвае адрас разам з індэксам інтэрфейса і потым дасылае. Прыбярыце зону — і прызначэнне становіцца неадназначным, таму стэк не мае спосабу выбраць сегмент.
Чаму маршрутызаваны тунель не можа яго даставіць
Маршрутызаваны VPN — гэта інтэрфейс пункт-пункт, які нясе ўласныя адрасы, звычайна /64 унікальнай лакальнай або прыватнай прасторы IPv6 унутры тунеля. Аддаленая лакальная сетка — асобная спасылка, дасяжная праз маршрутызацыю і перасылку канчатковага пункта тунеля ад вашага імя. Гэта два розныя сегменты, таму адрас з аднаго не з'яўляецца сапраўдным прызначэннем на другім.
Правіла перасылкі прапісана ў стандарце, а не з'яўляецца дзівацтвам вашага кліента: маршрутызатары не перасылаюць пакеты з лакальным адрасам спасылкі ў крыніцы або прызначэнні. Менавіта таму пакет гіне, нават калі табліца маршрутызацыі выглядае правільна. Дадайце маршрут fe80::/64 на тунель — і стэк, што адпавядае стандарту, або адхіліць яго, або прыме і скідзе кожны адпаведны пакет: межы прызначэння кажуць “толькі гэтая спасылка”, а зыходны інтэрфейс — не тая спасылка.
Выяўленне суседзяў падмацоўвае тую ж мяжу. Хаты развязваюць наступныя крокі лакальнай спасылкі запытам да суседзяў, накіраваным у множныя рассылкі межаў спасылкі з лімітам у 255 крокаў, каб маршрутызатары маглі адхіляць усё перасланае. Каб гэта працавала праз тунель, давялося б праксіраваць выяўленне для аддаленага сегмента, а гэта маставанне ўзроўню 2 ў іншай шапцы.
Ёсць і цішэйшы другі збой, які збівае з панталыку тых, хто ўсё ж спрабуе сілай прапісаць маршрут: зона. Якая б зона ні была набрана лакальна, яна называе інтэрфейс тунеля, а патрэбны вам адрас прывязаны да інтэрфейса аддаленай лакальнай сеткі. Яны ніколі не супадаюць, таму пакет нельга накіраваць на правільны інтэрфейс на далёкім канцы.
Як збой выглядае на практыцы
Вывад інструментаў пры памылцы з межамі дзеяння чытаецца як памылка маршрутызацыі або міжсеткавага экрана — менавіта таму людзі бавяць паўдня не ў тым узроўні.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
Трэці радок марнуе найбольш часу, бо кліент ssh без вываду выглядае як праблема службы, што слухае. Калі ў вас ёсць хоць які-небудзь шлях унутр, праверце далёкі бок і высветліце, ці sshd прывязаны да ўсіх адрасоў, ці толькі да аднаго.
Выкарыстоўвайце адрас, прызначаны для маршрутызацыі
Для ўсяго, да чаго трэба дабрацца праз тунель, выкарыстоўвайце адрас, выдадзены службе менавіта для гэтага: глабальны адрас аднаасобнай рассылкі, або унікальны лакальны адрас з fc00::/7, дыяпазон, захаваны менавіта для гэтага ўнутранага выпадку. Пераканайцеся, што слухач сапраўды яго прывязвае, і праверце зваротны шлях і любое правіла міжсеткавага экрана на хаце.
Глядзіце на аддаленую хатку, а не ўгадвайце. ip -6 addr show пералічвае існуючыя адрасы, а ss -6 -ltn — тое, што слухае дэман. Служба, прывязаная толькі да fe80::, дасяжная толькі з уласнага сегмента; звычайна гэта прадвызначаная налада, якую ніхто не выбіраў наўмысна, і яе можна змяніць з згоды адміністратара.
Калі службу сапраўды немагчыма перапрывязаць, падніміце мост да ўзроўню праграм замест узроўню сеткі. Рэтранслятар на аддаленай хаце, які слухае маршрутызаваны адрас і злучаецца з лакальным адрасам спасылкі, вырашае праблему, не пашыраючы ніводнага сегмента:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Тут зона знаходзіцца на правільным баку, на хаце, дзе eth0 сапраўды на той спасылцы. Ваш кліент звяртаецца да fd00:1:2::10, які маршрутызуецца звычайна, а рэтранслятар робіць крок лакальнай спасылкі лакальна. Той жа прыём працуе для вэб-інтэрфейса прылады або старога BMC, які абвяшчае толькі лакальны адрас спасылкі.
Калі маставанне сапраўды з'яўляецца адказам і што правяраць
Некаторыя разгортванні сапраўды патрабуюць аднаго агульнага сегмента: прылада, што размаўляе толькі выяўленнем лакальнай спасылкі, прылада, залежная ад множных рассылак, лабараторыя, якая ўзнаўляе плоскую лакальную сетку. Гэта праблема ўзроўню 2, і ёй патрэбны адказ узроўню 2, напрыклад tap-прылада, падмошчаная да аддаленага інтэрфейса, або кліенцкі прадукт з яўным рэжымам маста. Гэта каштуе вам шырокавяшчальнага і множнага трафіку праз тунель, а таксама выяўлення суседзяў, якое мусіць працаваць ад канца да канца.
Не імітуйце гэта даданнем fe80::/64 у маршрутызаваны профіль. Так атрымліваецца найгоршы стан: канфігурацыя выглядае гатовай, табліца маршрутызацыі паказвае запіс, а кожны пакет усё роўна адкідваецца недзе паміж двума стэкамі, якія абодва паводзяць сябе правільна.
Правярайце інтэрфейсам, а не пінгам. ip -6 addr show tun0 скажа, ці ўтварыла спасылка тунеля ўласны лакальны адрас спасылкі, а ip -6 route get fe80::1%tun0 — што ядро сапраўды зробіць з прызначэннем у межах. Калі ядро кажа, што прызначэнне недасяжна на гэтым інтэрфейсе, ніякая налада тунеля гэтага не зменіць, і пара спыніць правіць профіль.
Кароткая паслядоўнасць, якая закрывае пытанне:
- Прачытайце адрас на аддаленай хаце і адзначце, ці гэта fe80::, ці маршрутызаваны прэфікс.
- Калі гэта fe80::, перапрывязаць службу, зрабіце рэтрансляцыю на той хаце або падмашчыце сегмент; калі маршрутызаваны — выпраўце маршрут, міжсеткавы экран або адрас прывязкі.
- Пераправярайце зону пры кожным паўторным тэсце, бо скапіяваная каманда звычайна захоўвае няправільны інтэрфейс.
Крыніцы: RFC 4291, архітэктура адрасацыі IPv6.