Клијенти хотспота на Pi не стижу до кућне LAN преко TUN VPN-а

Локални Wi-Fi и Ethernet клијенти повезују се са хотспотом Pi-ја, добијају адресу из његовог DHCP опсега и учитавају интернет странице без жалби. Исти клијенти затим истичу када отворе дељење датотека или веб интерфејс на кућној LAN, док сам Pi стиже до те LAN кроз тунел. Ништа у бежичном слоју није покварено. Недостаје рутирани уговор: префикс хотспота мора да се пренесе у TUN интерфејс, и нешто на кућној страни мора да зна како да пошаље одговоре тамо назад. Обе половине морају да постоје пре него што један пакет може да заврши пут тамо и назад.

Три повезивања са три различита задатка

Linux Ethernet мост прослеђује оквире према одредишној MAC адреси. OpenVPN у TUN режиму носи IP пакете и уопште нема MAC слој, тако да додавање локалног моста никада не региструје тунел као порт. документација језгра о TUN/TAP објашњава то раздвајање: TAP уређај изгледа као Ethernet интерфејс, TUN уређај не. Пројекат који спаја два локална порта и затим рутира јесте рутер, шта год да кажу имена интерфејса.

Та разлика одлучује власништво. Подмрежа клијената, њихов подразумевани гејтвеј и DHCP овлашћење за тај опсег припадају локалном плану Pi-ја. Кућна DHCP емитовања не прелазе рутирани тунел и ниједна поставка моста то не мења; усмеравање клијената на кућни DHCP сервер је одвојен, намеран relay дизајн са сопственим режимима отказа.

Држите модем и ван моста клијената. 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 уместо да локални мост описујете као премошћен и чекате да се појави емитовање.