Bitta Pi'da hostapd va OpenVPN: standart marshrut kimniki?

Telefonlar kirish nuqtasiga ulanadi, manzil oladi va tunnel ko'tarilishi bilan hech qayerga yetib bormaydi. hostapd bu holatda odatda sog'lom, OpenVPN ham shunday; buziladigan narsa standart marshrut bo'lib, u yo ko'prikda hech qachon bo'lmagan, yo tunnel uni VPN serverining o'ziga yo'l qoldirmasdan almashtirgan. Ushbu qo'llanma o'sha marshrutni o'z joyiga qaytaradi va natijani Pi'dan emas, mijozdan isbotlaydi. Har bir qadam qaytariladi va bu yerda hech narsa tunnel konfiguratsiyasini o'zgartirmaydi, uning ichida qanday trafik kerakligini bilmaguningizcha.

Biror narsani tahrirlashdan oldin interfeyslarni sanab chiqing

Odatiy tartib simsiz radio va simli portni br0 ichiga joylashtiradi, hostapd'ni ko'prikka qarshi ishga tushiradi va dnsmasq'dan ijara tarqatadi, OpenVPN mijozi esa tun0 yaratadi. Shunda uchta alohida talab bitta bo'lib ko'rinadi: kirish nuqtasi mijozlariga shlyuz sifatida Pi kerak, Pi'ga o'z serveriga yetish uchun internetga marshrut kerak, ko'prikka esa o'sha mijozlar ishlata oladigan shlyuz manzili kerak.

O'zgartirishdan oldin joriy holatni o'qing, chunki bu to'rt buyruq interfeys muammosini marshrutlash muammosidan ajratadi.

ip -br addr
ip route show
ip link show master br0
bridge link show

Agar br0 manzilga ega bo'lsa, lekin standart marshruti bo'lmasa, mijozlar Pi'gacha yetib boradi va undan nariga o'tmaydi. Agar tunnel past bo'lganda standart marshrut tun0'ga ishora qilsa, Pi'da umuman ishlaydigan yo'l yo'q, mijoz belgisi esa xuddi shunday ko'rinadi. Ikkala holat ham telefondan bir xil ko'rinadi, shuning uchun marshrut jadvalini to'g'ridan-to'g'ri o'qish kerak.

Ko'prikka o'ziga tegishli standart marshrut bering

Raspberry Pi OS ko'prikni ko'pincha standart marshrutsiz qoldiradi, agar ko'prik interfeys fayli yozilgandan keyin paydo bo'lgan bo'lsa. Blok /etc/dhcpcd.conf ichida bo'lishi kerak va u Pi'ni emas, yuqori router'ni nomlashi kerak.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

O'sha misolda 192.168.50.1 mavjud router va 192.168.50.2 o'sha subnetdagi Pi ko'prigining manzili, shuning uchun raqamlarni nusxalash o'rniga o'z rejangizni qo'ying. Ko'prik a'zolari ham router so'ramasligi kerak, aks holda Pi'da raqobatlashuvchi standart marshrutlar qoladi, ularning g'olibi niyatga emas, metrika va vaqtga bog'liq.

systemctl restart dhcpcd dan keyin ip route show default br0 ni bir marta ko'rsatishi va simli portdan takror bo'lmasligi kerak. Jadvalni emas, qidiruvni tasdiqlang, chunki eski yozuv g'olib yozuv yonida o'tirishi mumkin: ip -4 route get 203.0.113.10 br0 ni nomlashi kerak. Bu manzil TEST-NET-3 hujjat diapazonidan, shuning uchun buni o'qiyotganingizda u haqiqiy server bilan to'qnasha olmaydi.

Tunnel o'z serveriga boradigan yo'lni o'g'irlashiga yo'l qo'ymang

redirect-gateway ni qabul qiladigan OpenVPN mijozi standart marshrutni oladi va uni tunnelga yo'naltiradi. Bu har bir kirish nuqtasi mijozi VPN ishlatishi kerak bo'lganda to'g'ri, faqat ba'zi manzillar ishlatishi kerak bo'lganda noto'g'ri. Qanday bo'lmasin, Pi'ning server bilan o'z aloqasi hali qurilayotgan tunnel ichidan o'tmasligi kerak. OpenVPN standart marshrutni qayta yo'naltirganda asl shlyuz orqali uzoqqa xost marshrutini qo'shadi va aynan shu xatti-harakat transportni tirik saqlaydi; agar bu marshrut bo'lmasa, tunnel o'rnatilishi bilan qulaydi.

O'sha transport yo'lini ulanishdan oldin va keyin tez solishtirish o'sha o'n soniyaga arziydi. ip -4 route get 203.0.113.10 ikkala holatda ham pastki qatlam qurilmasini nomlashi kerak, faqat metrika o'zgaradi. Agar tunnel ko'tarilgandan keyin u tun0 ni nomlasa, xost marshruti hech qachon o'rnatilmagan va keyingi qayta ulanish muvaffaqiyatsiz bo'ladi.

Tunnel orqali faqat tanlangan prefikslar o'tishi kerak bo'lsa, route-nopull dan foydalaning va kerakli marshrutlarni qo'lda qo'shing yoki serverdan torroq to'plam yuboring. Bu dizaynda ko'prik standart marshrutni saqlaydi, DNS esa keyingi qaror bo'ladi: dnsmasq'ni uy rezolveriga yo'naltirish faqat u yerda haqiqatan yashaydigan nomlar uchun mantiqiy.

Yo'naltirish va NAT masalasini hal qiling

To'liq tunnel Pi'da yoqilgan yo'naltirishni va uzoq tomonda kirish nuqtasi subnetini marshrutlashga tayyor shlyuzni talab qiladi. Yo'naltirishni hamma narsadan oldin tekshiring, chunki nol har qanday marshrut o'zgarishini ahamiyatsiz qiladi.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT qoidasi server kirish nuqtasi prefiksini qabul qilmaganda ishlaydigan qisqa yo'l, ammo uning narxi uzoq tomon jurnallarida har bir mijoz Pi'ning tunnel manzili sifatida ko'rinishi. Prefiksni NAT'siz marshrutlash manzillarni ko'rinadigan saqlaydi va uy tomonida 192.168.50.0/24 uchun qaytish marshrutiga bog'liq.

Tanlovni firewall qoidalari yoniga yozib qo'ying, chunki dizaynda ko'rinmaydigan NAT qoidasi olti oydan keyin tushuntirib bo'lmaydigan bo'lib qoladi. IPv6 ni ham shu qarorda saqlang; buzilgan IPv6 yo'li yonidagi ishlaydigan IPv4 yo'li brauzerda hali ham yarim buzilgan deb o'qiladi.

Mijozdan tekshiring, so'ng toza qaytaring

Kirish nuqtasidagi telefon yoki noutbukdan shu tartibda sinab ko'ring: dnsmasq'dan ijara, ko'prik manziliga ping, so'ng tunnelning uzoq tomonidagi manzil. Har bir qadam bitta qatlamni ajratadi, bitta foydasiz muvaffaqiyatsizlik chiqarish o'rniga.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

So'ng Pi'ning hali ham o'z chiqish yo'li borligini tasdiqlang: ip route get 203.0.113.10 pastki qatlam qurilmasini nomlashi kerak, server ICMP ga ruxsat bersa ping -c 3 -I br0 203.0.113.10 javob berishi kerak. Agar mijozning birinchi ikki qadami o'tsa va uchinchisi muvaffaqiyatsiz bo'lsa, xato yo'naltirishda yoki NAT da. Agar ikkinchi qadam muvaffaqiyatsiz bo'lsa, ko'prik yoki DHCP hali to'liq emas.

Qaytarish — bitta fayl tahriri va ikkita buyruq: blokni olib tashlang, dhcpcd'ni qayta ishga tushiring va standart marshrutni aniq ip route replace default via 192.168.50.1 dev br0 bilan almashtiring. Buni texnik xizmat oynasi yopilishidan oldin qiling, keyin emas, chunki standart marshrutini yo'qotgan Pi uni tuzatish uchun ishlatadigan tarmoqdan yetib bo'lmaydi.