Hotspot клиентите на Pi не стигнуваат до домашната LAN преку TUN VPN

Локалните Wi-Fi и Ethernet клиенти се поврзуваат со hotspot-от на Pi, земаат адреса од неговиот DHCP опсег и вчитуваат интернет страници без поплаки. Потоа истите клиенти истекуваат кога отвораат споделување на датотеки или веб-интерфејс на домашната LAN, додека самиот Pi стигнува до таа LAN преку тунелот. Ништо во безжичниот слој не е расипано. Она што недостига е рутиран договор: префиксот на hotspot-от мора да се пренесе во интерфејсот 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-мрежа. Третиот е мостот на hotspot-от, а четвртиот е домашниот префикс што сакате да го достигнете. Во оваа прошетка hotspot-от добива 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 опсегот на hotspot-от како порта објавете ја само адресата на мостот и ништо друго. Никогаш не давајте им на hotspot клиентите домашна адреса како порта; тие немаат пат на слојот за поврзување до тој сегмент.

Рутирајте го секој правец на страната што го поседува

На 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, затоа нивните одговори ја следат стандардната порта и умираат кај рутерот. Постојат две поддржани поправки. Или додајте статична рута на домашниот рутер што го насочува префиксот на hotspot-от кон LAN адресата на VPN серверот, или, кога серверот самиот е порта, регистрирајте го префиксот на клиентот во сопствената табела за рутирање на серверот. Во режимот со повеќе клиенти на OpenVPN, директориумот специфичен за клиентот ја носи таа асоцијација: датотека именувана по заедничкото име на сертификатот на клиентот, која содржи iroute 172.28.90.0 255.255.255.0 плус соодветната линија route што ја инсталира во јадрото на серверот. Погодена рута во јадрото на серверот не е истата изјава како да му кажете на серверот кој клиент го поседува префиксот.

Не преместувајте ја DHCP услугата на домашната мрежа на VPN серверот за ова да работи. Замената на стандардната порта за цела куќа е многу поголема промена од додавање една приватна повратна рута и ги влече DNS, резервациите на адреси и секој уред што го игнорира новиот закуп во откажувањето.

Отворете го проследувањето без погодување на огнениот ѕид

Вклученото проследување не значи дека пакетот смее да помине. Сообраќајот од мостот кон тунелот сѐ уште ги погодува филтерските правила, а стандардната политика за проследување drop го фрла сообраќајот на hotspot-от додека сопствениот сообраќај на Pi продолжува да работи, што го произведува точно поделениот симптом погоре.

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

Барајте правило за прифаќање од br0 кон tun0 и соодветниот правец на одговор, и правило postrouting што може да го препише изворот. Ако политиката на синџирот е drop и ниту едно правило не се совпаѓа, додајте ги тесните прифаќања и тестирајте повторно наместо да ја превртите политиката во accept.

Преводот е избор на политика, не барање. Изворниот NAT кон домашната LAN го прави секој hotspot клиент да изгледа како тунелската адреса на Pi, што го губи доделувањето по клиент во домашните логови и ги крши услугите што го очекуваат оригиналниот извор. Рутирањето без NAT ги држи адресите на клиентите видливи, но зависи од повратната рута погоре. Изберете едно и третирајте ги DNS и IPv6 на истиот начин, бидејќи работна IPv4 патека покрај расипана IPv6 патека сѐ уште се чита како половично расипана во прелистувачот.

Проверете го патувањето напред и назад, потоа намерно расипете го

Тестирајте од hotspot клиент, никогаш од 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, а не преку самиот себе, класичната јамка кога турната стандардна рута се прифаќа без рута до домаќинот-партнер.

Прифатете го дизајнот само кога hotspot клиент може да реши домашно име, да отвори TCP услуга и да одржи сесија жива низ едно повторно поврзување на модемот. Ако апликацијата навистина бара откривање на Ethernet ниво во домашниот сегмент, изберете поддржан дизајн Layer 2 наместо да го опишувате локалниот мост како премостен и да чекате да се појави емитување.