Kohaliku IP-aadressi konflikti parandamine pärast VPN-iga ühendamist

Kõik need raportid kõlavad ühtemoodi ja tähendavad erinevat: sülearvuti kurdab aadressikonflikti üle, aga ainult mõnikord ja enamasti siis, kui VPN töötab. Kolm eraldi riket tekitavad selle teate: tõeline duplikaat sinu enda lingil, kattuvus, kus kaugvõrk kasutab sinu LAN-i vahemikku ja midagi ei dubleerita, ning tunnel, mis andis ühe aadressi kahele partnerile. Parandus erineb igal juhul ja vale parandus liigutab sümptomit selle asemel, et seda eemaldada. Otsusta seega, milline juhtum sul on, enne kui midagi muudad.

Kolm riket ühe veateatega

Duplikaat tähendab, et kaks masinat samas segmendis nõuavad mõlemad üht aadressi. Kernel märkab seda, sest vastus tema enda päringule tuleb teiselt MAC-ilt, ja mis edasi juhtub, sõltub virnast: Linux logib selle, Windows keelab liidese ja kirjutab süsteemilogi kirje, ning DHCP-klient võib pakkumise tagasi lükata.

Kattuvus ei dubleeri ühtki aadressi. Sinu LAN on 192.168.1.0/24, kontori võrk on samuti 192.168.1.0/24, ja nüüd osutab marsruut kontorisse aadressidele, mis on ka sinu printer ja sinu NAS. ARP-i mõttes ei ole miski konfliktis; pakett lihtsalt läheb valesse seadmesse ühes kahest võrgust.

Tiigi kokkupõrge on tunneli enda viga. Kaks partnerit seadistati sama tunneliaadressiga või anti see neile, mistõttu server ei suuda neid eristada, kui saadab tagasiliiklust. Üks kahest kliendist näeb toimivat kätlust ja mitte mingisuguseid andmeid, mis loeb marsruutimisprobleemina ja seda ei ole.

Test 1: kas duplikaat on sinu enda segmendis?

Alusta loetlemisega, mis sinu masinal tegelikult on, mitte sellega, mida sa mäletad seadistanud olevat. VPN-i adapteri aadress on tunnelile privaatne ega ole sama, mida veebisaidid näevad, seega jagatud avalik väljund ei ole konflikt.

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

Windowsis tulevad samad andmed ipconfig /all ja Get-NetIPAddress kaudu, naabrite vahemälu asub arp -a sees. Kui vaidlusalune aadress on füüsilisel adapteril ja kaebus ilmub ilma VPN-i töötamiseta, on VPN kõrvaltvaataja ja peaksid selle diagnoosimise lõpetama.

Duplikaadi tõestamiseks oletamise asemel kontrolli aadressi seadmest, mis seda ei oma. arping -D saadab päringu nulllähteaadressiga, seega ootamatu MAC-i vastus tõestab, et teine host juba vastab sellele aadressile.

sudo arping -D -I eth0 -c 3 192.168.1.50

Seejärel leia omanik võrguadministraatori kaudu, selle asemel et ise teist aadressi valida. Staatilised määramised, mis elavad ainult kellegi märkmetes, fikseeritud aadressiga printerid ja DHCP-serveri reservatsioonid on tavapärased süüdlased, ja väljalülitatud seade omab endiselt oma renti.

Test 2: kas kaks võrku kattuvad?

Võrdle eesliidet, mille tunnel sulle annab, oma liideste eesliidetega. Kui kaugvahemik on sinu LAN-iga võrdne või seda sisaldab, on rike kattuvus, ja vihjeks on see, et ilma VPN-ita kättesaadav host kaob või sinu enda printer vastab kontori aadressil.

ip route get 192.168.1.10
ip -br addr show

Marsruudiotsing ütleb, millist liidest kernel kasutaks, ja see vastus on kogu diagnoos. Kui see näitab tunnelit aadressi jaoks, mis kuulub sinu kohalikule printerile, on sul kattuvus ja ükski rendi uuendamine ei muuda seda.

Väljapääsuks on kolm ausat teed ja tavaliselt on saadaval ainult üks. Kaugpool võib kattuva alavõrgu liiklust maskeerida, nii et sinu klient näeb ainult serveri tunneliaadressi. Tunnel võib kanda kitsamat kaug-eesliidet, mis sinu LAN-iga ei põrka. Või saab klient marsruutida lähteaadressi järgi poliitikareeglitega, mis töötab, kuid on habras ja raskesti kolleegile edasiantav.

Kontorivõrgu ümbernummerdamine on harva sinu otsus. Oma LAN-i ümbernummerdamine kokkupõrke vältimiseks on suurem muudatus, kui enamik inimesi ootab, kui printerid, kaamerad ja staatilised hostid on mängus.

Test 3: kas tunnel andis ühe aadressi kaks korda?

WireGuardil ei ole aadressitiiki. Iga partnerit identifitseeritakse tema avaliku võtme ja AllowedIPs sees olevate eesliidete järgi, seega duplikaat tekib siis, kui sama tunneliaadress kirjutatakse kahte partnerikirjesse või sama võtmepaar paigaldatakse kahte masinasse.

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

Liiklusloendurid on siin kasulik veerg: partner, mis näitab hiljutist kätlust, kuid mitte ülekannet, on kas valesti adresseeritud või jääb teise sama eesliidet nõudva kirje varju. Pane eesliide täpselt ühele partnerile ja anna igale seadmele oma võtmepaar.

OpenVPN tiik on olemas ja tavaline kokkupõrge on jagatud kliendiprofiil, mille fikseeritud rida --ifconfig on teise masinasse kopeeritud. Siis küsivad mõlemad kliendid sama tunneliaadressi ja server võtab vastu selle sessiooni, mille ta esimesena töötleb. Tiigi ammendumine valikuga --duplicate-cn annab sarnase tulemuse, kui ühe sertifikaadi mitu sessiooni võistlevad ühe kirje pärast.

Selle jaoks loe serveri logi, mitte kliendi logi. Server teab, milline sessioon millise aadressi võttis, ja korduvad aadressid on seal nähtavad hoiatustena, mis ei jõua kunagi kliendini.

Paranda allikas ja kontrolli siis mõlemat seadet uuesti

Järjekord on oluline. Esmalt paranda LAN-i duplikaat, sest klient, kes ei suuda aadressi hoida, ei suuda hoida ka tunnelit. Seejärel paranda provisioneerimine VPN-i poolel, sest kliendipoolne muudatus tiigi määramises tühistatakse järgmisel ühendusel. Lõpuks tegele dubleeritud identiteetidega: eraldi võtmepaarid WireGuardis, eraldi sertifikaadid või vähemalt eraldi profiilid OpenVPN-is.

Kliendis on mehaaniline osa lühike. Vabasta ja uuenda DHCP rent või palu aadress serveris reservatsiooni jaoks muuta. Ära sisesta juhuslikku aadressi, mis tundub vaba.

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

Seejärel kontrolli mõlemast otsast, mitte ühest. Kinnita lüüs, seejärel teenus, mida tegelikult vajad, seejärel ühenda uuesti ja korda. Kui osales kaks seadet, kontrolli mõlemat: ühe aadressi liigutamine jätab teise vananenud naaberkirjete või vana rendiga, mis hiljem uuesti ilmub.

Mida teel mitte teha

Ära summutage sümptomit. Duplikaataadresside tuvastamine on see, mis takistab sul võtta juba kasutusel olevat aadressi, ja selle väljalülitamine muudab nähtava konflikti aeg-ajalt esinevaks paketikaoks, mida on palju raskem jälgida. Sama kehtib ootamatu hosti sertifikaadihoiatuse aktsepteerimise kohta: see ei ole üldse aadressiprobleem ja sellest mööda klikkamine peidab teise rikke.

Ära muuda ka hallatava võrgu adresseerimist omapäi. Kirjuta üles algne seade, küsi omanikult, kui aadress määratakse tsentraalselt, ja hoia muudatus piisavalt väike, et selle saaks tagasi pöörata. RFC 5227 aadressikonfliktide tuvastamise reeglid selgitavad, mida õige päring tõestab, mida tasub teada enne, kui nimetad konflikti tõeliseks.