Кліенты хотспота на Pi не дасягаюць хатняй LAN праз TUN VPN

Лакальныя кліенты Wi-Fi і Ethernet падключаюцца да хотспота Pi, атрымліваюць адрас з яго DHCP-дыяпазону і загружаюць інтэрнэт-старонкі без скаргаў. Затым гэтыя ж кліенты атрымліваюць тайм-аўт, калі адкрываюць файлавы агульны рэсурс або вэб-інтэрфейс у хатняй LAN, тады як сам Pi дасягае гэтай LAN праз тунель. У бесправодным узроўні нічога не зламана. Не хапае маршрутызаванага кантракту: прэфікс хотспота павінен пераносіцца ў інтэрфейс TUN, і нешта на хатнім баку павінна ведаць, як адпраўляць туды адказы. Абедзве паловы павінны існаваць, перш чым адзін пакет зможа завяршыць паездку туды і назад.

Тры падключэнні з трыма рознымі задачамі

Мост Ethernet у Linux перасылае кадры па адрасе прызначэння MAC. OpenVPN у рэжыме TUN пераносіць IP-пакеты і зусім не мае ўзроўню MAC, таму даданне лакальнага моста ніколі не ўключае тунель як порт. Дакументацыя ядра TUN/TAP тлумачыць гэтае размежаванне: прылада TAP выглядае як інтэрфейс Ethernet, а прылада TUN — не. Дызайн, які злучае два лакальныя парты, а затым маршрутызуе, з'яўляецца маршрутызатарам, як бы ні называліся інтэрфейсы.

Гэтае размежаванне вырашае пытанне ўласнасці. Падсетка кліентаў, іх шлюз па змаўчанні і права DHCP для гэтага дыяпазону належаць лакальнаму плану Pi. Хатнія DHCP-шырокавяшчальныя паведамленні не перасякаюць маршрутызаваны тунель, і ніякая налада моста гэтага не змяняе; накіраванне кліентаў на хатні DHCP-сервер — гэта асобны, наўмысны дызайн рэтрансляцыі з уласнымі рэжымамі збояў.

Трымайце мадэм таксама па-за мостам кліентаў. Падключэнне PPP — гэта не прылада Ethernet з іншай этыкеткай, і дакументаваная логіка маршруту па змаўчанні ў pppd працуе пасля перамоваў IPCP і адклікае свой маршрут, калі гэтае злучэнне падае. Капіраванне шаблона DHCP і перайменаванне кожнага usb0 у ppp0 нічога не даказвае пра шлюз, метрыку або жыццёвы цыкл.

Выберыце прэфіксы, перш чым рэдагаваць якую-небудзь канфігурацыю

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Першы пул — гэта адрас underlay, які аператар выдаў мадэму; ён павінен заставацца па-за любым планам, звернутым да кліентаў. Другі — гэта падсетка тунеля, якую выбраў сервер, часта ўласная прыватная /24-сетка. Трэці — мост хотспота, а чацвёрты — хатні прэфікс, да якога вы хочаце дасягнуць. У гэтым праходзе хотспот атрымлівае 172.28.90.0/24 з мостам на 172.28.90.1, а хатняя службовая LAN захоўвае 192.168.77.0/24, што абыходзіць стандартныя 192.168.1.0/24 і 10.0.0.0/24, якія пастаўляюцца спажывецкімі маршрутызатарамі, і дыяпазон аператара 100.64.0.0/10.

Абвяшчайце адрас моста як шлюз у DHCP-дыяпазоне хотспота і нічога іншага. Ніколі не давайце кліентам хотспота хатні адрас у якасці шлюза; у іх няма шляху на ўзроўні злучэння да гэтага сегмента.

Маршрутызуйце кожны кірунак на тым баку, які ім валодае

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

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Калі ip route get усё яшчэ паведамляе пра інтэрфейс underlay, спыніцеся там; нішто далей на шляху не можа выправіць няправільны пошук.

Хатнія прылады не маюць маршруту да 172.28.90.0/24, таму іх адказы ідуць за шлюзам па змаўчанні і гінуць на маршрутызатары. Існуюць два падтрыманыя выпраўленні. Або дадайце статычны маршрут на хатнім маршрутызатары, які накіроўвае прэфікс хотспота на LAN-адрас VPN-сервера, або, калі сервер сам з'яўляецца шлюзам, зарэгіструйце прэфікс кліента ў ўласнай табліцы маршрутызацыі сервера. У шматкліенцкім рэжыме OpenVPN каталог, спецыфічны для кліента, нясе гэтую сувязь: файл, названы па агульным імені сертыфіката кліента, які змяшчае iroute 172.28.90.0 255.255.255.0 плюс адпаведны радок route, што ўсталёўвае яго ў ядры сервера. Меркаваны маршрут ядра на серверы — гэта не тое ж сцверджанне, што паведаміць серверу, які кліент валодае прэфіксам.

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

Адкрыйце перасылку, не ўгадваючы файрвол

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Шукайце правіла прыняцця ад br0 да tun0 і адпаведны кірунак адказу, а таксама правіла postrouting, якое можа перапісаць крыніцу. Калі палітыка ланцуга — drop і ні адно правіла не супадае, дадайце вузкія правілы прыняцця і паўторна праверце, замест таго каб пераключыць палітыку на accept.

Трансляцыя — гэта выбар палітыкі, а не патрабаванне. NAT крыніцы ў бок хатняй LAN робіць кожнага кліента хотспота падобным на адрас тунеля Pi, што губляе атрыбуцыю па кожным кліенце ў хатніх журналах і ламае службы, якія чакаюць зыходную крыніцу. Маршрутызацыя без NAT пакідае адрасы кліентаў бачнымі, але залежыць ад зваротнага маршруту вышэй. Выберыце адзін і апрацоўвайце DNS і IPv6 гэтак жа, бо працоўны шлях IPv4 побач са зламаным шляхам IPv6 усё яшчэ чытаецца як напалову зламаны ў браўзеры.

Праверце паездку туды і назад, затым наўмысна зламайце яе

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Чытайце два захапленні разам. Запыты на br0, якія ніколі не з'яўляюцца на tun0, азначаюць, што Pi не перасылае або маршрут паказвае ў іншае месца. Запыты на tun0 без адказаў азначаюць, што хатні бок не мае зваротнага маршруту або сервер адфільтраваў пакет. Адказы на tun0, якія ніколі не з'яўляюцца зноў на br0, азначаюць, што адваротнае правіла фільтрацыі адсутнічае, калі тунель выглядае бездакорна, а кліент усё роўна нічога не бачыць.

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

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