Pi ішіндегі hotspot клиенттері TUN VPN арқылы үйдегі LAN-ға жетпейді

Жергілікті Wi-Fi және Ethernet клиенттері Pi-дің hotspot-ына қосылады, оның DHCP ауқымынан мекенжай алады және интернет беттерін шағымсыз жүктейді. Содан кейін сол клиенттер үйдегі LAN-да файл бөлісу немесе веб-интерфейс ашқанда уақыт бітеді, ал Pi өзі сол LAN-ға туннель арқылы жетеді. Сымсыз қабатта ештеңе бұзылмаған. Жетіспейтіні — маршрутталған келісім: hotspot префиксін TUN интерфейсіне апару керек және үй жағындағы бірдеңе жауаптарды сол жерге қалай қайтаруды білуі керек. Бір пакеттің барып-қайтуын аяқтауы үшін екі жарты да болуы керек.

Үш түрлі жұмысы бар үш қосылым

Linux Ethernet көпірі кадрларды мақсатты MAC мекенжайы бойынша жібереді. OpenVPN TUN режимінде IP пакеттерін тасымалдайды және MAC қабаты мүлде жоқ, сондықтан жергілікті көпір қосу туннельді порт ретінде ешқашан тіркемейді. ядроның TUN/TAP құжаттамасы осы бөлуді түсіндіреді: TAP құрылғысы Ethernet интерфейсіне ұқсайды, TUN құрылғысы ұқсамайды. Екі жергілікті портты көпірлеп, содан кейін маршруттайтын дизайн — интерфейс аттары қалай аталса да, маршрутизатор.

Бұл айырмашылық меншікті шешеді. Клиенттердің қосалқы желісі, олардың әдепкі шлюзі және сол ауқымның DHCP өкілеттігі Pi-дің жергілікті жоспарына жатады. Үйдегі DHCP хабарламалары маршрутталған туннельден өтпейді және ешбір көпір параметрі мұны өзгертпейді; клиенттерді үйдегі DHCP серверіне бағыттау — өз қателік режимдері бар жеке, әдейі жасалған реле дизайны.

Модемді де клиент көпірінен тыс ұстаңыз. PPP қосылымы — басқа жапсырмадағы Ethernet құрылғысы емес, және pppd-ның құжатталған әдепкі маршрут логикасы IPCP келіссөздерінен кейін жұмыс істейді және сол байланыс үзілгенде өз маршрутын кері қайтарады. DHCP үлгісін көшіріп, әр usb0-ды ppp0-ға ауыстыру шлюз, метрика немесе өмірлік цикл туралы ештеңе дәлелдемейді.

Кез келген конфигурацияны өңдемес бұрын префикстерді таңдаңыз

Қабаттасатын префикстер firewall ережелерінен де көп кеш жоғалтады, өйткені қабаттасу туннель сау болса да маршрут іздеуін дұрыс емес интерфейске жібереді. 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 ауқымынан жалтарады.

Hotspot-тың DHCP ауқымында тек көпір мекенжайын шлюз ретінде жариялаңыз, басқа ештеңе жоқ. 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 префиксін VPN серверінің LAN мекенжайына бағыттайтын статикалық маршрут қосыңыз, не сервер өзі шлюз болған кезде клиент префиксін сервердің өз маршруттау кестесіне тіркеңіз. OpenVPN-нің көпклиенттік режимінде клиентке тән каталог осы байланысты тасымалдайды: клиент сертификатының жалпы атымен аталған файл, оның ішінде iroute 172.28.90.0 255.255.255.0 және оны сервер ядросына орнататын сәйкес route жолы бар. Сервердегі болжалды ядро маршруты серверге қай клиент префикске ие екенін айтумен бірдей тұжырым емес.

Бұл жұмыс істеуі үшін үй желісінің DHCP қызметін VPN серверіне көшірмеңіз. Бүкіл үй үшін әдепкі шлюзді ауыстыру бір жеке қайтару маршрутын қосқаннан әлдеқайда үлкен өзгеріс және ол DNS-ті, мекенжай резервтерін және жаңа жалдауды елемейтін әрбір құрылғыны сәтсіздікке сүйрейді.

Firewall-ды болжамай қайта жіберуді ашыңыз

Қайта жіберудің қосулы болуы пакеттің өтуге рұқсаты бар дегенді білдірмейді. Көпірден туннельге трафик әлі де сүзгі ережелеріне соғылады және әдепкі drop қайта жіберу саясаты hotspot трафигін тастайды, ал Pi-дің өз трафигі жалғасады, бұл дәл жоғарыдағы бөлінген симптомды тудырады.

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

br0-тен tun0-ке дейінгі рұқсат ережесін және сәйкес жауап бағытын, сондай-ақ көзді қайта жаза алатын postrouting ережесін іздеңіз. Егер тізбек саясаты drop болса және ешбір ереже сәйкес келмесе, саясатты accept-қа аударудың орнына тар рұқсаттарды қосып, қайта сынаңыз.

Аударма — талап емес, саясат таңдауы. Үй LAN-ына қарай көздік NAT әр hotspot клиентін Pi-дің туннель мекенжайына ұқсатады, бұл үй журналдарында клиент бойынша атрибуцияны жоғалтады және бастапқы көзді күтетін қызметтерді бұзады. NAT-сыз маршруттау клиент мекенжайларын көрінетін етіп ұстайды, бірақ жоғарыдағы қайтару маршрутына тәуелді. Біреуін таңдап, DNS пен IPv6-ға дәл солай қараңыз, өйткені бұзылған IPv6 жолының қасындағы жұмыс істейтін IPv4 жолы браузерде әлі де жартылай бұзылған болып оқылады.

Барып-қайтуды тексеріңіз, содан кейін оны әдейі бұзыңыз

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 дизайнын таңдаңыз.