Server yoki mijoz: ikki rolli Pi'da qaysi OpenVPN birligi

Bitta Pi'da bir vaqtning o'zida aylanib yuruvchi foydalanuvchilarni qabul qiladigan va yuqori provayderga yetib boradigan ikkita OpenVPN jarayoni ishlaydi va ular apparatdan boshqa deyarli hech narsani bo'lishmaydi. Biri kiruvchi tunnellarni tinglaydi, ikkinchisi tashqariga qo'ng'iroq qiladi. Har biri o'z katalogini o'qiydi va har birining o'z ishdan chiqish tartibi bor. Noto'g'ri birlikni qayta ishga tushirish — mijoz tuzatishi o'rniga tinglovchini silkitib yuborishning eng keng tarqalgan yo'li.

Birlik nomini u yuklaydigan katalog bilan moslashtiring

Upstream 2.6 ikkita shablon birligini beradi: [email protected] va [email protected]. Server shabloni /etc/openvpn/server ichida boshlanadi va u yerdan %i.conf yuklaydi. Mijoz shabloni /etc/openvpn/client ichida boshlanadi. roaming nomli nusxa bir vaqtda ikkala joyda ham mavjud bo'lishi mumkin — server va mijoz sifatida, ikkita bog'liq bo'lmagan konfiguratsiya bilan va ular o'rtasida satrdan boshqa hech qanday aloqa yo'q.

Fayl tizimidan emas, systemd'dan so'rang, chunki paket yaratuvchilar ish katalogini yoki binar oladigan argumentlarni o'zgartirishi mumkin bo'lgan qo'shimcha fayllar qo'shadi.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Birinchi buyruq har bir yaratilgan birlikni sanaydi, muvaffaqiyatsiz bo'lib yuklangan holda qolganlarini ham. Ikkinchisi birlik faylini har qanday bekor qilish bilan birga chop etadi. Uchinchisi savolni hal qiladigan ikki faktni ko'rishning eng tez yo'li: jarayon boshlanadigan katalog va unga berilgan konfiguratsiya yo'li.

Paket yo'nalishi bo'yicha qaror qiling, interfeys nomi bo'yicha emas

Server nusxasi tinglovchi soketga ega va ulanishlarni qabul qiladi. Uning shifrlangan transporti Pi'da mahalliy kirish va mahalliy chiqishdir, foydalanuvchilar uchun uzatadigan trafigi esa uzatish yo'lini kuzatadi va boshqa qoidalar to'plamiga bo'ysunadi. Mijoz nusxasining bu ma'noda tinglovchisi yo'q: u sherikka qo'ng'iroq qiladi, shuning uchun uning shifrlangan transporti pastki qatlam tomon mahalliy chiqishdir.

Bu farq qoida qayerga tegishli ekanini aytadi. Uzatish zanjiri ichidagi interfeysga mos keladigan qoida faqat marshrutlash allaqachon tanlagan trafikka ruxsat beradi; u hech qachon marshrutni tanlamaydi. Aylanib yuruvchi foydalanuvchining paketlari noto'g'ri yo'ldan chiqsa, tekshiriladigan zanjir — forward, output emas.

Nazariya qurishdan oldin soketlarga qarang. udp/1194 ga bog'langan server tinglovchi soketni ko'rsatadi. Mijoz provayder manziliga assotsiatsiyani ko'rsatadi va tinglaydigan hech narsa yo'q.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Bitta nusxaning standart marshruti boshqasining javoblarini ushlab qolishi mumkin

Yuqori mijoz itarib yuboradigan redirect-gateway mashinadagi hamma narsa bilan raqobatlashadigan standart marshrutni o'rnatadi, jumladan server aylanib yuruvchi foydalanuvchilarga yuboradigan javoblar ham. OpenVPN tunnel yetib borishli bo'lib qolishi uchun o'z sherik manziliga istisno qiladi, lekin bu istisno mehmonxona tarmog'idagi telefon haqida hech narsa demaydi.

Alomat odatda assimmetrik bo'ladi. Qo'l berib ko'rishish tugaydi, mijoz ulanganini bildiradi va birinchi javob paketidan keyin trafik o'ladi. Manbaga asoslangan siyosat marshrutlash yoki server nusxasida --mark bilan qo'yilgan paket belgisi ikki oqimni alohida ushlab turadi; ularning hech biri o'z-o'zidan to'liq qoidalar to'plami emas va ikkalasi ham tanlagan jadvalida amaldagi marshrutlarga muhtoj.

Tunnel holatini emas, mahalliy qarorni sinab ko'ring, chunki yadro OpenVPN paketni ko'rishidan oldin manba va interfeysni tanlaydi.

ip route get 203.0.113.44
ip rule show

Bitta rolni qayta ishga tushirib, ikkinchisi omon qolganini isbotlang

Ikkala rol ham bir xil pastki qatlamga bog'liq bo'lsa, tartib muhim. Agar foydalanuvchi trafigini uzatishdan oldin yuqori marshrut mavjud bo'lishi kerak bo'lsa, avval mijozni qayta ishga tushiring, agar faqat uning tinglovchisi yoki hovuzini o'zgartirayotgan bo'lsangiz, avval serverni qayta ishga tushiring. Qanday bo'lsa ham keyin ikkala birlikni tasdiqlang, chunki muvaffaqiyatsiz qayta ishga tushirish boshqa rolni eskirgan holat bilan ishlashda qoldirishi mumkin.

O'zgartirishdan oldin to'xtash shartini yozib qo'ying: yuqori tunnel yo'qolishi aylanib yuruvchi foydalanuvchilarni to'sadimi yoki Pi'ning o'z yuqori kanaliga qaytadimi? DNS va IPv6 ham aniq javobga muhtoj, chunki itarilgan hal qiluvchi ko'pincha uni foydali qilgan marshrutdan uzoqroq yashaydi.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

O'zgartirishni faqat uchta narsa bir vaqtda to'g'ri bo'lganda qabul qiling: yangi kiruvchi ulanish tugaydi, uzatilgan ilova mo'ljallangan chiqish orqali manziliga yetadi va ikkala jarayon ham o'z kutgan sherikini bildiradi. Uchtadan biri muvaffaqiyatsiz bo'lsa, siz noto'g'ri nusxani yoki noto'g'ri marshrutni o'zgartirdingiz va keyingi qadam boshqa narsani qayta ishga tushirish emas, birlikni qayta o'qishdir.