OpenBSD VPN shlyuzida tun0 orqali LAN uchun NAT

Bir xil OpenBSD shlyuziga ega ikki injener sizga uzoq tarmoqqa yetish uchun ko'pincha ikki xil qoidalar to'plamini beradi va ikkalasini ham himoya qilish mumkin. Manba tarjimasi bilan qaytish marshruti o'rtasidagi tanlov umuman sintaksis masalasi emas. Hammasi qarshi tomon 192.168.88.0/24 haqida allaqachon nima bilishiga va jurnallaringizda nimani saqlashingiz kerakligiga bog'liq. Bu yerda xato qilsangiz, nat-to satri mukammal to'g'ri ko'rinadi, javoblar esa uzoqdagi standart shlyuzda yo'qoladi.

Marshrutlash va qayta yozish turli savollarga javob beradi

Marshrutlash jadvali 172.20.0.0/16 ga tun0 orqali yetish mumkinligini hal qiladi va bu qaror har qanday pf tarjimasi so'ralishidan oldin qabul qilinadi. So'ng manba tarjimasi paket sarlavhasini o'zgartiradi, shunda uzoq tomon LAN xosti o'rniga shlyuzning tunnel manzilini ko'radi. Hech bir mexanizm ikkinchisini almashtirmaydi: nat qoidasi marshrut yarata olmaydi, marshrut esa sizning shaxsiy quyi tarmog'ingiz haqida hech eshitmagan uzoq marshrutizatorni ishontira olmaydi. Qarshi tomonda qaytish yo'li bo'lmasa, javoblar tashlab yuboriladi yoki uning standart shlyuziga yo'naltiriladi va qoidalarni qanchalik sozlasangiz ham bu tuzalmaydi.

Sodda qilib aytganda, uzatish trafik qayerga ketishiga javob beradi, tarjima esa u qayerdan kelayotgandek ko'rinishiga javob beradi. Qoidalar to'plamini loyihalashda ikkalasini alohida fikriy qutilarda saqlang.

Hal qiluvchi uch shart

Uch savolni tartib bilan bering, loyiha odatda o'zi tanlanadi. Uzoq tarmoqda 192.168.88.0/24 uchun tunnel manziliga ishora qiluvchi statik marshrut bormi yoki uning administratori o'sha yo'ldagi marshrutizatorlarni boshqaradimi? Agar ha bo'lsa, LAN manzillarini o'zgartirmasdan o'tkazing va tarjimani butunlay tashlab ketting. Qarshi tomonda har bir mijozni ko'rish kerakmi, kirish siyosati uchun ham, audit izi uchun ham? Agar kerak bo'lsa, manbani saqlash marshrutlash mehnatiga arziydi. Tunnel manzili uzoq marshrutga yozish uchun yetarlicha barqarormi yoki qayta ulanishlar orasida o'zgaradimi?

Agar biron javob yo'q yoki noma'lum bo'lsa, nat-to amaliy variantdir va u qaytariladigan ham. Qarshi tomon munosib marshrut qo'shishi bilan tarjima qoidasi bir satrda chiqib ketadi. Hech qachon o'rnatilmagan qaytish marshruti tunnel nima uchun faqat bir yo'nalishda ishlaydi deb kimdir so'ragan har safar sizga bitta qo'llab-quvvatlash tarmog'ini sarflaydi.

Parchani pf haqiqatan baholaydigan joyga qo'ying

Quyidagi parcha LAN 192.168.88.0/24, uzoq tarmoq 172.20.0.0/16 va tunnel interfeysi tun0 deb hisoblaydi. Unda keyingi sakrashni tanlaydigan hech narsa yo'q. U faqat tunnel orqali chiqib ketayotgan paketlarda manbani qayta yozadi.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

O'sha birinchi satrdagi ikki tafsilot eng katta yukni ko'taradi. tun0 atrofidagi qavslar pf ga har safar holat yozuvini qurishda interfeys manzilini o'qishni aytadi, bu qayta ulanishdan keyin tunnel qayta raqamlansa muhim. match so'zi qoida qayta yozib, keyin pastga tushishini bildiradi, shuning uchun alohida pass qoidasi oqimni baribir o'tkazishi kerak. match satrida nomlangan interfeys ham marshrutlash jadvali tanlaydigan interfeys bo'lishi kerak, aks holda pf qoidani paket haqiqatan bosib o'tadigan yo'ldan boshqa chiqish yo'lida baholaydi.

Yadro tomonini unutmang. IPv4 uzatish yoqilgan bo'lishi kerak, tunnel va LAN uchun holatli pass qoidalari esa bularning barchasi mazmun kasb etishidan oldin mavjud bo'lishi kerak. Bu yerda kalit so'zlar tartibi uchun OpenBSD FAQ dagi PF NAT bo'limi to'g'ri havola.

Trafikka ishonishdan oldin qoidalar to'plamini tekshiring

Avval sintaksisni pfctl -nf /etc/pf.conf bilan tekshiring, u faylni yuklamasdan tahlil qiladi. So'ng siyosatni yuklang va yadro haqiqatan nimani saqlayotganini qayta o'qing, chunki toza tahlil qilingan qoida ham soyada qolishi yoki noto'g'ri interfeysga bog'lanishi mumkin. pfctl -sn tarjima qoidalarini yuklangan shaklda chiqaradi, pfctl -sr esa filtr qoidalarini baholash tartibida chiqaradi.

So'ng simni kuzating. Shlyuzda tcpdump -ni tun0 'host 172.20.0.10' tunneldan chiqayotgan manba manzil tunnel manzilimi yoki LAN xostimi ekanini ko'rsatadi. Tez netstat -rn -f inet manzil qaysi interfeysga yechilishini tasdiqlaydi. Trafik oqa boshlagach pfctl -ss holat yozuvlarini sanab chiqadi; agar oqim holat yaratmagan bo'lsa, paket uni yaratadigan qoidaga hech qachon duch kelmagan.

Agar tunnel tomoni to'g'ri ko'rinsa-yu javoblar baribir kelmasa, pf ni tahrirlashni to'xtating. Qolgan nosozlik uzoq marshrutizatorda, u yerda javob o'sha tomon yeta olmaydigan shaxsiy manzilga yuborilmoqda.

Tarjima tejaganidan qimmatga tushganda

Tarjima mijozlarni yashiradi va ba'zan bu aynan noto'g'ri almashinuv. Bir-biriga qoplanadigan quyi tarmoqlar bir holat: agar qarshi tomon ichkarida ham 192.168.88.0/24 dan foydalansa, LAN xostlarini shlyuz sifatida ko'rsatish to'qnashuvni yaxshilash o'rniga yanada yomonlashtiradi. Trafikni manzil jufti bo'yicha tanlaydigan IPsec siyosatlari boshqa holat, chunki xavfsizlik siyosati ma'lumotlar bazasi tarjimadan oldin solishtiriladi va qayta yozilgan paketingizni hech qachon ko'rmaydi. Har bir foydalanuvchi bo'yicha hisob-kitob qiladigan, cheklaydigan yoki audit qiladigan har qanday joriy etish ham manba bitta manzilga qisqargan paytda kerakli shaxsni yo'qotadi.

Ko'chma pf hosilalari alohida tuzoq. O'z qoida fayllarini yaratadigan mahsulotlar NAT ularning interfeysi orqali sozlanishini kutadi va qo'lda tahrirlangan parchalar keyingi qayta yuklashda ustidan yoziladi. match kalit so'zi paydo bo'lishidan oldin yozilgan qo'llanmalardan ko'chirilgan qoidalar to'plami joriy yadroda yuklanmaydi, shuning uchun sintaksisni ko'chiring va taxmin qilish o'rniga xatoni o'qing.

Haqiqiy tarmoqlar bilan aloqada omon qoladigan qaror qoidasi qisqa: imkoni bo'lsa qaytish marshrutini o'rnating, imkoni bo'lmasa tarjima qiling va uch shartdan qaysi biri sizni shu tanlovga undaganini yozib qo'ying. O'sha eslatma keyingi odamning yarim kunini tejaydi.