MULTI: hibás forrásoldali cím az ügyféltől: kié volt ez a cím?

A kiszolgáló naplója kiírja a következőt: MULTI: bad source address from client, eldobja a csomagot, és a munkamenet kapcsolva marad. Ez a kombináció összezavarja azokat, akik az üzenetet hitelesítési hibaként olvassák. Nem az: az ügyfél hitelesítette magát, és a megérkezett csomag olyan belső forráscímet hordozott, amelyet a kiszolgáló nem tudott ehhez az ügyfélpéldányhoz kapcsolni. Az ellenőrzés a kézbesítés előtt történik, ezért tűnik egészségesnek az alagút, miközben semmi hasznos nem halad át rajta.

Mit hasonlít össze a kiszolgáló a kézbesítés előtt

Minden ügyféltől érkező csomagnál a felhasználói térben futó kiszolgáló az alagúton belüli forráscímre néz, és megkérdezi belső útválasztási állapotát, melyik ügyfélhez tartozik ez a cím. Ha a tulajdonos egy másik példány, vagy egyáltalán nincs tulajdonos, a csomag eldobódik, és a figyelmeztetés kiadódik.

Az alagút interfészén keresztüli szokásos kézbesítés soha nem történik meg.

Ez a sorrend magyaráz egy részletet, amely megzavarja az embereket: a gazdagép tűzfalának számlálói nem mozdulnak, mert a csomag soha nem érte el a tűzfalat. A fordított útvonal szűrésének állítása a gazdagépen itt semmit nem változtat, mivel az elutasítás a démon saját társítás-ellenőrzésében történt. Olvassa az üzenetet a tulajdonra vonatkozó állításként, majd derítse ki, a három helyzet közül melyik hozta létre.

Egy nem illeszkedő belső cím három forrása

Az ügyfél olyan címről küldhet, amelyet nem neki osztottak ki, olyan hálózatról, amelyet senki nem nyilvánított az övének, vagy olyan identitás másolatáról, amelynek már van tulajdonosa. Mindhárom ugyanazt a naplósort eredményezi. Abban különböznek, hogy mit kell változtatnia. Kezdje a címmel és az aktuális hozzárendelési listával, és hagyja, hogy ez a két tény válassza ki az esetet.

Megkülönböztetésük két tényhez kötött: a naplóban elutasított címhez és azokhoz a hozzárendelésekhez, amelyeket a kiszolgáló aktuálisnak tart. A második a futó példány állapot- vagy kezelőnézetében érhető el, és ez az egyetlen érdemi tekintély, mert a konfigurációs fájl szándékokat rögzít, nem a jelenlegi állapotot.

Jegyezze fel mindkettőt, mielőtt bármit módosít, majd osztályozzon. Az utána készített képernyőkép nem a figyelmeztetést kiváltó állapot rögzítése. Őrizze meg az időbélyeget is, mert a hozzárendelések munkamenetek között mozognak.

Az ügyfél mögötti LAN és az iroute

Amikor egy telephelyi ügyfél a saját privát hálózatát irányítja, azt a hálózatot az ügyfélhez tartozóként kell deklarálni. Az iroute bejegyzést tartalmazó ügyfélspecifikus fájl ezt teszi meg, és a bejegyzés megnevezi azt az előtagot, amelyet az ügyfél szállíthat.

Az ugyanazt az előtagot az alagútra irányító kernelútvonal külön követelmény, és hozzáadása semmit nem változtat a démon belső tulajdonán.

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Erősítse meg, hogy a tényleges identitás megegyezik a fájlnévvel, mert az eltérés azt jelenti, hogy a fájl soha nem töltődik be, és a tünet azonos a hiányzó bejegyzéssel. Ne adjon hozzá széles iroute-ot a figyelmeztetés elnémításához, mert az egy váratlan forrást engedélyezetté tesz anélkül, hogy megválaszolná, miért küldte az ügyfél. Az OpenVPN 2.6 kézikönyv külön kontrollként dokumentálja az iroute-ot, a duplicate-cn-t és az identitásleképezést.

Ugyanaz az identitás két gépen

A második laptopra másolt profil ugyanazt a tanúsítványt és ugyanazt a közös nevet hordozza. A kiszolgáló beállításaitól függően az újabb kapcsolat kiválthatja a régebbit, és a társítás-ellenőrzést az a példány nyeri, amelyik a tulajdont birtokolja.

Emiatt a hiba szakaszosnak tűnik, és csak akkor jelenik meg, ha mindkét eszköz ébren van.

A duplikált közös nevek engedélyezése mindkettőt beengedi, de nem ad nekik független statikus címeket vagy független tulajdont. Ha két eszköznek együtt kell léteznie, külön regisztrálja őket, hogy mindegyiknek saját identitása és saját hozzárendelése legyen. A duplikátumbeállítás javításként kezelése a figyelmeztetésre a rejtélyt a helyén hagyja, és hozzáad egy másodikat.

Bizonyítsa, hogy a társítás megváltozott

Alkalmazza a javítást a konfiguráció tulajdonosán keresztül, majd csatlakoztassa újra az érintett ügyfelet, hogy az új házirend betöltődjön.

Ismételje meg ugyanazt a folyamatot, és erősítsen meg három dolgot: a csomag belső forrását, az ügyfélpéldányt, amelyhez a kiszolgáló társítja, és a cél viselkedését utána.

Ha a figyelmeztetés megszűnik, de az alkalmazás továbbra is hibázik, a probléma elmozdult, nem eltűnt. A továbbítás, a tűzfalszabályok és a visszaút külön szakaszok, és a társítás-ellenőrzés átlépése csak azt jelenti, hogy a csomag elhagyhatta az alagutat.