Saytdan saytga VPN javobi tunnel orqali o’tmaydi
Tunnelni chetlab o’tayotgan javob uzoq tomondagi marshrutlash qaroridir. Xost jadvalini, selektorlarni va rp_filterni tekshiring, so’ng marshrut yoki NAT tanlang.
Bir tongni tunnelga bag’ishladim: u toza ko’tarilib, trafikni aynan bitta yo’nalishda olib bordi — filial bosh ofisdagi fayl serveriga yetib borardi, bosh ofisdan filialga ochilgan har bir ulanish esa birinchi SYN da o’lardi. SA-lar ko’tarilgan, tunnel hisoblagichlari ortib borardi, qo’l siqish esa hech qachon muammo bo’lmagan. Javob tunnel qamramaydigan joyga marshrutlanardi, va bu tanlov uzoq tomonga tegishli. Saytdan saytga VPN faqat xost shlyuzga topshirgan paketlarni tashiydi, va har bir xost bu tanlovni alohida, har yo’nalishda, o’z marshrutlash jadvalidan amalga oshiradi.
Ikkala yo’nalish alohida marshrutlanadi
IP suhbat yo’nalishini eslab qolmaydi. Paket yuboradigan har bir xost o’zining eng uzun prefiks qidiruvini bajaradi, bitta keyingi sakrashni tanlaydi va qarorni unutadi. So’rov va javob bitta ulanishga tasodifan tegishli ikkita bog’lanmagan paketdir, tunnel esa ularning har biri ishlatishi yoki ishlatmasligi mumkin bo’lgan bitta sakrashdir. IKE almashinuvida hech narsa uzoq serverga sizning quyi tarmog’ingizga qanday yetib borishni o’rgatmaydi; muzokara faqat qaysi prefikslarni shifrlash mumkinligi to’g’risida kelishadi.
O’sha kelishuv ikkinchi darvozadir. strongSwan da trafik selektorlari leftsubnet va rightsubnet, va manbasi yoki manzili kelishilgan juftlikdan tashqariga tushadigan paket shifrlanmaydi, marshrutlash jadvali nima desa ham. Tunnelga marshrutlanadigan, lekin selektorlarda bo’lmagan prefiks — jim bir tomonlama nosozlik: marshrut to’g’ri ko’rinadi, paket baribir ochiq chiqadi yoki tashlanadi, va faqat charon jurnali shikoyat qiladi.
Uzoq xost sizning tunnellingiz haqida hech narsa bilmaydi
Uzoq LAN ichida javob sizning mijozingizga yo’naltirilgan oddiy paketdir. Manzil xosti hech qanday IPsec sarlavhasini ko’rmaydi va VPN shlyuzini afzal ko’rishga sababi yo’q; u sizning prefiksingizni qidiradi, o’z standart marshrutidan aniqroq narsa topmaydi va shunga ergashadi. Agar standart marshrut asosiy tarmoqlararo devorga ishora qilsa, devorda tunnelga qaytish marshruti bor yoki yo’q. Yo’q bo’lsa, siz jim tashlash, ICMP unreachable yoki internetga qaragan interfeysdan chiqib o’ladigan javob olasiz.
Marshrut mavjud bo’lsa ham, ikkinchi interfeys buni buzish uchun yetarli. Boshqa VLANda boshqaruv aloqasi bo’lgan NAS, zaxira uplinkli server, bitta manba oralig’ini ikkinchi jadvalga yuboradigan siyosat qoidasi: bularning har biri javobni ushlab qolishi mumkin. Linux da ip rule show va ip route show table all standart ro’yxat yashiradigan qoidalar va jadvallarni ko’rsatadi.
Qarorni javob yuborayotgan mashinada o’qing
Biron narsani o’zgartirishdan oldin yadrodan so’rang va unga manba manzilini bering, chunki manbaga bog’liq qoidalar javobni o’zgartiradi.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Chiqish chiquvchi interfeys va keyingi sakrashni nomlaydi. Agar interfeys VPN shlyuziga qaragan interfeys bo’lmasa, siz nuqsonni topdingiz, qolgan ish esa marshrut qayerda bo’lishi kerakligini tanlashdir. Shlyuzdan qilingan ping bu yerda kam narsani isbotlaydi: u uzoq xost joylashtira oladigan manzil bilan javob beradi, noutbukingiz manzili bilan emas.
Windows da ekvivalentlar qaror uchun Find-NetRoute -RemoteIPAddress 10.10.5.10 va jadval uchun Get-NetRoute. Standartdan yuqori metrikali New-NetRoute bilan qo’shilgan marshrut jim yutqazadi, shuning uchun metrika ustunini o’qing, yozuvni emas. So’ng paketlar bilan tasdiqlang: uzoq LAN interfeysida tcpdump -ni any "host 10.10.5.10 and tcp port 445" so’rovni ko’rsatadi, tunnel tomonida xuddi shu filtr javob qaytdimi-yo’qmi ko’rsatadi. So’rov ko’rinadi, javob yo’q — demak javob boshqa joyga marshrutlangan yoki tashlangan; noto’g’ri interfeysdagi javob marshrutga tegishdan oldin aybdorni beradi.
Server shlyuzi VPN ning oxirgi nuqtasi bo’lmaganda
Ko’p saytlar serverlar bilan kontsentrator orasiga tarmoqlararo devor qo’yadi. O’sha devor javobni uzatadi, shuning uchun unga mijoz prefiksi uchun VPN shlyuziga qaragan marshrut va ikki yo’nalishda uzatish siyosati kerak. Holat saqlaydigan qurilmalar ahvolni yomonlashtiradi: so’rov devordan u ruxsat bergan LAN xostidan o’tdi, javob endi boshqa yo’nalishdan keladi va ulanish kuzatuvi yozuvi endi mos kelmaydi, shuning uchun paket rad etilish o’rniga yaroqsiz deb tashlanadi. Trafik yo’qolayotganda siyosat jurnali bo’sh ko’rinishining sababi shu.
Shlyuzning o’z ikkinchi filtri bor. Linux ning teskari yo’l filtrlashi manbasi kelgan interfeys orqali yetib bo’lmaydigan paketlarni tashlaydi, va bu qonuniy assimmetrik qaytish yo’lining aynan shakli. strongSwan ning uzatish qo’llanmasi aynan shu sababdan net.ipv4.ip_forward va yumshatilgan net.ipv4.conf.all.rp_filter talab qiladi. Har qaysi shlyuzda qat’iy 1 qiymati to’g’ri marshrutni jim buzadi, va qayerga qarashni bilsangiz nstat -az tashlashlarni ko’rsatadi.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Marshrutlang yoki tarjima qiling, so’ng ikki yo’nalishda tekshiring
Ikki tuzatish teng emas. Marshrut qo’shish mijoz manzilini daxlsiz qoldiradi, shuning uchun manbaga asoslangan qoidalar, audit jurnallari va qo’ng’iroq qiluvchini qayd etuvchi ilovalar ishlashda davom etadi; narxi — qaror qabul qiladigan har bir sakrashga marshrut kerak, ya’ni xato qilish joylari ko’proq. Uzoq shlyuzda maskarad qaytish yo’lini bitta sakrashga siqadi, chunki javob endi shlyuzning o’ziga yo’naltirilgan, va qaysi mijoz nima qilganini yashiradi.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEUni ongli ravishda tanlang: mijozlar shlyuz manzili sifatida ko’rina boshlashi bilan manbaga asoslangan ACL lar ularni ajrata olmaydi, va javob tunnelga qayta yozilishi uchun conntrack moslikni ushlab turishi kerak. Agar selektorlar hali ham mijoz prefiksini chiqarib tashlasa, NAT hech narsani o’zgartirmaydi, chunki so’rov tunnelga hech qachon kirmagan.
Buni tuzatilgan deb aytishdan oldin to’rt narsani tartib bilan tasdiqlang: javob yuboradigan xostdagi marshrut, uni uzatadigan har bir sakrashdagi marshrut, ikki prefiksni qamrab oluvchi selektorlar va javob siz kutgan manba bilan tunnelga kirayotganini ko’rsatuvchi yozuv. So’ng sinovni boshqa saytdan takrorlang. Bir yo’nalishning o’tishi yarim ochiq loyihadir, ikkinchi yo’nalish esa odatda hozir tuzatganingizdan boshqa sabab bilan muvaffaqiyatsiz bo’ladi.