Տեղական IP հասցեի բախման շտկում VPN-ին միանալուց հետո

Այս զեկույցներից յուրաքանչյուրը նույն ձայնն ունի և տարբեր բան է նշանակում: նոթբուքը բողոքում է հասցեների բախումից, բայց միայն երբեմն, և հիմնականում այն ժամանակ, երբ VPN-ը միացված է։ Երեք առանձին խնդիր արտադրում են այդ հաղորդագրությունը: իրական կրկնօրինակ ձեր սեփական կապուղում, համընկնում, երբ հեռավոր ցանցն օգտագործում է ձեր LAN միջակայքը և ոչինչ չի կրկնօրինակվում, և թունել, որը մեկ հասցե տվեց երկու գործընկերների։ Ուղղումը տարբեր է յուրաքանչյուր դեպքում, և սխալը տեղափոխում է ախտանիշը՝ փոխարենը հեռացնելու։ Ուստի որոշեք, թե որ դեպքն ունեք, նախքան որևէ բան խմբագրելը։

Երեք խնդիր մեկ սխալի հաղորդագրությամբ

Կրկնօրինակ նշանակում է, որ նույն սեգմենտի երկու մեքենաներ երկուսն էլ պահանջում են մեկ հասցե։ Միջուկը նկատում է դա, որովհետև իր սեփական ստուգման պատասխանը գալիս է այլ MAC-ից, և թե ինչ է լինելու հետո, կախված է կույտից: Linux-ը գրանցում է այն, Windows-ը անջատում է ինտերֆեյսը և գրառում կատարում համակարգի մատյանում, իսկ DHCP հաճախորդը կարող է մերժել առաջարկը։

Համընկնումը ոչ մի հասցե չի կրկնօրինակում։ Ձեր LAN-ը 192.168.1.0/24 է, գրասենյակի ցանցը նույնպես 192.168.1.0/24 է, և այժմ դեպի գրասենյակ տանող ուղին մատնանշում է հասցեներ, որոնք նաև ձեր տպիչը և ձեր NAS-ն են։ ARP իմաստով ոչինչ բախման մեջ չէ: փաթեթը պարզապես գնում է սխալ սարքին երկու ցանցերից մեկում։

Լողավազանում բախումը հենց թունելի սխալն է։ Երկու գործընկերներ կարգավորվել են նույն թունելի հասցեով կամ ստացել են այն, ուստի սերվերը չի կարող տարբերել նրանց, երբ ուղարկում է վերադարձի տրաֆիկ։ Երկու հաճախորդներից մեկը տեսնում է աշխատող ձեռքսեղմում և ոչ մի տվյալ, ինչը կարդացվում է որպես երթուղավորման խնդիր և այդպիսին չէ։

Փորձարկում 1: կրկնօրինակը ձեր սեփական սեգմենտո՞ւմ է

Սկսեք թվարկելով, թե ինչ իրականում ունի ձեր մեքենան, ոչ թե ինչ եք հիշում, որ կարգավորել եք։ VPN ադապտերի հասցեն մասնավոր է թունելի համար և նույնը չէ, ինչ տեսնում են կայքերը, ուստի ընդհանուր հանրային ելքը բախում չէ։

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

Windows-ում նույն տեղեկությունը գալիս է ipconfig /all-ից և Get-NetIPAddress-ից, իսկ հարևանների քեշը գտնվում է arp -a-ում։ Եթե վիճելի հասցեն ֆիզիկական ադապտերի վրա է, և բողոքը հայտնվում է առանց VPN-ի աշխատելու, ապա VPN-ը դիտորդ է, և դուք պետք է դադարեցնեք այն ախտորոշելը։

Կրկնօրինակն ապացուցելու համար՝ գուշակելու փոխարեն, ստուգեք հասցեն այն սարքից, որը չի տիրապետում դրան։ arping -D-ը ստուգումն ուղարկում է զրոյական աղբյուրի հասցեով, ուստի անսպասելի MAC-ից պատասխանը ապացուցում է, որ մեկ այլ հոսթ արդեն պատասխանում է այդ հասցեին։

sudo arping -D -I eth0 -c 3 192.168.1.50

Այնուհետև գտեք սեփականատիրոջը ցանցի ադմինիստրատորի միջոցով՝ ինքներդ այլ հասցե ընտրելու փոխարեն։ Միայն ինչ-որ մեկի նշումներում ապրող ստատիկ նշանակումները, հաստատուն հասցեով տպիչները և DHCP սերվերի արգելոցները սովորական մեղավորներն են, և անջատված սարքը դեռ տիրապետում է իր վարձակալությանը։

Փորձարկում 2: երկու ցանցերը համընկնու՞մ են

Համեմատեք թունելի տված նախածանցը ձեր ինտերֆեյսների նախածանցերի հետ։ Եթե հեռավոր միջակայքը հավասար է ձեր LAN-ին կամ պարունակում է այն, խնդիրը համընկնում է, և հուշումն այն է, որ առանց VPN-ի հասանելի հոսթը մարում է, կամ ձեր տպիչը պատասխանում է գրասենյակի հասցեով։

ip route get 192.168.1.10
ip -br addr show

Երթուղու որոնումը ձեզ ասում է, թե որ ինտերֆեյսը կօգտագործեր միջուկը, և այդ պատասխանը ողջ ախտորոշումն է։ Եթե այն թունելն է նշում ձեր տեղական տպիչին պատկանող հասցեի համար, ապա համընկնում ունեք, և ոչ մի վարձակալության նորացում դա չի փոխի։

Ելքի երեք ազնիվ ուղի կա, և սովորաբար ձեզ հասանելի է միայն մեկը։ Հեռավոր կողմը կարող է քողարկել համընկնող ենթացանցի տրաֆիկը, այնպես որ ձեր հաճախորդը տեսնում է միայն սերվերի թունելի հասցեն։ Թունելը կարող է կրել ավելի նեղ հեռավոր նախածանց, որը չի բախվում ձեր LAN-ի հետ։ Կամ հաճախորդը կարող է երթուղավորել ըստ աղբյուրի հասցեի՝ քաղաքականության կանոններով, ինչը աշխատում է, բայց փխրուն է և դժվար փոխանցել գործընկերոջը։

Գրասենյակի ցանցի վերահամարակալումը հազվադեպ է ձեր որոշումը։ Սեփական LAN-ի վերահամարակալումը բախումից խուսափելու համար ավելի մեծ փոփոխություն է, քան մարդկանց մեծ մասը սպասում է, հենց որ տպիչներ, տեսախցիկներ և ստատիկ հոսթեր են ներգրավվում։

Փորձարկում 3: թունելը մեկ հասցե տվե՞ց երկու անգամ

WireGuard-ը հասցեների լողավազան չունի։ Յուրաքանչյուր գործընկեր նույնացվում է իր հանրային բանալիով և AllowedIPs-ում եղած նախածանցերով, ուստի կրկնօրինակը հայտնվում է, երբ նույն թունելի հասցեն գրվում է երկու գործընկերոջ գրառման մեջ կամ նույն բանալու զույգը տեղադրվում է երկու մեքենաների վրա։

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

Տրաֆիկի հաշվիչները այստեղ օգտակար սյունն են: գործընկեր, որը ցույց է տալիս վերջին ձեռքսեղմում, բայց ոչ մի փոխանցում, կա՛մ սխալ հասցեավորված է, կա՛մ ստվերվում է նույն նախածանցը պահանջող մեկ այլ գրառումով։ Նախածանցը դրեք ուղիղ մեկ գործընկերոջ վրա և յուրաքանչյուր սարքի տվեք իր սեփական բանալու զույգը։

OpenVPN-ը լողավազան ունի, և սովորական բախումը համօգտագործվող հաճախորդային պրոֆիլն է՝ հաստատուն --ifconfig տողով, որը պատճենվել է երկրորդ մեքենայի։ Այնուհետև երկու հաճախորդներն էլ պահանջում են նույն թունելի հասցեն, և սերվերն ընդունում է այն սեսիան, որը մշակում է առաջինը։ Լողավազանի սպառումը --duplicate-cn-ով նման արդյունք է տալիս, երբ մեկ վկայագրի մի քանի սեսիաներ մրցում են մեկ գրառման համար։

Դրա համար կարդացեք սերվերի մատյանը, ոչ թե հաճախորդի մատյանը։ Սերվերը գիտի, թե որ սեսիան որ հասցեն վերցրեց, և այնտեղ կրկնվող հասցեները երևում են որպես նախազգուշացումներ, որոնք երբեք չեն հասնում հաճախորդին։

Շտկեք աղբյուրում, ապա նորից ստուգեք երկու սարքերը

Հերթականությունը կարևոր է։ Նախ շտկեք LAN-ի կրկնօրինակը, որովհետև հաճախորդը, որը չի կարող պահել հասցե, չի կարող պահել նաև թունել։ Ապա շտկեք մատակարարումը VPN-ի կողմում, որովհետև լողավազանի նշանակման հաճախորդային խմբագրումը չեղարկվում է հաջորդ միացման ժամանակ։ Վերջում զբաղվեք կրկնվող ինքնություններով: առանձին բանալու զույգեր WireGuard-ում, առանձին վկայագրեր կամ գոնե առանձին պրոֆիլներ OpenVPN-ում։

Հաճախորդի վրա մեխանիկական մասը կարճ է։ Ազատեք և նորացրեք DHCP վարձակալությունը, կամ խնդրեք, որ հասցեն փոխվի սերվերում՝ արգելոցի համար։ Մի մուտքագրեք պատահական հասցե, որը ազատ է թվում։

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

Ապա ստուգեք երկու ծայրերից, ոչ թե մեկից։ Հաստատեք դարպասը, ապա այն ծառայությունը, որն իսկապես անհրաժեշտ է, ապա նորից միացեք և կրկնեք։ Եթե երկու սարք է մասնակցել, ստուգեք երկուսն էլ: մեկ հասցե տեղափոխելը մյուսին թողնում է հնացած հարևանային գրառումներ կամ հին վարձակալություն, որը հետո նորից է հայտնվում։

Ինչ չանել ճանապարհին

Մի՛ լռեցրեք ախտանիշը։ Կրկնվող հասցեների հայտնաբերումը հենց այն է, ինչը խանգարում է ձեզ վերցնել արդեն օգտագործվող հասցե, և այն անջատելը տեսանելի բախումը վերածում է ընդհատվող փաթեթների կորստի, որը շատ ավելի դժվար է հետևել։ Նույնը վերաբերում է անսպասելի հոսթից վկայագրի նախազգուշացումն ընդունելուն: դա ամենևին հասցեի խնդիր չէ, և դրա միջով անցնելը թաքցնում է այլ խնդիր։

Չե՛ք փոխի նաև կառավարվող ցանցի հասցեավորումը ինքնուրույն։ Գրանցեք սկզբնական կարգավորումը, հարցրեք սեփականատիրոջը, երբ հասցեն կենտրոնացված է նշանակվում, և փոփոխությունը պահեք այնքան փոքր, որ հնարավոր լինի հետ շրջել։ RFC 5227-ի հասցեների բախման հայտնաբերման կանոնները բացատրում են, թե ինչ է ապացուցում ճիշտ ստուգումը, ինչը արժե իմանալ նախքան բախումը իրական անվանելը։