Az OpenVPN még mindig régi útvonalakat küld? Nézze meg, mit töltött be

Hozzáad egy útvonalat, újraindítja a szolgáltatást, újracsatlakozik, és a kliens táblázata pontosan olyan, mint korábban. Két különböző dolog lehet igaz: a kiszolgáló nem töltötte be a módosítását, vagy a kliens nem telepítette, amit kapott. Csak a tünet közös bennük, ezért az első lépés annak kiderítése, melyik eset áll fenn.

Az alábbi összehasonlítás a folyamattól kifelé halad, mert a folyamat az egyetlen hiteles forrása annak, melyik fájl van érvényben.

A szerkesztett fájl és a fájl, amelyet a folyamat olvas

Kezdje az unitnál és a létrehozott parancssornál. systemd-gazdagépen a systemctl cat openvpn@server kiírja a ExecStart sort, az instance-unit pedig általában az instance nevéből vezeti le a konfigurációs útvonalát, így a openvpn@office néven indított démon más fájlt olvas, mint a openvpn@server néven indított. Hasonlítsa ezt a futó folyamat argv-jével. A konfigurációkezelő eszköz újabb módot ad a módosítás elvesztésére: írhat egy helyes fájlt olyan helyre, amelyet az unit soha nem említ, és akkor egy zöld telepítés úgy tűnik, mintha semmit sem tett volna.

Az időbélyegek gyorsan eldöntik: ha a fájl újabb, mint a folyamat indulási ideje, a folyamat nem olvashatta be. Az útválasztó firmware-je harmadik esetet ad hozzá, mert sok modell a flashben tartja a beállításait, és indításkor újraépíti a konfigurációt, ami a lemezen lévő fájl szerkesztését teljesen rossz réteggé teszi.

Mit küld a kiszolgáló és mit telepít a kliens

A küldött útvonalnak két szűrőn kell átjutnia. A kiszolgálón a betöltött konfigurációban kell lennie, nem kikommentelt blokkban vagy olyan kliensspecifikus fájlban, amelynek neve nem egyezik. A kliensen a pull-nek engedélyezve kell lennie, és egyetlen pull-filter sem dobhatja el az opciót. Csatlakozzon verbosity 4 mellett, és olvassa el a kliens által jelentett küldött opciókat: ha az útvonal szerepel a listán, a kiszolgáló megtette a dolgát, és a kliens dönt úgy, hogy nem telepíti.

A kliensspecifikus fájlok gyakori zavarforrások. A tanúsítvány common name-je alapján elnevezett fájl csak annak az egy kliensnek küld opciókat, és egyetlen karakter eltérése csendben megállítja a küldést, egyik oldalon sem jelentkezik hiba. A kiszolgáló naplózza a csatlakozáskor látott common name-et, ezért ezt az értéket a fájlnévhez hasonlítsa, ne ahhoz, amit a kliens nevének gondol.

A küldött előtag és a visszaútvonal különböző problémák

Az a kliens, amely szándékosan figyelmen kívül hagyja a redirect-gateway beállítást, hogy megtartsa helyi internetútvonalát, egy második, független rést hoz létre. A kiszolgáló próbái elérik az alagút címét, a válaszok mégsem érkeznek meg, mert a kiszolgáló alagút-IP-jére címzett válasz a kliens szokásos alapértelmezett átjáróján keresztül halad. Itt nem a küldött alhálózati útvonal a hibás; az hiányzik, ami a kiszolgáló alagúthálózatának forgalmát visszaküldi az alagút-eszközön.

Az útvonal hozzáadása a kliensen kijavítja a kiszolgáló által indított próbákra adott válaszokat. Nem helyettesíti a küldött alhálózati útvonalat, és fordítva is igaz, mert a kettő ellentétes haladási irányokat ír le.

Hasonlítsa össze a táblázatokat mindkét végén

Minden változtatás után csatlakozzon újra, és olvassa el a kliens táblázatát a küldött előtagra és az alagút-eszközre. Ezután teszteljen mindkét irányban: a klienstől a küldött alhálózat egy hosztjáig, és onnan vissza a klienshez. Az létező, de forgalmat nem vivő útvonal három dolog egyikét jelenti: a túloldal nem továbbít, a tűzfal eldobja a folyamot, vagy a válasznak nincs visszaútja.

Tartson három azonosítót együtt: a konfigurációs útvonalat, az unit vagy instance nevét és a teszteléshez használt kliens identitását.

Ez a három a következő esetet ötperces ellenőrzéssé teszi ismételt vizsgálat helyett, és pontosan erre van szüksége egy kollégának, amikor az alagút valaki más problémájává válik.

Az újraindítást túlélő útvonalprobléma gyakran egyáltalán nem útválasztási probléma; a hiba a táblázat felett van, amelyet folyton olvas.