Egy Pi, két OpenVPN-példány: mit olvas az egyes egységek

Számolja meg az OpenVPN-folyamatokat, mielőtt hozzányúl egy profilhoz. Az a Pi, amely roaming felhasználókat fogad, és egyben egy felsőbb szolgáltatást is tárcsáz, két démont futtat, és mindegyikük azt a konfigurációs fájlt olvassa, amelyet a beírt példánynév választ ki. A csomagolt sablonok ezután minden démonnak saját munkakönyvtárat, saját futásidejű állapotfájlt és saját alagúteszközt adnak. Ha ezt a felosztást elrontja, egy estét azzal tölt, hogy egy helyes beállítást módosít egy olyan fájlban, amelyet a futó folyamat soha nem nyit meg.

Minden példánynév a saját fájlját választja

Az OpenVPN 2.6-tal szállított egységfájlokban az indítási argumentumok egy példány-helyőrzőt hordoznak, amelyet a @ jel utáni szöveg tölt ki. A szerver sablon a szerver konfigurációs könyvtárából fut, és az argumentumát ott a %i.conf fájlhoz rendeli, míg a kliens sablon ugyanezt a kliens könyvtárából teszi. Így a [email protected] a admits.conf fájlt olvassa a szerver könyvtárában, és a [email protected] a uplink.conf fájlt olvassa a kliens könyvtárában, és a két név egyike sem jelent semmit a másik könyvtárban.

Erősítse meg a hozzárendelést a gépen, ahelyett hogy feltételezné, hogy a csomag megtartotta a felsőbb szint alapértelmezéseit. Egy disztribúciós drop-in jogosult a munkakönyvtár vagy a konfigurációs argumentum közvetlen lecserélésére.

systemctl cat [email protected]
systemctl cat [email protected]

Olvassa el a WorkingDirectory sort és a konfigurációs argumentumot abban a kimenetben, mert csak az engedélyezett egység dönti el, melyik fájl töltődik be. Az a drop-in, amely --config -t hozzáfűzi a ExecStart sorhoz, akkor is legyőzi a sablont, ha a sablon útvonala helyesnek tűnik. Kérdezze meg a fragmentum és a drop-in útvonalait, ha tudni akarja, hogy játékban van-e helyi felülírás. Ha mindkét szerep egy fájlra oldódik fel, egyetlen folyamata van, amely egyszerre próbál szerver és kliens lenni, és a fájl későbbi beállítása csendben nyer.

A helyi szállítás és a továbbított hasznos teher különböző horgokat ér el

A szerver titkosított kapcsolata minden roaming felhasználóval magán a Pi-n jön létre, ezért külső válaszai a helyi kimeneti horgon keresztül lépnek ki. A kliens kapcsolata a felsőbb partnerével szintén helyben létrehozott kimenet, bár eléri a távoli hálózatot. A továbbított hasznos teher egy harmadik kategória, és a kernel csak azután párosítja, hogy már kiválasztotta a csomag kimeneti eszközét.

A továbbítási láncon belül kimenő interfészre illeszkedő szabály engedélyezhet vagy eldobhat egy csomagot, amelyet az útválasztás már ehhez az interfészhez rendelt, de soha nem választja ki az interfészt. Amikor az egyik gazdagép lezár egy alagutat és elindít egy másikat, a felhasználói forgalmat a felsőbb alagútba küldő szabály és a Pi saját titkosított válaszait védő szabály külön döntések. Véletlenül ugyanarra a fizikai hálózati kártyára kerülnek, ezért keverik össze őket.

Ez a különbség magyaráz egy gyakori félhibát. A felhasználók csatlakoznak, a kézfogás befejeződik, és a forgalmuk mégis rossz irányba indul, mert a kézfogás helyi volt, a hasznos teher pedig továbbított, és csak a kettő egyikét tesztelték valaha.

Egy importált útvonal elnyelheti a felhasználóinak szóló válaszokat

A kliensprofil biztonsági beállítása dönti el, mit tolhat a felsőbb fél a Pi útválasztási táblájába, és a széles átirányítás az a lehetőség, amely egy működő kettős szerepű gazdagépet tönkretett gazdagéppé változtat. Ha a betolt útvonal lefedi a roaming felhasználók nyilvános címeit, a szerver által nekik generált válaszok a háttérhálózaton való kilépés helyett követhetik az új útvonalat a felsőbb alagútba. Az emberek gyakran megerősítik, hogy a szolgáltatóhoz vezető alagút még működik, és ott megállnak, mert ez a forgalom magának az alagútnak a szállítása, és tovább folyik, miközben minden más rosszul viselkedik.

A forrás- vagy jelölésalapú szabály az, ahogy a két adatfolyam elkülönül. Az OpenVPN Linux jelölési lehetősége ellátja a démon saját titkosított csomagjait egy tűzfaljelöléssel, amelyet egy útválasztási szabály aztán egy dedikált táblába küldhet. A forráscímek ugyanolyan jól működnek, ha a szerver külső válaszai mindig egyetlen háttércímről indulnak. Mindkét megközelítésnek érvényes útvonalak kellenek a kiválasztott táblában, és kivétel a szolgáltató végpontjára, különben maga az alagút sem jön fel.

Kérdezze meg a kernelt, milyen útvonalat venne egy válasz valójában, mielőtt bármilyen szabályt ír. Az alábbi címek helyőrzők a Pi háttércíméhez és egy roaming felhasználó nyilvános címéhez.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Ellenőrizze a felosztást, majd állítson le egy szerepet egyszerre

Három adatfolyamot külön teszteljen, mert egy működő kézfogás semmit nem bizonyít a másik kettőről. Fogadjon el egy új bejövő kapcsolatot, küldjön el egy engedélyezett alkalmazást a felsőbb kimeneten, és erősítse meg, hogy mindkét folyamat továbbra is eléri a saját partnereit.

Aztán állítsa le a kliens szerepét, és figyelje, mit tart meg a szerver szerepe. Ez a legolcsóbb módja annak, hogy megtaláljon egy útvonal- vagy jelölésszabályt, amelyet egy példánynak szántak, és mindkettőre alkalmaztak.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Amit látni szeretne, az a továbbra is kötött figyelő, a továbbra is jelen lévő alagúteszköz, és a napló új hibák nélkül, miközben a kliens szerep le van állítva. Ha az ügyfél leállítása a szerver válaszait is elvágja a meglévő felhasználók felé, a két szerep olyasmit oszt meg, amit az egyikre kellett volna korlátozni. Jegyezze fel, melyik példányt, melyik konfigurációs fájlt és melyik forgalomtulajdonost érintette az egyes változtatás, mert a következő ember, aki ezt a gazdagépet hibakeresi, különben ugyanazt a felfedezést ismétli meg nulláról.