Noutbuingiz VPN orqali pfSense LAN'iga yetib boradi, ammo yana ikki hop chuqurroqdagi xizmatga yetib bora olmaydi, farq esa har bir egasi uchun bitta marshrutlash qarori. Paket o'zining borib-kelish sayohatini yakunlashidan oldin uchta qurilma kelishishi kerak: mijoz, xavfsizlik devori va maqsad tarmog'iga haqiqatan egalik qiluvchi router. Ulardan birini o'tkazib yuborsangiz, alomat bir xil ko'rinadi.

Qoidani o'zgartirishdan oldin bitta paketni shu uch qaror orqali kuzatib chiqing, chunki har bir egasining boshqaruvi ham, nosozlik usuli ham boshqacha.

Bitta paket, uchta marshrutlash qarori

Mijoz maqsad tunnelga tegishli yoki yo'qligini hal qiladi va faqat bilgan narsasiga tayanib hal qila oladi: itarib yuborilgan marshrut, mahalliy marshrut yoki allaqachon hammasini qamrab olgan standart marshrut. pfSense paketni keyin qayerga yuborishni hal qiladi, bu esa boshqa router ortidagi tarmoq uchun to'g'ri interfeysdagi yetib boriladigan shlyuz orqali statik marshrutni bildiradi. Pastki router VPN hovuziga qaytish yo'lini biladimi-yo'qmi hal qiladi, bilmasa javob tashlab yuboriladi yoki foydasiz joyga yuboriladi. Har bir qaror qolgan ikkitasidan mustaqil.

Ulardan birortasining nosozligi bir xil foydalanuvchi hisobotini beradi. Shuning uchun nosozlikni tuzatish tartibi asboblardan muhimroq.

Mijozga prefiks bering, taxmin emas

IPv4 tunnel tarmog'i /30 dan katta bo'lgan pfSense SSL/TLS serverida IPv4 Local network(s) maydoni ulanganda mijozlarga marshrutlarni tarqatadi. Mijoz o'zi bittasini o'ylab topadi deb ishonish o'rniga pastki prefiksni o'sha yerga qo'shing. So'ngra ulangandan keyin mijozning haqiqiy jadvalini o'qing, chunki route-nopull bo'lgan profil yoki marshrut filtri server yuborgan narsani e'tiborsiz qoldirishi mumkin. Server butunlay to'g'ri bo'lishi mumkin, mijoz esa hech narsa o'rnatmaydi.

Boshqa server rejimlari va topologiyalarning chegaralari boshqacha, har bir mijoz yoki ulanish siyosati muayyan mijoz nima olishini o'zgartirishi mumkin. Avval tasodifan sinab ko'rgan mijozda emas, muhim mijozda tekshiring.

pfSense'ni ichki routerga qarating

pfSense'dagi statik marshrutga aniqlangan va yetib boriladigan shlyuz kerak, o'sha shlyuz uchun tanlangan interfeys esa haqiqatan unga yetib boradigan interfeys bo'lishi kerak, Netgate'ning statik marshrutlar bo'yicha qo'llanmasi shunday tushuntiradi. Illyustrativ joylashuvda tranzit bog'lanish xavfsizlik devorida 192.168.77.1 va ichki routerda 192.168.77.2, xizmat tarmog'i esa uning orqasida 172.16.30.0/25. Keyin marshrut prefiks va keyingi hopni nomlaydi, xizmat manzilini emas. Uzoq tarmoqdan manzilni shlyuz sifatida ishlatish to'g'ri ko'rinadigan, lekin hech qayerga yo'naltirmaydigan marshrut qurishning keng tarqalgan usuli.

Interfeysga nom berish uning orqasidagi tarmoqlarni tavsiflamaydi. Statik marshrut o'sha tavsifdir.

Uzoq tomon hovuzni bilishi kerak

Pastki routerga hovuz uchun qaytish marshruti kerak, bu misolda 192.168.77.1 orqali 10.55.0.0/24, agar standart marshrut yoki dinamik protokol allaqachon bittasini bermasa. Xizmat hostining o'z shlyuzi o'sha routerga qarab borishi kerak, bu odatda router uning standart shlyuzi bo'lganda to'g'ri va host qo'lda sozlanganda noto'g'ri. Xavfsizlik devoridagi siyosat marshrutlash ham muayyan trafik uchun jadvalni chetlab o'tishi mumkin, shuning uchun marshrut noto'g'ri degan xulosaga kelishdan oldin biron qoida boshqa shlyuz tanlaydimi-yo'qmi tekshiring.

Bu dizayn uchun tarjima talab qilinmaydi va mijozning manba manzilini ko'rinadigan qoldirish pastki tarmoqqa o'z siyosatini qo'llash imkonini beradi.

Qabul uchun bitta yangi so'rovni tunnel kirishidan, xavfsizlik devorining ichki chiqishidan va maqsaddan kelgan javobdan o'tkazing. Agar buning o'rniga tarjima ataylab ishlatilsa, pastki tarmoq qaysi manbani ko'rishini va javob qanday qaytishi kutilishini yozib qo'ying.

Uch egasining rejasini ruxsat etilgan ilova bilan birga saqlang, shunda keyingi administrator yo'lni qaytadan kashf qilish o'rniga uni qayta qurishi mumkin.

O'xshash maqolalar