Helyi IP-címütközés javítása VPN-csatlakozás után

Mindegyik ilyen jelentés ugyanúgy hangzik és mást jelent: a laptop címütközésre panaszkodik, de csak néha, és többnyire akkor, amikor a VPN fut. Három külön hiba termeli ezt az üzenetet: valódi duplikátum a saját kapcsolatodon, átfedés, ahol a távoli hálózat a LAN-tartományodat használja és semmi sem duplikálódik, és egy alagút, amely egy címet két partnernek adott. A javítás minden esetben más, és a rossz a tünetet mozgatja ahelyett, hogy megszüntetné. Tehát döntsd el, melyik eset a tiéd, mielőtt bármit szerkesztenél.

Három hiba, egy hibaüzenet

A duplikátum azt jelenti, hogy két gép ugyanabban a szegmensben ugyanazt a címet igényli. A kernel észreveszi, mert a saját próbájára adott válasz másik MAC-ről érkezik, és hogy mi történik utána, a veremtől függ: a Linux naplózza, a Windows letiltja az interfészt és bejegyzést ír a rendszernaplóba, a DHCP-kliens pedig visszautasíthatja az ajánlatot.

Az átfedés egyetlen címet sem duplikál. A LAN 192.168.1.0/24, az irodai hálózat szintén 192.168.1.0/24, és most az irodába vezető útvonal olyan címekre mutat, amelyek a nyomtatód és a NAS-od is. ARP-értelemben semmi sincs ütközésben; a csomag egyszerűen a rossz eszközre megy a két hálózat egyikén.

A készletütközés az alagút saját hibája. Két partnert ugyanazzal az alagútcímmel konfiguráltak, vagy megkapták azt, így a szerver nem tudja megkülönböztetni őket, amikor visszirányú forgalmat küld. A két kliens egyike működő kézfogást és semmi adatot lát, ami útválasztási problémának tűnik, és nem az.

1. teszt: a saját szegmensedben van a duplikátum?

Kezdd annak felsorolásával, ami a gépeden valóban van, nem azzal, amire emlékszel, hogy beállítottad. A VPN-adapter címe az alagút számára privát, és nem ugyanaz, mint amit a webhelyek látnak, tehát a megosztott nyilvános kijárat nem ütközés.

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

Windowson ugyanezeket az információkat a ipconfig /all és a Get-NetIPAddress adja, a szomszéd-gyorsítótár pedig a arp -a-ben van. Ha a vitatott cím a fizikai adapteren van, és a panasz a VPN futtatása nélkül is megjelenik, a VPN csak szemlélő, és abba kell hagynod a diagnosztizálását.

Hogy találgatás helyett bizonyítsd a duplikátumot, próbáld ki a címet egy olyan eszközről, amely nem birtokolja. A arping -D nulla forrás-címmel küldi a próbát, így egy váratlan MAC-ről érkező válasz bizonyítja, hogy egy másik gazdagép már válaszol erre a címre.

sudo arping -D -I eth0 -c 3 192.168.1.50

Ezután a hálózati adminisztrátoron keresztül keresd meg a tulajdonost, ahelyett hogy magad választanál másik címet. A csak valaki jegyzeteiben élő statikus kiosztások, a fix című nyomtatók és a DHCP-kiszolgálón lévő foglalások a szokásos bűnösök, és egy kikapcsolt eszköz is birtokolja a bérletét.

2. teszt: átfedésben van-e a két hálózat?

Hasonlítsd össze az alagút által adott előtagot a saját interfészeid előtagjaival. Ha a távoli tartomány egyenlő a LAN-oddal vagy tartalmazza azt, a hiba átfedés, és az árulkodó jel az, hogy egy VPN nélkül elérhető gazdagép eltűnik, vagy a saját nyomtatód irodai címen válaszol.

ip route get 192.168.1.10
ip -br addr show

Az útvonalkeresés megmondja, melyik interfészt használná a kernel, és ez a válasz a teljes diagnózis. Ha az alagutat mondja egy olyan címre, amely a helyi nyomtatódhoz tartozik, átfedésed van, és semmilyen bérletújítás nem változtat ezen.

Három tisztességes kiút van, és általában csak egy érhető el számodra. A távoli oldal maszkolhatja az átfedő alhálózat forgalmát, így a kliensed csak a szerver alagútcímét látja. Az alagút hordozhat egy szűkebb távoli előtagot, amely nem ütközik a LAN-oddal. Vagy a kliens forráscím szerint irányíthat házirend-szabályokkal, ami működik, de törékeny és nehéz átadni egy kollégának.

Az irodai hálózat újraszámozása ritkán a te döntésed. A saját LAN újraszámozása az ütközés elkerülésére nagyobb változás, mint amire a legtöbben számítanak, amint nyomtatók, kamerák és statikus gazdagépek kerülnek képbe.

3. teszt: kétszer adta ki az alagút ugyanazt a címet?

A WireGuardnak nincs címkészlete. Minden partnert a nyilvános kulcsa és a AllowedIPs-ben lévő előtagok azonosítanak, így duplikátum akkor jelenik meg, ha ugyanazt az alagútcímet két partnerbejegyzésbe írják, vagy ugyanazt a kulcspárt két gépre telepítik.

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

A forgalomszámlálók a hasznos oszlop itt: az a partner, amely friss kézfogást mutat, de semmi átvitelt, vagy rossz címre mutat, vagy egy másik, ugyanazt az előtagot igénylő bejegyzés árnyékolja. Tegyél előtagot pontosan egy partnerre, és adj minden eszköznek saját kulcspárt.

A OpenVPN készlete valódi, és a gyakori ütközés egy megosztott kliensprofil, amelyben egy rögzített --ifconfig sor egy második gépre másolódott. Ekkor mindkét kliens ugyanazt az alagútcímet kéri, és a szerver azt a munkamenetet fogadja el, amelyiket először dolgozza fel. A készlet kimerülése a --duplicate-cn kapcsolóval hasonló eredményt ad, amikor egy tanúsítvány több munkamenete verseng egy bejegyzésért.

Ehhez a kiszolgáló naplóját olvasd a kliens naplója helyett. A szerver tudja, melyik munkamenet melyik címet foglalta el, és az ismétlődő címek ott olyan figyelmeztetésként látszanak, amelyek soha nem jutnak el a klienshez.

Javíts a forrásnál, aztán ellenőrizd újra mindkét eszközt

A sorrend számít. Először a LAN-duplikátumot javítsd, mert az a kliens, amely nem tud címet megtartani, alagutat sem tud megtartani. Utána a VPN oldalán javítsd a kiépítést, mert a kliensoldali módosítás egy készletkiosztáson a következő kapcsolatnál visszavonódik. Végül a duplikált identitásokkal foglalkozz: külön kulcspárok a WireGuardon, külön tanúsítványok vagy legalább külön profilok az OpenVPNon.

A kliensen a mechanikus rész rövid. Szabadíts fel és újíts meg egy DHCP-bérletet, vagy kérd a cím módosítását a szerveren foglalás céljából. Ne írj be egy szabadnak tűnő véletlenszerű címet.

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

Ezután mindkét végpontról ellenőrizd, ne egyről. Igazold az átjárót, majd a szolgáltatást, amelyre valóban szükséged van, majd csatlakozz újra és ismételd meg. Ha két eszköz volt érintett, ellenőrizd mindkettőt: egy cím áthelyezése a másikat elavult szomszédbejegyzésekkel vagy régi bérlettel hagyja, amely később újra megjelenik.

Mit ne tegyél útközben

Ne némítsd el a tünetet. A duplikált címek felismerése az, ami megakadályozza, hogy már használatban lévő címet vegyél át, és kikapcsolása egy látható ütközést időszakos csomagvesztéssé alakít, amelyet sokkal nehezebb nyomon követni. Ugyanez vonatkozik arra, hogy elfogadod egy váratlan gazdagép tanúsítványfigyelmeztetését: az egyáltalán nem címprobléma, és az átkattintása más hibát rejt el.

A felügyelt hálózat címzését se változtasd meg magad. Jegyezd fel az eredeti beállítást, kérdezd meg a tulajdonost, amikor a címet központilag osztják ki, és tartsd a változtatást elég kicsinek ahhoz, hogy visszafordítható legyen. A RFC 5227 címütközés-felismerési szabályai elmagyarázzák, mit bizonyít egy helyes próba, amit érdemes tudni, mielőtt valódi ütközésnek nevezel valamit.