Két OpenVPN kliens összefűzése egy Linux gazdagépen fwmarkkal

Ha egy Linux gazdagépre második OpenVPN klienst telepítünk, két hely egyikén sikertelen lesz. Vagy a belső kliens nem éri el a saját szerverét, mert a külső alagút elragadta azt a forgalmat, vagy a második kliens átírja az útvonaltáblát, és az első alagút leáll. Mindkét probléma az útvonalválasztásban van, nem a titkosításban, és mindkettő megoldódik, mielőtt az új alagút bármilyen alkalmazásforgalmat szállítana. A címek itt szemléltetésül szolgálnak: a tun0 a külső alagút, a 203.0.113.9 a belső szerver, és a TCP 9999 az a folyam, amelynek a belső útvonalat kell használnia.

Két hibaüzemmód, egy útvonaltábla

A belső kliens UDP-csatornát nyit a szerveréhez, és az a csatorna a jelenlegi útvonaltáblát követi, mint bármely másik. Ha a külső alagút már birtokolja az alapértelmezett útvonalat, a kézfogási csomagok a külső alagútba kerülnek. Ez csak akkor működik, ha a külső szerver eléri a belső szervert, és a túloldal vállalja a folyam szállítását; különben a kézfogás megakad, és a kliens újrapróbálkozik.

A második hiba a szerver push üzenetéből ered. A szokásos push a redirect-gateway def1, amely a 0.0.0.0/1 és a 128.0.0.0/1 címeket telepíti az alapértelmezett útvonal lecserélése helyett. Ezért a két kliens, amelyek külön-külön saját /1 párt telepítenek, ütköznek, és a legújabb pár nyer szinte minden célállomásnál. Keresse ezt a két előtagot a táblában, amikor egy alagút meghal, miután a második csatlakozott, mert lehet, hogy maga az alapértelmezett útvonal soha nem változott.

Jelölje meg a folyamot, és adjon neki táblát

Irányítsa a kiválasztott forgalmat úgy, hogy megjelöli a mangle táblában, és a jelölést egy házirend-szabályban egyezteti. A szabály egy dedikált táblára mutat, amelynek alapértelmezett útvonala a belső eszköz, így csak a megjelölt csomagok haladnak a belső útvonalon.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

A szabálykészlet hibáinak többsége két tévedésből ered. A tűzfal által beállított jelölésértéknek és a szabály által egyeztetett értéknek azonosnak kell lennie, mert az eltérés sem hibát, sem hatást nem okoz. A PREROUTING pedig csak a kívülről érkező csomagokat látja, ezért az ezen a gazdagépen indított kapcsolatnak ugyanilyen egyeztetésű OUTPUT szabályra van szüksége, mielőtt egyáltalán megjelölnék.

Vegye el az útvonalak tulajdonjogát a második klienstől

Két lehetőség akadályozza meg, hogy a második kliens szerkessze a táblát, és ezek különböző pontokon hatnak. A route-nopull figyelmen kívül hagyja a pusholt útvonal-beállításokat, így semmi nem települ. A route-noexec elfogadja a pusholt beállításokat a kliens környezetében, de a tábla módosítását egy hookra bízza, és ezt akkor szeretné, amikor látnia kell, mit ajánlott a szerver.

A hook a pusholt értékekkel fut a környezetében, és csak az Ön által jóváhagyott bejegyzéseket adhatja hozzá. Tegye idempotenssé: az újraépítés előtt ürítse ki a birtokában lévő táblát, és ne feltételezze, hogy az előző futás tiszta állapotot hagyott. Az újracsatlakozás újra meghívja a hookot, a tisztítás nélkül hozzáfűző hook pedig duplikált útvonalakat halmoz fel.

Válasszon egy tulajdonost, és írja le. Az a profil, amely mindkét beállítást megadja, vagy az a hook, amely verseng egy kézi szkripttel, olyan táblát eredményez, amelyet senki nem tud később megmagyarázni.

Rögzítse mindkét szerver címét

A belső szervernek hosztútvonalra van szüksége a külső eszközön át, mielőtt a belső kliens csatlakozik. Ez a bejegyzés tartja a belső forgalmat a külső alagúton belül, ahelyett hogy hagyná az alapértelmezettet követni.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Adjon hozzá megfelelő hosztútvonalat a külső szerverhez is a fő táblában, különben az újracsatlakozás a külső kliens saját forgalmát a saját alagútjába irányíthatja. A sorrend nem választható: ezeket a bejegyzéseket azután adja hozzá, hogy a vonatkozó interfész létezik, ami hookot vagy a csatlakozás után futó szkriptet jelent. A lekapcsolt eszközre mutató útvonal eltávolításra kerül vagy figyelmen kívül marad, ezért a rendszerindításkor írt bejegyzés nem éli túl a feltételezett sorrendet.

Ellenőrizze a keresést a teljes tábla olvasása helyett. Az útvonal-keresés kimenete megnevezi az eszközt és a forrás-címet, amelyet a kernel használni fog, és a kliens pontosan ezt kapja, amikor megnyitja a csatornáját.

Tesztelje a láncot, és tegye láthatóvá a hibát

Rögzítsen a külső interfészen, miközben a belső kliens csatlakozik. A belső kézfogásnak titkosított hasznos teherként kell megjelennie a külső alagútban; ha sima UDP-ként jelenik meg a 203.0.113.9 felé, akkor a hosztútvonal hiányzik, és a lánc soha nem épült fel.

A legrosszabb eredmény az a lánc, amely csendben visszaáll a fizikai uplinkre, mert az interfész állapota semmit nem jelez, és a belső forgalom a rossz forrás-címről indul. Ha a második kliens közvetlenül újracsatlakozhat, amikor a külső alagút leesik, tiltsa le azt az útvonalat, vagy kösse a külső interfészhez, hogy a hiba látható legyen.

Fejezze be két folyamattal és egy szabálykiírással: a megjelölt és a jelöletlen kapcsolatnak különböző útvonalon kell haladnia, és az ip rule show-nak fel kell sorolnia a szándékolt prioritást. Ha mindkét folyam ugyanazt az útvonalat használja, a jelölés nem ott érvényesül, ahol gondolja.