Bu hisobotlarning barchasi bir xil eshitiladi va turli narsani anglatadi: noutbuk manzil to'qnashuvi haqida shikoyat qiladi, lekin faqat ba'zan va ko'pincha VPN yoqilganda. Uchta alohida nosozlik bu xabarni keltirib chiqaradi: o'z ulanishingizdagi haqiqiy dublikat, masofaviy tarmoq sizning LAN diapazoningizdan foydalanadigan va hech narsa takrorlanmaydigan ustma-ust tushish, va bitta manzilni ikkita peerga bergan tunnel. Tuzatish har bir holatda farq qiladi va noto'g'risi simptomni olib tashlash o'rniga uni boshqa joyga ko'chiradi. Shuning uchun biror narsani o'zgartirishdan oldin qaysi holat ekanini aniqlang.

Bitta xato xabarini bo'lishadigan uchta nosozlik

Dublikat bir segmentdagi ikki mashina bitta manzilni talab qilishini anglatadi. Yadro buni sezadi, chunki o'z tekshiruviga javob boshqa MACdan keladi, va keyin nima bo'lishi stekka bog'liq: Linux buni jurnalga yozadi, Windows interfeysni o'chiradi va tizim jurnaliga yozuv qo'shadi, DHCP mijozi esa taklifni rad etishi mumkin.

Ustma-ust tushish hech qanday manzilni takrorlamaydi. Sizning LANingiz 192.168.1.0/24, ofis tarmog'i ham 192.168.1.0/24, va endi ofisga yo'l sizning printeringiz va NASingiz bo'lgan manzillarni ko'rsatadi. ARP ma'nosida hech narsa to'qnashmaydi; paket shunchaki ikki tarmoqdan birida noto'g'ri qurilmaga ketadi.

Hovuzdagi to'qnashuv tunnelning o'z aybi. Ikki peer bir xil tunnel manzili bilan sozlangan yoki ularga shu manzil berilgan, shuning uchun server qaytish trafigini yuborayotganda ularni ajrata olmaydi. Ikki mijozdan biri ishlaydigan handshake va hech qanday ma'lumot ko'rmaydi, bu marshrutlash muammosiga o'xshaydi, lekin unday emas.

Sinov 1: dublikat o'z segmentingizdami?

Mashinangiz aslida nima tutayotganini sanashdan boshlang, sozlaganingizni eslaganingizni emas. VPN adapterining manzili tunnel uchun xususiy va saytlar ko'radigan manzil bilan bir xil emas, shuning uchun umumiy ommaviy chiqish to'qnashuv emas.

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Windowsda xuddi shu ma'lumot ipconfig /all va Get-NetIPAddress dan olinadi, qo'shnilar keshi esa arp -a da. Agar bahsli manzil jismoniy adapterda bo'lsa va shikoyat VPN ishlamayotganda paydo bo'lsa, VPN bu yerda kuzatuvchi va uni tekshirishni to'xtatish kerak.

Taxmin qilish o'rniga dublikatni isbotlash uchun manzilni unga ega bo'lmagan qurilmadan tekshiring. arping -D tekshiruvni nol manba manzili bilan yuboradi, shuning uchun kutilmagan MACdan kelgan javob boshqa xost allaqachon bu manzil uchun javob berayotganini isbotlaydi.

sudo arping -D -I eth0 -c 3 192.168.1.50

Keyin o'zingiz boshqa manzil tanlash o'rniga tarmoq administratori orqali egasini toping. Faqat kimningdir yozuvlarida yashaydigan statik tayinlashlar, qat'iy manzilli printerlar va DHCP serveridagi rezervatsiyalar odatiy aybdorlar, o'chirilgan qurilma esa o'z ijara manziliga hali ham egalik qiladi.

Sinov 2: ikki tarmoq ustma-ust tushadimi?

Tunnel bergan prefiksni o'z interfeyslaringizdagi prefikslar bilan solishtiring. Agar masofaviy diapazon LANingizga teng bo'lsa yoki uni o'z ichiga olsa, nosozlik ustma-ust tushishdir va buni VPNsiz ochiladigan xostning yo'qolishi yoki o'z printeringizning ofis manzilida javob berishi oshkor qiladi.

ip route get 192.168.1.10
ip -br addr show

Marshrut qidiruvi yadro qaysi interfeysdan foydalanishini aytadi va bu javob butun tashxisdir. Agar mahalliy printeringizga tegishli manzil uchun tunnelni ko'rsatsa, sizda ustma-ust tushish bor va hech qanday ijara yangilash buni o'zgartirmaydi.

Uchta halol chiqish yo'li bor va odatda sizga faqat bittasi ochiq. Masofaviy tomon ustma-ust tushgan subnet uchun trafikni maskalashi mumkin, shunda mijozingiz faqat serverning tunnel manzilini ko'radi. Tunnel LANingiz bilan to'qnashmaydigan torroq masofaviy prefiksni olib yurishi mumkin. Yoki mijoz siyosat qoidalari bilan manba manzili bo'yicha marshrutlashi mumkin, bu ishlaydi, lekin nozik va uni hamkasbga topshirish qiyin.

Ofis tarmog'ini qayta raqamlash kamdan-kam sizning qaroringiz. To'qnashuvdan qochish uchun o'z LANingizni qayta raqamlash printerlar, kameralar va statik xostlar ishtirok etganda ko'pchilik kutganidan kattaroq o'zgarishdir.

Sinov 3: tunnel bitta manzilni ikki marta berdimi?

WireGuardda manzillar hovuzi yo'q. Har bir peer o'zining ommaviy kaliti va AllowedIPs dagi prefikslar bilan aniqlanadi, shuning uchun bir xil tunnel manzili ikki peer yozuviga yozilganda yoki bir xil kalit jufti ikki mashinaga o'rnatilganda dublikat paydo bo'ladi.

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

Trafik hisoblagichlari bu yerda foydali ustun: yaqinda handshake ko'rsatgan, lekin uzatish bo'lmagan peer yo noto'g'ri manzillangan, yo bir xil prefiksni talab qiluvchi boshqa yozuv tomonidan soya qilingan. Prefiksni aniq bitta peerga qo'ying va har bir qurilmaga o'z kalit juftini bering.

OpenVPN hovuzga ega va odatiy to'qnashuv qat'iy --ifconfig satrini o'z ichiga olgan umumiy mijoz profili ikkinchi mashinaga ko'chirilganda yuz beradi. Shunda ikkala mijoz ham bir xil tunnel manzilini so'raydi va server qaysi sessiyani birinchi qayta ishlasa, o'shani qabul qiladi. --duplicate-cn bilan hovuzning tugashi bitta sertifikatning bir nechta sessiyasi bitta yozuv uchun raqobatlashganda shunga o'xshash natija beradi.

Buning uchun mijoz jurnali o'rniga server jurnalini o'qing. Server qaysi sessiya qaysi manzilni egallaganini biladi va u yerda takrorlanuvchi manzillar mijozga hech qachon yetib bormaydigan ogohlantirishlar sifatida ko'rinadi.

Manbada tuzating, keyin ikkala qurilmani qayta tekshiring

Tartib muhim. Avval LANdagi dublikatni tuzating, chunki manzilni ushlab turolmagan mijoz tunnelni ham ushlab turolmaydi. Keyin VPN tomonidagi ta'minotni tuzating, chunki mijoz tomonida hovuz tayinlashiga kiritilgan o'zgartirish keyingi ulanishda bekor qilinadi. Nihoyat, takrorlangan identifikatsiyalar bilan shug'ullaning: WireGuardda alohida kalit juftlari, OpenVPNda alohida sertifikatlar yoki hech bo'lmaganda alohida profillar.

Mijozda mexanik qism qisqa. DHCP ijarasini bo'shatib yangilang yoki rezervatsiya uchun manzilni serverda o'zgartirishni so'rang. Bo'sh ko'rinadigan tasodifiy manzilni yozmang.

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

Keyin bir uchdan emas, ikki uchdan tekshiring. Shlyuzni, so'ng haqiqatan kerak bo'lgan xizmatni tasdiqlang, keyin qayta ulanib takrorlang. Agar ikki qurilma ishtirok etgan bo'lsa, ikkalasini ham tekshiring: bitta manzilni ko'chirish ikkinchisini eskirgan qo'shni yozuvlari yoki keyinroq yana paydo bo'ladigan eski ijara bilan qoldiradi.

Yo'lda nima qilmaslik kerak

Simptomni jim qilmang. Takrorlanuvchi manzillarni aniqlash sizni allaqachon ishlatilayotgan manzilni olishdan to'xtatadigan narsadir va uni o'chirish ko'rinadigan to'qnashuvni kuzatish ancha qiyin bo'lgan vaqti-vaqti bilan paket yo'qotishiga aylantiradi. Xuddi shu kutilmagan xostdan kelgan sertifikat ogohlantirishini qabul qilishga ham tegishli: bu umuman manzil muammosi emas va uni bosib o'tish boshqa nosozlikni yashiradi.

Boshqariladigan tarmoqning manzillashini ham o'zingiz o'zgartirmang. Asl sozlamani yozib oling, manzil markazlashgan tarzda tayinlanganda egasidan so'rang va o'zgartirishni qaytarish mumkin bo'ladigan darajada kichik tuting. RFC 5227 manzil to'qnashuvini aniqlash qoidalari to'g'ri tekshiruv nimani isbotlashini tushuntiradi, buni to'qnashuvni haqiqiy deb e'lon qilishdan oldin bilish foydali.

O'xshash maqolalar