Masofaviy foydalanuvchilar VPN markazi orqali ikkinchi saytga yetib bormaydi

Masofaviy foydalanuvchi markazga ulanadi, markazning o'z LAN tarmog'idagi fayl serveriga yetib boradi va hammasi sog'lom ko'rinadi. Keyin u bosh ofisda 10.20.0.50 manzilidagi umumiy resursni ochadi, markaz u yerga alohida sayt-sayt tunnel orqali yetib boradi va so'rov vaqti tugaydi. Ikkala tunnel ham ishlayapti va ikkala hisoblagich ham oshib bormoqda, shuning uchun hech bir tunnel buzilmagan. Markazdan o'tish uch qurilmada uchta marshrutlash qaroridir, va tunnel faqat o'zi uchun qurilgan prefikslarni tashiydi. Men tekshiradigan tartib shu, va har bir qadam to'g'riligini ko'rsatadigan buyruq.

O'tish uchun uchta qidiruv kerak, bitta tunnel emas

Har bir qurilma o'zining eng uzun prefiks mosligini bajaradi va uni unutadi. Noutbuk 10.20.0.50 ni mahalliy marshrutizatoriga emas, tunnelga yuborishi kerak. Markaz masofaviy kirish interfeysiga kelgan paketni olib, uni sayt-sayt interfeysiga berishi kerak. Bosh ofis foydalanuvchi manziliga javobni tunnel orqali qaytarishi kerak. Uchdan birortasi muvaffaqiyatsiz bo'lsa, brauzerda bir xil ko'rinadi: sukunat.

Shuning uchun har bir tunnelni alohida sinash juda oz narsani isbotlaydi. Markazning LAN manziliga ping yuborish birinchi qarorni sinaydi, bosh ofisdan markazga ping yuborish uchinchisini sinaydi. Muvaffaqiyatsiz paketning manbasi foydalanuvchilar puli, manzili esa ikkinchi sayt, shuning uchun avval o'sha prefikslarni yozib oling. Bu yerda pul 10.80.0.0/24, markazning LAN tarmog'i 10.10.0.0/24 va bosh ofis 10.20.0.0/24.

Uzoq prefiksni masofaviy mijozga itarib yuboring

Bitta OpenVPN masofaviy kirish serverida mijoz ulanish paytida yo'nalishlarni o'rganadi. push bo'lmasa, bo'lingan tunnelli mijoz 10.20.0.50 ni o'z shlyuziga yuboradi va paket hech qachon tunnelga kirmaydi.

push "route 10.20.0.0 255.255.255.0"

Itarilgan yo'nalish mijoz ulanganda kuchga kiradi, shuning uchun onlayn qolgan foydalanuvchi qayta ulanmaguncha hech narsa ko'rmaydi. Mijozda tekshiring: Linuxda ip route get 10.20.0.50, Windowsda route print. Chiqish tunnel interfeysini nomlashi kerak.

push markazga yordam bermaydi. Bu mijozga xabar, serverdagi yo'nalish ham emas, uzatishga ruxsat ham emas, shuning uchun mukammal push qatoriga ega markaz ham bir sakrashdan keyin oqimni tashlab yuboradi. Odamlarning push muvaffaqiyatsiz bo'ldi degan xulosaga kelishining odatiy sababi shu.

Markazga haqiqiy chiqish yo'nalishini bering

Markazga bosh ofis prefiksi uchun o'zining keyingi sakrashi kerak. Marshrutlangan tunnelda bu sayt-sayt interfeysidan o'tadigan oddiy yo'nalish, va bitta buyruq tanlangan yo'nalishni ham, tanlangan manbani ham ko'rsatadi:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Sayt-sayt qismi o'zi OpenVPN bo'lsa, yo'nalish o'sha konfiguratsiyada sherikning tunnel manzilini shlyuz sifatida saqlab yashashi mumkin: route 10.20.0.0 255.255.255.0 172.30.0.2. Shlyuz ixtiyoriy emas. Uni tashlab ketsangiz, keyingi sakrash amalga oshirishning standart qiymatiga tushadi, bu bitta masofaviy mijoz va bir nechta sherikli markaz o'rtasida farq qiladi.

Siyosatga asoslangan IPsec boshqacha: markaz yadrosi paketni oddiy LAN shlyuziga yuboradi va siyosat uni chiqishda ushlaydi, shuning uchun tunnel yo'nalishi yo hech narsa qilmaydi, yo trafikni siyosat chetidan olib o'tadi. Yuqoridagi buyruqdagi manbaga e'tibor bering, chunki pul manzili o'rniga 10.10.0.1 bo'lsa, yadro uzoq tomon rad etadigan manzilni tanlagan. iroute ham javob emas; u serverga qaysi mijoz o'z tunnelining orqasidagi quyi tarmoqqa egaligini aytadi, uchinchi sayt uchun trafikni qayerga yuborishni emas.

Uzoq tomonni foydalanuvchilar puligacha kengaytiring

Bosh ofis allaqachon markazning LAN tarmog'ini, 10.10.0.0/24 ni qamrab oladi. Foydalanuvchilar puli ikkinchi prefiks va u selektorlarda ham bo'lishi kerak, aks holda 10.80.0.25 ga yuborilgan javobni hech bir siyosat qamrab olmaydi. Har bir sherik o'z tomonidan bir xil prefiks to'plamlari juftini nomlaydi:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

Bitta qurilmaning local_ts qiymati boshqasining remote_ts qiymati. Markaz blokini bosh ofisga nusxalang va juftlik teskari bo'ladi, shuning uchun bola SA hech qachon ko'tarilmaydi.

Eski ipsec.conf sintaksisi vergul bilan ajratilgan leftsubnet dan foydalanadi. Ishlab turgan xavfsizlik assotsiatsiyasi kelishilgan selektorlarni saqlaydi, shuning uchun tahrirdan keyin tunnelni qayta o'rnating. 10:00 da o'zgartirilgan selektor 09:40 da ko'tarilgan SA ga qarshi sinalsa ham muvaffaqiyatsiz bo'ladi, holbuki konfiguratsiya fayli butun vaqt davomida to'g'ri ko'rinadi.

Keyin oxirgi sakrashni tekshiring. Uzoq uchidagi ip route get 10.80.0.25 tunnelga ishora qilishi kerak. Agar xizmat LAN marshrutizatorini standart shlyuz sifatida ishlatsa, o'sha marshrutizatorga ham qaytish yo'nalishi kerak, aks holda javob o'sha yerda o'ladi. O'sha segmentda tcpdump -ni eth1 host 10.80.0.25 ni ishga tushirish javob uchidan chiqqanini ko'rsatadi.

Markazda oqimga ruxsat bering

Uzatish yoqilgan va yo'l ruxsat etilgan bo'lishi kerak. Interfeyslar orasida hamma narsani qabul qilish o'rniga qoidalarni ikkita prefiks bilan cheklang.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

Teskari yo'l filtrlash uning yonidagi sokin muvaffaqiyatsizlik: ikki oyoq turli interfeyslarda bo'lsa, rp_filter=1 javobni tashlashi mumkin, qabul qilish qoidasining hisoblagichi esa umuman qimirlamaydi. Bir urinishdan oldin va keyin iptables -vnL FORWARD ni solishtiring. Hech qachon o'smaydigan qoidaga yetib bo'lmaydi, shuning uchun uni qayta yozish o'rniga bir qatlam pastga qarang.

Agar faqat bitta guruhga o'tish kerak bo'lsa, global push ni kengaytirish o'rniga yo'nalishni client-config-dir ostidagi har bir mijoz fayliga qo'ying. Markazdagi Source NAT ham uzoq tomonning qaytish yo'nalishi zaruratini olib tashlaydi, lekin u foydalanuvchi manzilini yashiradi, shuning uchun uzoq sayt jurnallari va manzilga asoslangan qoidalar foydalanuvchilarni ajratishni to'xtatadi.

Mijozdan tekshiring, so'ng teskari tartibda orqaga qaytaring

Faqat ICMP emas, TCP portini sinang, chunki xizmat bloklangan bo'lsa ham ping o'tishi mumkin. Mijozdan nc -vz 10.20.0.50 445 va traceroute -n 10.20.0.50 ikkinchi sakrash markaz tunnel manzili ekanini ko'rsatadi. Markazda tcpdump -ni tun0 host 10.20.0.50 va sayt-sayt interfeysidagi xuddi shu filtr: ikkalasida ham so'rov, lekin hech birida javob bo'lmasa, muammo uzoq tomonga o'tadi.

Keyin bloklangan bo'lib qolishi kerak bo'lgan narsani sinang. Agar pul hech qachon yetib bormasligi kerak bo'lgan xost ham javob bersa, siz o'tishdan ko'proq ochgansiz va qoidalarni toraytirish kerak. Hamma narsani har bir shoxobchaga uzatadigan markaz birinchi sinovdan o'tadi va ikkinchisida muvaffaqiyatsiz bo'ladi.

Orqaga qaytarish ro'yxatini saqlang, chunki to'rtta obyekt o'zgardi va uchtasini unutish oson: itarilgan yo'nalish, markaz yo'nalishi, selektorlar va xavfsizlik devori qoidalari. Ularni teskari tartibda bekor qiling, SA ni qayta o'rnating va bitta foydalanuvchi qayta ulansin. Qisman orqaga qaytarish endi mos kelmaydigan tunnelga ishora qiluvchi yo'nalish qoldiradi, va uni o'qish asl sukunatdan qiyinroq. OpenVPN 2.6 qo'llanmasi sizning versiyangiz uchun push, route va iroute hujjatlashtiradi.