Клиенти на хотспот на 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 broadcast съобщения не преминават през маршрутизиран тунел и никоя настройка на моста не го променя; насочването на клиентите към домашен 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.

Транслацията е избор на политика, а не изискване. Source 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 дизайн, вместо да описвате локалния мост като мостов и да чакате broadcast да се появи.