Potřebuje každý peer v OpenVPN řádek remote? Ne tak docela
remote určuje, kam jde první paket; nevybírá roli klienta, serveru ani TLS. Přečtěte si uspořádání, než ho zkopírujete na obě strany.
Dvě konfigurace peerů se srovnávají vedle sebe, jedna má řádek remote a druhá ne, a závěr je, že jedna z nich je rozbitá. Tato úvaha je dost často chybná, aby stálo za to ji rozebrat. Direktiva popisuje, kam se má první paket poslat. Nevybírá, zda proces vystupuje jako klient, který spojení iniciuje, nebo jako brána, která čeká, a nerozhoduje, která strana prokazuje svou identitu té druhé.
Co remote skutečně určuje
Záznam remote pojmenovává hostitele, volitelně port a transport a volitelně několik takových záznamů, které se zkoušejí postupně.
Jeho nepřítomnost má určitý význam, nikoli neurčitý: proces čeká a nezpracovává pakety z adresy, dokud se tento peer neautentizuje. Brána obsluhující roamingové uživatele proto nemá důvod některého z nich předem jmenovat.
Čtěte záznam jako vztah adres. Zda je vzdálený konec důvěryhodný, odpovídají certifikáty a možnosti ověření, nikoli skutečnost, že byla zapsána adresa.
Odpověď určují tři uspořádání
Roamingový klient potřebuje cíl, protože musí iniciovat a bez něj neví, kde brána je. Brána pro mnoho klientů nepotřebuje cíl pro každého uživatele, protože klienti přicházejí a autentizují se. Záměrné spojení dvou peerů se známými koncovými body může mít cíl na jedné straně, na obou stranách nebo na žádné, podle toho, která strana iniciuje.
Vložení pevné adresy klienta do obecné brány je chyba, která plyne z ignorování těchto kategorií. Funguje pro jediný peer, jehož adresa byla zaznamenána, a všechny ostatní mate.
Nic v direktivě nemění konfiguraci na server pro mnoho klientů a nic v její přítomnosti nebrání roli serveru. Reference OpenVPN 2.6 dokumentuje volitelné argumenty a chování bez remote odděleně, což je náznak, jak nezávislé jsou.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Transportní role jsou jiná osa
U TCP jedna strana čeká a druhá vytáčí spojení. To jsou samostatné direktivy od cíle a jejich smícháním vznikne pár, který buď oba čeká, nebo oba vytáčí.
Existuje také role TCP filtru zdroje, a proto je ploché tvrzení, že server nikdy nesmí obsahovat remote, chybné.
U UDP není co navazovat, takže oba konce používají odpovídající transport UDP a direktiva jen říká, kam mířit. Změny adresy autentizovaného peera řeší vyhrazené chování, nikoli přidávání dalších záznamů. Správný transport je předpokladem toho, aby cíl něco znamenal, a záměna obojího vytváří konfigurace, které vypadají věrohodně a nikdy nedokončí handshake.
Proč nepřítomné remote nejsou otevřené dveře
Proces bez cíle přesto odmítá provoz od peerů, kteří se neautentizují, a to je část, kterou lidé přehlédnou, když chybějící řádek čtou jako posluchače otevřeného komukoli.
Autentizace a cíl jsou nezávislé a pro důvěru je důležitá ta první.
Opačná chyba je nebezpečnější. Pevná zdrojová adresa může působit jako řízení přístupu, protože je konkrétní a snadno ověřitelná, ale neprokazuje nic o tom, kdo je na druhém konci. Zachovejte ověřování certifikátů a kontroly identity, které vážou certifikát k jeho roli. Nahradit je shodou adres znamená vyměnit skutečnou kontrolu za její zdání.
Zapište, co konfigurace předpokládá
Pro každou stranu zaznamenejte tři věci: jak se první paket dostane k peerovi, která strana může přijmout transport a co každá strana o té druhé ověřuje.
Tyto předpoklady jsou návrh. Direktivy jsou jen jejich pravopis.
Pokud se oba soubory liší, zkontrolujte, zda vyjadřují různé předpoklady, místo abyste předpokládali, že jeden je špatně. Symetrická dvojice souborů není pro funkční tunel ani nutná, ani dostačující, a asymetrie je často tou částí, která dělá topologii funkční.