LAN serveridagi VPN mijozi: javoblar nima uchun noto'g'ri yo'ldan chiqadi

Belgilar bitta shaklga amal qiladi: xost ishlaydi, keyin u mijoz sifatida VPN ga ulanadi va endi LAN mijozlari unga yetib boradi, javoblari esa yo'qoladi. Xostdagi ushlash javoblar LAN interfeysi o'rniga tunnel qurilmasi orqali chiqishini ko'rsatadi. Tunnelda hech narsa buzilmagan va tuzatish marshrut, qayta ulanish emas. Quyidagi to'rt tekshiruvni tartib bilan bajaring va birinchi muvaffaqiyatsiz bo'lganida to'xtang.

Javob yangi paket, yo'lning teskari harakati emas

Javob so'rov ketgan yo'l bilan qaytadi degan fikrdan voz kechish foydali. Marshrutlash har bir paket va har bir yo'nalish uchun jo'natuvchi xostda hal qilinadi. Tunnel ichida 10.64.0.23 manzilidan kelgan so'rov qaytish yo'lini yaratmaydi; xost javob berganida bu javob yangi paket sifatida jadval bilan solishtiriladi va qaysi marshrut yutsa, o'sha orqali chiqadi.

Shuning uchun LAN ga ham xizmat qiladigan mashinada to'liq tunnel mijozi shunday chalkash nosozlik keltirib chiqaradi. Mijoz standart marshrutni yoki ba'zi mijozlar afzal ko'radigan ikkita yarim standart marshrutni o'rnatadi va LAN mijoziga javob endi tunnelga mos keladi. U provayderga ketadi, uning uni uzatishga sababi yo'q, LAN mijozi esa xost ishlab, mahalliy javob berayotgan bo'lsa ham vaqt tugashini ko'radi. Ushlash buni yaqqol ko'rsatadi, marshrut jadvali esa izohlaydi.

Qolganini o'qiyotganda ikki kichik tarmoqni yodda tuting. Biri uzoq mijozlar keladigan VPN manzil hovuzi, bu misolda 10.64.0.0/24. Ikkinchisi ishlashda davom etishi kerak bo'lgan LAN, 172.16.24.0/24, marshrutizatori 172.16.24.1 da. Xato shundaki, ular orasidagi trafikni standart marshrut hal qiladi.

Buni ushlash va qidiruv bilan isbotlang

Biror narsani o'zgartirishdan oldin javob qaysi qurilmadan foydalanishini tasdiqlang. Qidiruv ushlashdan tezroq va paket qurilayotganda yadro javob beradigan aynan o'sha savolga javob beradi.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Javobni ikki qismda o'qing. Agar u dev tun0 ni aytsa, xost javobni inkapsulyatsiya qilib provayderga beradi va LAN mijozi uni hech qachon ko'rmaydi. Agar u dev eth0 ni aytsa, lekin mijoz hali ham vaqt tugashini olsa, marshrut allaqachon to'g'ri va paket keyinroq tashlanadi, bu boshqa muammo va boshqa tuzatish.

O'sha qadamdagi ushlash ping hal qila olmaydigan shubhani hal qiladi. LAN mijoziga yetib boradigan aks-sado javobi qandaydir yo'l ishlayotganini isbotlaydi, uni qaysi interfeys olib o'tganini emas, shuning uchun ushlashni xostning o'zida o'tkazing va kadrlar qayerdan chiqishini kuzating. O'sha kichik tarmoqdagi printer javob berishda davom etadi, chunki uning to'g'ridan-to'g'ri marshruti tunnelning standartidan aniqroq. Yo'naltirilgan port boshqa har qanday oqim kabi muvaffaqiyatsiz bo'ladi, chunki interfeysni jadval tanlaydi, ulanish emas.

Tunneldan ustun turadigan eng tor marshrutni o'rnating

Prefiks uzunligi hal qiladi, metrika emas, shuning uchun LAN marshrutizatori orqali mijoz hovuzi marshruti VPN mijozi o'rnatadigan har qanday standartdan ustun. Metrika jarrohligi kerak emas va standart mijoz qo'ygan joyda qolishi mumkin.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Ikkinchi add o'rniga replace ishlating, chunki qayta ulanadigan mijoz o'z yozuvini o'rnatib bo'lgan bo'ladi va ikkinchi add ruxsat muammosiga o'xshab o'qiladigan mavjud marshrut xatosi bilan muvaffaqiyatsiz bo'ladi. Windows xostida ekvivalenti route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, bu yerda -p yozuvni qayta yuklashlar orasida saqlaydi, chunki tunnel yana ko'tarilganda mijoz jadvalni qayta qurishi mumkin. Zamonaviy Windows xostida qo'llab-quvvatlanadigan ekvivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, eski route buyrug'i esa eski shakl sifatida saqlanadi.

Bir tafsilot bu to'g'ri yoki shunchaki ishonchli ekanini hal qiladi: keyingi sakrash mijozlarga qaytish yo'liga haqiqatan ega bo'lgan marshrutizator bo'lishi kerak. Marshrutni o'zi tunnel orqali yetib boriladigan manzilga yo'naltirish toza nosozlik o'rniga uzilib-uzilib yo'qotish sifatida ko'rinadigan halqa yaratadi. Qatorni tasdiqlashdan oldin keyingi sakrash LAN kichik tarmog'ida ekanini tekshiring.

Qayta ulangandan keyin ham javobni saqlang

Qo'lda qo'shilgan marshrut eng yaxshi holatda keyingi qayta ulanishgacha yashaydi. Agar mijoz hovuzi dinamik bo'lsa, uni server konfiguratsiyasida mahkamlang, shunda siz marshrutlagan prefiks mijozlar oladigan prefiks bo'lib qoladi; aks holda yozuv bo'sh diapazonga ishora qiladi va belgi haftalar o'tib aniq sababsiz qaytadi. Marshrutni mijozning o'z up-skriptiga yozish boshqa ishonchli variant, chunki u mijoz jadvalni qayta yozgandan keyin ishlaydi.

Holatli xavfsizlik devori to'g'ri marshrutni baribir yengishi mumkin. Agar ushlash endi javob eth0 orqali chiqishini ko'rsatsa va mijoz hali ham vaqt tugashini olsa, xost paketni jo'natishdan oldin tashlayaptimi-yo'qmi tekshiring. Qat'iy teskari yo'l filtrlash va net.ipv4.conf.all.rp_filter ni 1 ga qo'yish manbasi qaysi interfeysdan kelgan bo'lsa, o'sha orqali qayta marshrutlanmaydigan paketlarni tashlaydi va bu siz hozir yaratib, keyin tuzatgan asimmetrik holatning o'zi, conntrack holati esa yo'naltirilgan portlar uchun ham xuddi shu voqeani aytadi.

Oxirgi tekshiruv odamlar o'tkazib yuboradigan tekshiruv: tunnel pastga tushib, yana ko'tarilgandan keyin qidiruvni takrorlang. To'rt qiymat siz yozgan bilan mos kelishi kerak: manzil, keyingi sakrash, qurilma va tanlangan manba. Agar ulardan biri siljigan bo'lsa, mijoz jadvalni qayta yozgan va tuzatish uning ilgaklarida, shell tarixida emas.