Szerver vagy kliens: melyik OpenVPN-egység a kettős szerepű Pi-n

Egy Pi-n két OpenVPN-folyamat fut, amely egyszerre fogadja a barangoló felhasználókat és ér el egy felső szolgáltatót, és a hardveren kívül szinte semmit nem osztanak meg. Az egyik a bejövő alagutakat figyeli, a másik kifelé tárcsáz. Mindegyik a saját könyvtárát olvassa, és mindegyiknek megvan a maga hibaállapota. A rossz egység újraindítása a leggyakoribb módja annak, hogy egy kliensjavítás végül a figyelőt borítja fel.

Párosítsa az egység nevét az általa betöltött könyvtárral

Az Upstream 2.6 két sablonegységet szállít, [email protected] és [email protected]. A szerver sablon a /etc/openvpn/server könyvtárban indul, és onnan tölti be a %i.conf fájlt. A kliens sablon a /etc/openvpn/client könyvtárban indul. Egy roaming nevű példány létezhet egyszerre mindkét helyen, szerverként és kliensként, két független konfigurációval és a karakterláncon kívül semmilyen kapcsolat nélkül köztük.

A fájlrendszer helyett a systemd-t kérdezze, mert a csomagolók olyan kiegészítő fájlokat adnak hozzá, amelyek megváltoztathatják a munkakönyvtárat vagy a bináris által kapott argumentumokat.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Az első parancs minden létrehozott egységet felsorol, beleértve azokat is, amelyek meghiúsultak és betöltve maradtak. A második kiírja az egységfájlt bármilyen felülírással együtt. A harmadik a leggyorsabb módja annak, hogy lássa azt a két tényt, amely eldönti a kérdést: a könyvtárat, amelyben a folyamat indul, és a neki átadott konfigurációs útvonalat.

A csomagok iránya döntsön, ne az interfész neve

Egy szerverpéldány figyelő sockettel rendelkezik, és kapcsolatokat fogad. A titkosított átvitele helyi bemenet és helyi kimenet a Pi-n, míg a felhasználók számára továbbított forgalom a továbbítási útvonalat követi, és más szabálykészletnek engedelmeskedik. Egy klienspéldánynak ebben az értelemben nincs figyelője: egy társat tárcsáz, ezért a titkosított átvitele helyi kimenet az alsó réteg felé.

Ez a különbség megmondja, hová tartozik egy szabály. A továbbítási láncon belüli interfészhez illő szabály csak azt a forgalmat engedi, amelyet az útválasztás már kiválasztott; soha nem választ útvonalat. Amikor egy barangoló felhasználó csomagjai a rossz úton lépnek ki, a vizsgálandó lánc a forward, nem az output.

Nézze meg a socketeket, mielőtt elméleteket gyárt. Az udp/1194-hez kötött szerver figyelő socketet mutat. A kliens a szolgáltató címéhez való társítást mutat, és semmit, ami figyelne.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Az egyik példány alapértelmezett útvonala elkaphatja a másik válaszait

A felső kliens által tolt redirect-gateway alapértelmezett útvonalat telepít, amely verseng minden mással a gépen, beleértve azokat a válaszokat, amelyeket a szerver a barangoló felhasználóknak küld. Az OpenVPN kivételt képez a saját társ-címére, hogy az alagút elérhető maradjon, de ez a kivétel semmit nem mond egy szállodai hálózaton ülő telefonról.

A tünet általában aszimmetrikus. A kézfogás befejeződik, a kliens kapcsolódottnak jelentkezik, és a forgalom az első válaszcsomag után meghal. A forrásalapú házirend-útválasztás vagy a szerverpéldányon --mark segítségével beállított csomagjelzés külön tartja a két folyamot; egyik sem teljes szabálykészlet önmagában, és mindkettőnek érvényes útvonalakra van szüksége abban a táblában, amelyet választanak.

A helyi döntést tesztelje, ne az alagút állapotát, mert a kernel a forrást és az interfészt azelőtt választja ki, hogy az OpenVPN látná a csomagot.

ip route get 203.0.113.44
ip rule show

Indítson újra egy szerepet, és bizonyítsa, hogy a másik túlélte

A sorrend számít, amikor mindkét szerep ugyanattól az alsó rétegtől függ. Először a klienst indítsa újra, ha a felső útvonalnak léteznie kell ahhoz, hogy a felhasználói forgalom továbbítható legyen, és először a szervert indítsa újra, amikor csak a figyelőjét vagy a készletét változtatja. Mindenképpen erősítse meg utána mindkét egységet, mert egy sikertelen újraindítás a másik szerepet elavult állapottal hagyhatja futni.

Írja le a leállási feltételt a változtatás előtt: a felső alagút elvesztése blokkolja a barangoló felhasználókat, vagy visszaesik a Pi saját felső linkjére? A DNS-nek és az IPv6-nak is egyértelmű válasz kell, mert a tolt feloldó gyakran túléli azt az útvonalat, amely hasznossá tette.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Csak akkor fogadja el a változtatást, ha három dolog egyszerre teljesül: egy új bejövő kapcsolat létrejön, egy továbbított alkalmazás eléri célját a tervezett kijáraton keresztül, és mindkét folyamat még mindig jelenti a várt társát. Ha a három közül egy meghiúsul, a rossz példányt vagy a rossz útvonalat változtatta meg, és a következő lépés az egység újraolvasása, nem pedig valami más újraindítása.