Két VPN-kliens, egy útválasztási tábla: ki kapja meg az alapértelmezett útvonalat

Úgy tűnik, mintha két VPN-kliens ugyanazért a socketért harcolna, és a kézenfekvő megoldás az egyik eltávolítása. A gyakorlatban ritkán érintik ugyanazt a socketet. Minden kapcsolódás újraírja az operációs rendszer útválasztási tábláját, és a teljes alagút profil igényli az alapértelmezett útvonalat. Általában a legutóbb csatlakozó nyer, ezért tűnik úgy, hogy a tünet a kliensek között vándorol.

A konfliktus az útválasztási táblában él

Virtuális adapter plusz alapértelmezett útvonal – így ragadja meg a teljes alagút a forgalmat. Amikor a második kliens telepíti a saját alapértelmezett útvonalát, a régebbi bejegyzés lecserélődik vagy a metrika szerint lejjebb kerül, és minden cél most az újabb alagúton halad. Az első kliens kapcsolódva marad, és továbbra is zöld ikont mutat, tehát az interfész aktív, miközben az útvonal eltűnt. Éppen a kapcsolati állapot és az útválasztási állapot szétválása teszi zavaróvá a viselkedést.

A kliensek egy közös tábla szerkesztői. Tudni, melyik módosítás történt utoljára, szinte minden tünetet megmagyaráz.

Olvassa ki, melyik alagút birtokolja az aktuális útvonalat

Ellenőrizze a tényleges döntést ahelyett, hogy a kapcsolódást jelentő kliensnek hinne. Kérdezze meg a rendszertől, melyik interfész vinné egy adott célállomást.

ip route get 10.20.0.5
route print -4

Az első parancs megnevezi az interfészt és a forrás címet egy célállomáshoz, és pontosan ez a kérdés érdekli. Az útvonal-lista Windows alatt megmutatja a versengő alapértelmezett bejegyzéseket és metrikáikat, így látja, melyik nyer éppen. Futtassa a keresést minden távoli hálózat egyik hosztjára, mert egy cél lehet helyes, miközben a másik hálózat elérhetetlen. Ha a válasz a rossz alagutat nevezi meg, az újracsatlakozás nem segít; az útválasztási házirendet módosítani kell.

Akadályozza meg, hogy a második kliens mindent igényeljen

Az egyik kliens birtokolja az alapértelmezett útvonalat, a másik csak a saját prefixeit vigye. OpenVPN a kliensek visszautasíthatják, amit a szerver rákényszerít.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull figyelmen kívül hagy minden rákényszerített útvonalat, míg a pull-filter ignore "redirect-gateway" csak az alapértelmezett útvonalra vonatkozó utasítást dobja el, és megtartja a rákényszerített DNS-t és más beállításokat. Válasszon köztük aszerint, mennyit akar még a szerver konfigurációjából, majd adja hozzá a második hálózatnak szükséges konkrét prefixeket. Tartsa szem előtt a DNS-t, mert az olyan alagút által rákényszerített feloldó, amely nem viszi a lekérdezéseket, semmit sem ad vissza. Teszteljen egy ismert hosztot minden hálózatban, és erősítse meg a forráscímet, amelyet a távoli fél lát.

Az átfedő alhálózatok nem kerülhetők el

Amikor mindkét hálózat ugyanazt a prefixet hirdeti, a kernel egy bejegyzést tart két különböző helyhez, és választania kell. Egy hosztútvonal nem tudja kitalálni a hiányzó megkülönböztetést, és a metrika módosítása sem. Számozza át az egyik oldalt, vagy fordíttassa le a távoli tartományt annak rendszergazdájával, hogy a prefixek különbözzenek. Ellenőrizze a valódi alhálózatokat, mielőtt a klienseket hibáztatná, mert egy otthoni router alapértelmezett 192.168.1.0/24-es tartománya gyakrabban ütközik irodai tartománnyal, mint bárki várná. Jegyezze fel mindkét tartományt a jegybe, hogy a következő változtatás ne hozza létre újra az átfedést.

Különítsen el két célt is: mindkét hálózat elérése útválasztási probléma, míg az alagutak láncolása adatvédelemért más tervezés, amelynél egy további üzemeltető van az útvonalon. Ne használja az egyiket a másik megoldására.