Rekebisha mgongano wa anwani ya IP ya ndani baada ya kuunganisha kwenye VPN

Ripoti hizi zote zinasikika sawa na zinamaanisha mambo tofauti: kompyuta inalalamika kuhusu mgongano wa anwani, lakini mara chache tu, na mara nyingi wakati VPN iko hai. Hitilafu tatu tofauti huzalisha ujumbe huo: nakala halisi kwenye kiungo chako mwenyewe, mwingiliano ambapo mtandao wa mbali unatumia masafa ya LAN yako na hakuna kinachorudiwa, na tunnel iliyotoa anwani moja kwa peer wawili. Ukarabati hutofautiana kwa kila kisa, na ule mbaya huhamisha dalili badala ya kuiondoa. Kwa hiyo amua ni kisa gani unacho kabla ya kubadilisha chochote.

Hitilafu tatu zinazoshiriki ujumbe mmoja wa kosa

Nakala inamaanisha kwamba mashine mbili kwenye segment moja zinadai anwani moja. Kernel huona hilo kwa sababu jibu la uchunguzi wake mwenyewe linatoka kwa MAC tofauti, na kinachotokea baadaye hutegemea stack: Linux huiandika kwenye kumbukumbu, Windows huzima kiolesura na kuandika kipengee kwenye kumbukumbu ya mfumo, na mteja wa DHCP anaweza kukataa ofa.

Mwingiliano haurudii anwani yoyote. LAN yako ni 192.168.1.0/24, mtandao wa ofisi pia ni 192.168.1.0/24, na sasa njia ya kuelekea ofisi inaelekeza kwenye anwani ambazo pia ni printa yako na NAS yako. Hakuna kinachogongana kwa maana ya ARP; pakiti inaenda tu kwenye kifaa kisichofaa katika mmoja wa mitandao miwili.

Mgongano kwenye pool ni kosa la tunnel yenyewe. Peer wawili waliwekwa au wakapewa anwani moja ya tunnel, kwa hiyo seva haiwezi kuwatofautisha inapotuma trafiki ya kurudi. Mmoja wa wateja wawili huona handshake inayofanya kazi na hakuna data, jambo ambalo linaonekana kama tatizo la uelekezaji na siyo.

Jaribio la 1: nakala iko kwenye segment yako mwenyewe?

Anza kwa kuorodhesha kile mashine yako inacho kweli, si kile unachokumbuka kuwa ulisanidi. Anwani ya adapta ya VPN ni ya faragha kwa tunnel na si sawa na anwani ambayo tovuti huona, kwa hiyo njia ya kutoka ya umma inayoshirikiwa si mgongano.

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

Kwenye Windows taarifa hiyo hiyo inatoka kwa ipconfig /all na Get-NetIPAddress, na akiba ya majirani iko kwenye arp -a. Ikiwa anwani inayozozaniwa iko kwenye adapta ya kimwili na malalamiko yanatokea bila VPN kufanya kazi, VPN ni mshiriki wa nje na unapaswa kuacha kuishughulikia.

Ili kuthibitisha nakala badala ya kubahatisha, chunguza anwani kutoka kwa kifaa kisichomiliki anwani hiyo. arping -D hutuma uchunguzi na anwani ya chanzo ya sifuri, kwa hiyo jibu kutoka kwa MAC isiyotarajiwa linathibitisha kwamba mwenyeji mwingine tayari anajibu anwani hiyo.

sudo arping -D -I eth0 -c 3 192.168.1.50

Kisha pata mmiliki kupitia msimamizi wa mtandao badala ya kuchagua anwani nyingine mwenyewe. Ugawaji tuli unaokaa tu kwenye maelezo ya mtu fulani, printa zenye anwani isiyobadilika na uhifadhi kwenye seva ya DHCP ndio wahusika wa kawaida, na kifaa kilichozimwa bado kinamiliki kukodisha kwake.

Jaribio la 2: mitandao miwili inapishana?

Linganisha kiambishi ambacho tunnel inakupa na viambishi kwenye violesura vyako mwenyewe. Ikiwa masafa ya mbali ni sawa na LAN yako au yanaihusisha, hitilafu ni mwingiliano, na kiashiria ni kwamba mwenyeji anayefikiwa bila VPN huzimika, au printa yako mwenyewe inajibu kwenye anwani ya ofisi.

ip route get 192.168.1.10
ip -br addr show

Utafutaji wa njia unakuambia kiolesura ambacho kernel kingetumia, na jibu hilo ndio utambuzi wote. Ikiwa linasema tunnel kwa anwani inayomilikiwa na printa yako ya ndani, una mwingiliano na hakuna uhuishaji wa kukodisha utakaobadilisha hilo.

Kuna njia tatu za uaminifu za kutoka, na kwa kawaida moja tu inapatikana kwako. Upande wa mbali unaweza kufanya masquerade ya trafiki kwa subnet inayopishana, ili mteja wako aone tu anwani ya tunnel ya seva. Tunnel inaweza kubeba kiambishi cha mbali chembamba zaidi kisichogongana na LAN yako. Au mteja anaweza kuelekeza kwa anwani ya chanzo kwa kanuni za sera, ambayo inafanya kazi lakini ni dhaifu na ngumu kumpa mwenzako.

Kubadilisha nambari za mtandao wa ofisi mara chache ni uamuzi wako. Kubadilisha nambari za LAN yako mwenyewe ili kuepuka mgongano ni mabadiliko makubwa kuliko wengi wanavyotarajia pindi printa, kamera na wenyeji tuli wanapohusika.

Jaribio la 3: tunnel ilitoa anwani moja mara mbili?

WireGuard haina pool ya anwani. Kila peer hutambulishwa kwa ufunguo wake wa umma na kwa viambishi vilivyo kwenye AllowedIPs, kwa hiyo nakala inaonekana wakati anwani hiyo ya tunnel imeandikwa kwenye vipengee viwili vya peer au ufunguo huo umeinstaliwa kwenye mashine mbili.

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

Vihesabu vya trafiki ndio safu muhimu hapa: peer inayoonyesha handshake ya hivi karibuni lakini hakuna uhamishaji ama imeelekezwa vibaya au inafunikwa na kipengee kingine kinachodai kiambishi hicho. Weka kiambishi kwenye peer mmoja hasa na umpe kila kifaa ufunguo wake.

OpenVPN ina pool, na mgongano wa kawaida ni wasifu wa mteja unaoshirikiwa na mstari wa --ifconfig usiobadilika ulionakiliwa kwenye mashine ya pili. Wateja wote wawili kisha huomba anwani hiyo hiyo ya tunnel, na seva hukubali kikao ambacho inakichakata kwanza. Kuoisha kwa pool kwa --duplicate-cn hutoa matokeo kama hayo wakati vikao kadhaa vya cheti kimoja vinashindana kwa kipengee kimoja.

Soma kumbukumbu ya seva badala ya kumbukumbu ya mteja kwa hili. Seva inajua kikao kipi kilidai anwani ipi, na anwani zinazorudiwa zinaonekana hapo kama maonyo ambayo hayafiki kwa mteja.

Rekebisha kwenye chanzo, kisha angalia tena vifaa vyote viwili

Mpangilio ni muhimu. Rekebisha kwanza nakala kwenye LAN, kwa sababu mteja asiyeweza kushikilia anwani hawezi kushikilia tunnel pia. Kisha rekebisha ugavi upande wa VPN, kwa sababu mabadiliko ya upande wa mteja kwenye ugawaji wa pool yanafutwa kwenye muunganisho unaofuata. Mwisho, shughulikia utambulisho uliorudiwa: jozi za funguo tofauti kwenye WireGuard, vyeti tofauti au angalau wasifu tofauti kwenye OpenVPN.

Kwa upande wa mteja sehemu ya kiufundi ni fupi. Achilia na uhuisha kukodisha kwa DHCP, au omba anwani ibadilishwe kwenye seva kwa uhifadhi. Usiandike anwani ya nasibu inayoonekana huru.

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

Kisha thibitisha kutoka pande zote mbili, si moja. Thibitisha lango, kisha huduma unayohitaji kweli, kisha unganisha tena na urudie. Ikiwa vifaa viwili vilihusika, angalia vyote viwili: kuhamisha anwani moja humwacha mwingine na vipengee vya majirani vilivyopitwa na wakati au kukodisha kwa zamani kunakotokea tena baadaye.

Mambo ya kuepuka njiani

Usinyamazishe dalili. Ugunduzi wa anwani zinazorudiwa ndio unakuzuia kuchukua anwani ambayo tayari inatumika, na kuuzima kunabadilisha mgongano unaoonekana kuwa upotevu wa pakiti wa vipindi ambao ni mgumu zaidi kufuatilia. Ndivyo ilivyo pia kwa kukubali onyo la cheti kutoka kwa mwenyeji asiyetarajiwa: hilo si tatizo la anwani hata kidogo, na kubofya kupitia hilo kunaficha hitilafu nyingine.

Pia usibadilishe anwani za mtandao unaosimamiwa peke yako. Andika mpangilio wa awali, muulize mmiliki wakati anwani inagawiwa kwa serikali kuu, na uweke mabadiliko madogo vya kutosha kurudishwa. Kanuni za RFC 5227 za kugundua migongano ya anwani zinaeleza kile uchunguzi sahihi unathibitisha, jambo ambalo ni vyema kujua kabla ya kuita mgongano kuwa wa kweli.