Ripari lokan IP-adresan konflikton post konektiĝo al VPN

Ĉiu el ĉi tiuj raportoj sonas same kaj signifas ion alian: la tekkomputilo plendas pri adresa konflikto, sed nur foje, kaj plejparte dum la VPN estas ŝaltita. Tri apartaj difektoj produktas tiun mesaĝon: vera duoblaĵo sur via propra ligo, interkovro kie la fora reto uzas vian LAN-gamon kaj nenio duobliĝas, kaj tunelo kiu donis unu adreson al du samtavolanoj. La riparo malsamas en ĉiu kazo, kaj la malĝusta movas la simptomon anstataŭ forigi ĝin. Do decidu kiun kazon vi havas antaŭ ol ŝanĝi ion ajn.

Tri difektoj kun unu erarmesaĝo

Duoblaĵo signifas ke du maŝinoj en la sama segmento ambaŭ postulas unu adreson. La kerno rimarkas tion ĉar la respondo al sia propra sondado venas de alia MAC, kaj kio okazas poste dependas de la stako: Linux protokolas ĝin, Windows malŝaltas la interfacon kaj skribas rikordon en la sistema protokolo, kaj DHCP-kliento povas rifuzi la proponon.

Interkovro duobligas neniun adreson. Via LAN estas 192.168.1.0/24, la oficeja reto ankaŭ estas 192.168.1.0/24, kaj nun la vojo al la oficejo montras al adresoj kiuj ankaŭ estas via presilo kaj via NAS. En la senco de ARP nenio estas en konflikto; la paketo simple iras al la malĝusta aparato en unu el la du retoj.

Kolizio en la baseno estas la propra kulpo de la tunelo. Du samtavolanoj estis agorditaj kun aŭ ricevis la saman tunelan adreson, do la servilo ne povas distingi ilin kiam ĝi sendas revenan trafikon. Unu el la du klientoj vidas funkciantan manpremon kaj neniujn datumojn, kio legiĝas kiel enkursiga problemo kaj ne estas.

Testo 1: ĉu la duoblaĵo estas sur via propra segmento?

Komencu listigante tion, kion via maŝino efektive havas, ne tion, kion vi memoras agordinta. VPN-adaptila adreso estas privata por la tunelo kaj ne estas la sama kiel la adreso, kiun vidas retejoj, do kunhava publika eliro ne estas konflikto.

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

En Windows la samaj informoj venas de ipconfig /all kaj Get-NetIPAddress, kun la najbara kaŝmemoro en arp -a. Se la pridisputata adreso estas sur la fizika adaptilo kaj la plendo aperas sen la VPN funkcianta, la VPN estas spektanto kaj vi devus ĉesi diagnozi ĝin.

Por pruvi duoblaĵon anstataŭ diveni, testu la adreson de aparato, kiu ne posedas ĝin. arping -D sendas la sondadon kun nula fonta adreso, do respondo de neatendita MAC pruvas, ke alia gastiganto jam respondas por tiu adreso.

sudo arping -D -I eth0 -c 3 192.168.1.50

Poste trovu la posedanton per la reta administranto anstataŭ mem elekti alian adreson. Statikaj atribuoj, kiuj vivas nur en la notoj de iu, presiloj kun fiksa adreso kaj rezervoj sur la DHCP-servilo estas la kutimaj kulpuloj, kaj aparato, kiu estas malŝaltita, ankoraŭ posedas sian luon.

Testo 2: ĉu la du retoj interkovriĝas?

Komparu la prefikson, kiun la tunelo donas al vi, kun la prefiksoj sur viaj propraj interfacoj. Se la fora gamo egalas vian LAN-on aŭ enhavas ĝin, la difekto estas interkovro, kaj la signo estas ke gastiganto atingebla sen la VPN mallumiĝas, aŭ ke via propra presilo respondas sur oficeja adreso.

ip route get 192.168.1.10
ip -br addr show

La vojserĉo diras al vi, kiun interfacon la kerno uzus, kaj tiu respondo estas la tuta diagnozo. Se ĝi diras la tunelon por adreso, kiu apartenas al via loka presilo, vi havas interkovron kaj neniu luo-renovigo ŝanĝos tion.

Ekzistas tri honestaj eliroj, kaj kutime nur unu estas disponebla por vi. La fora flanko povas maski trafikon por la interkovranta subreto, do via kliento nur vidas la tunelan adreson de la servilo. La tunelo povas porti pli mallarĝan foran prefikson, kiu ne kolizias kun via LAN. Aŭ la kliento povas enkursigi laŭ fonta adreso kun politikaj reguloj, kio funkcias sed estas rompiĝema kaj malfacile transdonebla al kolego.

Renumerigi la oficejan reton malofte estas via decido. Renumerigi vian propran LAN por eviti la kolizion estas pli granda ŝanĝo ol plej multaj homoj atendas, unufoje kiam presiloj, fotiloj kaj statikaj gastigantoj estas implikitaj.

Testo 3: ĉu la tunelo donis unu adreson dufoje?

WireGuard ne havas adresan basenon. Ĉiu samtavolano identiĝas per sia publika ŝlosilo kaj per la prefiksoj en AllowedIPs, do duoblaĵo aperas kiam la sama tunela adreso estas skribita en du rikordojn de samtavolano aŭ la sama ŝlosilparo estas instalita sur du maŝinoj.

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

Trafiknombriloj estas la utila kolumno ĉi tie: samtavolano, kiu montras freŝan manpremon sed neniun transdonon, aŭ estas misadresita aŭ estas ombrigita de alia rikordo postulanta la saman prefikson. Metu prefikson sur precize unu samtavolanon kaj donu al ĉiu aparato sian propran ŝlosilparon.

OpenVPN havas basenon, kaj la kutima kolizio estas komuna klienta profilo kun fiksa linio --ifconfig kopiita al dua maŝino. Tiam ambaŭ klientoj petas la saman tunelan adreson, kaj la servilo akceptas tiun sesion, kiun ĝi prilaboras unue. Basena elĉerpiĝo kun --duplicate-cn produktas similan rezulton kiam pluraj sesioj de unu atestilo konkuras por unu rikordo.

Por ĉi tio legu la servilan protokolon anstataŭ la klientan. La servilo scias, kiu sesio postulis kiun adreson, kaj ripetaj adresoj tie videblas kiel avertoj, kiuj neniam atingas la klienton.

Riparu ĉe la fonto, poste rekontrolu ambaŭ aparatojn

La ordo gravas. Unue riparu LAN-duoblaĵon, ĉar kliento, kiu ne povas teni adreson, ankaŭ ne povas teni tunelon. Poste riparu la provizadon ĉe la VPN-flanko, ĉar klientflanka ŝanĝo de basena atribuo malfariĝas ĉe la sekva konekto. Fine traktu duobligitajn identecojn: apartaj ŝlosilparoj ĉe WireGuard, apartaj atestiloj aŭ almenaŭ apartaj profiloj ĉe OpenVPN.

Ĉe la kliento la mekanika parto estas mallonga. Liberigu kaj renovigu DHCP-luon, aŭ petu ke la adreso ŝanĝiĝu sur la servilo por rezervo. Ne tajpu hazardan adreson, kiu aspektas libera.

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

Poste kontrolu de ambaŭ finoj, ne de unu. Konfirmu la enirejon, poste la servon, kiun vi efektive bezonas, poste rekonektu kaj ripetu. Se du aparatoj estis implikitaj, kontrolu ambaŭ: movi unu adreson lasas la alian kun malnoviĝintaj najbaraj rikordoj aŭ malnova luo, kiu reaperos poste.

Kion ne fari survoje

Ne silentigu la simptomon. Duobla-adresa detektado estas tio, kio malhelpas vin preni adreson jam uzatan, kaj malŝalti ĝin ŝanĝas videblan konflikton en intermitan pakoperdon, kiu estas multe pli malfacile spurebla. La samo validas por akcepti atestilan averton de neatendita gastiganto: tio tute ne estas adresa problemo, kaj klaki preter ĝi kaŝas alian difekton.

Ne ŝanĝu ankaŭ mem la adresadon de administrata reto. Notu la originalan agordon, demandu la posedanton kiam la adreso estas centrale atribuata, kaj tenu la ŝanĝon sufiĉe malgranda por malfari. La reguloj de RFC 5227 por detekti adresajn konfliktojn klarigas, kion pruvas ĝusta sondado, kio indas scii antaŭ ol nomi konflikton reala.