Egyetlen útvonal sem javítja meg a LAN-oddal átfedő VPN-készletet

Az alkalmazás szerint az alagút egészséges, mégis a szükséges célok fele soha nem válaszol. A reflex az, hogy adjunk hozzá egy útvonalat vagy csökkentsük a metrikát, és épp ez a reflex az a mítosz, amelyet először meg kell ölni. Amikor a kliens saját LAN-ja és az alagút készlete ugyanarra az előtagra tart igényt, a forgalomirányító tábla két összeegyeztethetetlen tényt tart, és sem egy alapértelmezett útvonal, sem egy metrika nem oldja fel őket. A javítás címzési döntés, és semmilyen útvonal-szerkesztés nem helyettesíti.

Miért nem tud egy extra útvonal egy előtagot kettéválasztani

Egy útvonal nem tud két igényt szétválasztani egy előtagon, ezért az ésszerű lépés az, hogy felhagyjunk a megfelelő útvonalsor keresésével. A verem nem tesz azonos előtagot a kapcsolt útvonal elé, és egy konkrétabb bejegyzés valóban elkapja a címet, de elérhetetlenné teszi a tulajdonos helyi gazdagépet. Ami forgalomirányítási problémának látszik, az címzési ütközés, és mindkét javítás címeket változtat, nem útvonalakat. Teszteld az állítást a saját gépeden, mielőtt elfogadod.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Kérdezd meg a rendszert egyetlen címről, és figyeld meg, melyik interfészt nevezi meg. A Linux, a macOS és a Windows mindegyike csak olvasható lekérdezéssel válaszol, amely közli a választott interfészt és a következő ugrást anélkül, hogy bármit továbbítana. Amikor a válasz a fizikai adapterre mutat, miközben az alagút fent van, a kernel a címet a kapcsolaton lévőnek tekinti, nem pedig olyannak, amit az alagút vihetne.

Tedd a szolgáltató által adott előtagot az otthoni router által kiszolgált előtag mellé, és hasonlítsd össze őket karakterláncként. A pontos egyezés a világos eset, és a szélesebb szolgáltatói készlet, amely tartalmazza az otthoni alhálózatot, ugyanúgy meghibásodik, csak könnyebb elszúrni. Két előtag, amely csak hasonlónak látszik, nem ütközés, ezért írd fel mindkettőt, mielőtt bármit megváltoztatsz.

Olvasd el, milyen készletet kapott valójában a kliens

Azt olvasd, amit a kliens kapott, ne a szolgáltató marketingoldalát. Növeld egy OpenVPN-kliens naplójának részletességét, és a szerver által küldött útvonalak megjelennek benne, felfedve az alagút előtagjait; máshol a készlet a kapcsolat részleteiben vagy magán az adapteren látszik. Kérd meg a szolgáltatót az általa használt összes privát tartomány teljes listájára, mert egyetlen /24 ma még kettő lehet holnap. A szokásos RFC 1918 blokkok elkerülése nem ugyanaz, mint az elkerülése annak a kiosztásnak, amelyet valóban kaptál.

A készlet zsugorodhat vagy régiók között mozoghat, ezért a listának dátumra és felelősre van szüksége. A legutóbbi tervváltoztatásodnál régebbi szolgáltatói választ kezeld találgatásként, nem tényként. Kérdezz újra, mielőtt elköteleznél magad egy tartomány mellett, és tartsd a választ a hálózati jegyzeteknél, hogy a következő ember örökölje a bizonyítékot.

Az újraszámozás az a javítás, amelyet te magad meg tudsz tenni

Ha a VPN-szerver nem a tiéd, hogy megváltoztasd, az otthoni LAN áthelyezése az egyetlen elérhető javítás, és ez a szokásos helyzet egy kereskedelmi szolgáltatónál. Válassz a szolgáltató készletén kívül és azokon a tartományokon kívül, amelyekre később szükséged lehet, és ellenőrizd minden más hely ellen, ahová alagúton keresztül elérsz. Számíts rövid kiesésre és az elfelejtett eszközök hosszabb uszályára: egy eszköz, amely még a régi címet tartja, működőnek látszik, amíg szükség nem lesz az átjáróra.

1. Először leltár: a router saját címe, a DHCP-tartomány, a foglalások, a porttovábbítások és minden eszköz, amelynek címét kézzel írták be.
2. Aztán változtasd meg a router LAN-előtagját és a DHCP-tartományt együtt egy karbantartási ablakban, és újítsd meg a vezetékes bérleteket a vezeték nélküliek előtt.
3. Ezután javítsd a statikus címeket: nyomtatók, hálózati tároló, minden, amin mereven kódolt átjáró van.
4. Végül csatlakoztasd újra a VPN-klienst, és erősítsd meg, hogy az alagút címe már nem ütközik a LAN-nal.

Ebben a sorrendben haladj végig a címeken, ne egyszerre mindenen, és tartsd a régi tartományt egy ideig dokumentálva, hogy az elavult eszköz felismerhető legyen, ne titokzatos. Az az eszköz, amely soha nem újít, azzal jelzi magát, hogy nem éri el az átjárót, ami sokkal jobb nyom, mint egy támogatási hívás. Ha a router egy napnál hosszabb bérleteket oszt, rövidítsd le őket az ablak idejére.

Mit tud és mit nem tud egy alias

Amikor a szerver a tiéd, a címek fordítása a kliensen felfedheti a távoli előtagot egy szabad helyi tartományon belül, így ugyanaz a gazdagép egy második címen válaszol. A közösségi OpenVPN ezt client-nat, és ez az utasítás kifejezetten arra a kliensre vonatkozik, hiányzik a kereskedelmi és mobil kliensekből, amelyekkel általában összehasonlítják. Az elrendezéshez a fordítással egyező útvonal, az alias számára szabad tartomány és egy olyan szerver kell, amely hajlandó válaszolni a kliens le nem fordított címére. Ebből semmi sem segít, ha a kliens egy felügyelt szolgáltatóhoz tartozik, amelyet nem tudsz beállítani.

Amint a változás életbe lép, érj el egy helyi és egy távoli gazdagépet először cím, majd név szerint, és jegyezd fel, melyik útvonalat választja a rendszer minden alkalommal. Egy név még mindig a régi tartományba oldódhat fel, ezért a címek és a nevek külön ellenőrzést érdemelnek. Indíts újra egy klienst és egy szerveroldali eszközt, ha valamelyik végig bekapcsolva maradt a változás alatt, mert a gyorsítótárazott szomszédbejegyzések tovább élnek, mint a szerkesztés.

Írd le a kiválasztott előtagokat oda, ahol az emberek valóban megnézik: a hálózati jegyzetekbe, a router saját megjegyzésmezőjébe, a bevezető oldalra. Valaki újra a 192.168.1.0/24-et fogja választani, és az ütközés visszatér vele.