Potrebuje každý peer v OpenVPN riadok remote? Nie tak celkom

Dve konfigurácie peerov sa porovnávajú vedľa seba, jedna má riadok remote a druhá nie, a záver je, že jedna z nich je pokazená. Táto úvaha je dosť často chybná na to, aby stálo za to ju rozobrať. Direktíva opisuje, kam sa má poslať prvý paket. Nevyberá, či proces vystupuje ako klient, ktorý spojenie iniciuje, alebo ako brána, ktorá čaká, a nerozhoduje, ktorá strana preukazuje svoju identitu tej druhej.

Čo remote skutočne určuje

Záznam remote pomenúva hostiteľa, voliteľne port a transport a voliteľne niekoľko takých záznamov, ktoré sa skúšajú postupne.

Jeho neprítomnosť má určitý, nie neurčitý význam: proces čaká a nekoná na pakety z adresy, kým sa ten peer neautentizuje. Brána obsluhujúca roamingových používateľov preto nemá dôvod niektorého z nich vopred menovať.

Čítajte záznam ako vzťah adries. Či je vzdialený koniec dôveryhodný, odpovedajú certifikáty a možnosti overenia, nie skutočnosť, že bola zapísaná adresa.

Odpoveď určujú tri usporiadania

Roamingový klient potrebuje cieľ, pretože musí iniciovať a bez neho nevie, kde je brána. Brána pre mnoho klientov nepotrebuje cieľ pre každého používateľa, pretože klienti prichádzajú a autentizujú sa. Zámerné spojenie dvoch peerov so známymi koncami môže mať cieľ na jednej strane, na oboch stranách alebo na žiadnej, podľa toho, ktorá strana iniciuje.

Vloženie pevnej adresy klienta do všeobecnej brány je chyba, ktorá vyplýva z ignorovania týchto kategórií. Funguje pre jediný peer, ktorého adresa bola zaznamenaná, a všetkých ostatných zvádza.

Nič v direktíve nemení konfiguráciu na server pre mnoho klientov a nič v jej prítomnosti nebráni role servera. Referencia OpenVPN 2.6 dokumentuje voliteľné argumenty a správanie bez remote oddelene, čo je náznak, ako nezávislé sú.

Transportné roly sú iná os

Pri TCP jedna strana čaká a druhá vytáča spojenie. To sú samostatné direktívy od cieľa a ich zmiešaním vznikne pár, v ktorom buď obe čakajú, alebo obe vytáčajú.

Existuje aj rola TCP filtra zdroja, a preto je ploché tvrdenie, že server nikdy nesmie obsahovať remote, chybné.

Pri UDP niet čo nadväzovať, takže oba konce používajú zodpovedajúci transport UDP a direktíva len hovorí, kam mieriť. Zmeny adresy autentizovaného peera rieši vyhradené správanie, nie pridávanie ďalších záznamov. Správny transport je predpokladom toho, aby cieľ niečo znamenal, a zámena oboch vytvára konfigurácie, ktoré vyzerajú vierohodne a nikdy nedokončia handshake.

Prečo neprítomné remote nie sú otvorené dvere

Proces bez cieľa napriek tomu odmieta prevádzku od peerov, ktoré sa neautentizujú, a to je časť, ktorú ľudia prehliadnu, keď chýbajúci riadok čítajú ako poslucháča otvoreného komukoľvek.

Autentizácia a cieľ sú nezávislé a pre dôveru je dôležitá tá prvá.

Opačná chyba je nebezpečnejšia. Pevná zdrojová adresa môže pôsobiť ako riadenie prístupu, pretože je konkrétna a ľahko overiteľná, ale nepreukazuje nič o tom, kto je na druhom konci. Zachovajte overovanie certifikátov a kontroly identity, ktoré viažu certifikát k jeho role. Nahradiť ich zhodou adries znamená vymeniť skutočnú kontrolu za jej zdanie.

Zapíšte, čo konfigurácia predpokladá

Pre každú stranu zaznamenajte tri veci: ako sa prvý paket dostane k peerovi, ktorá strana môže prijať transport a čo každá strana o tej druhej overuje.

Tie predpoklady sú návrh. Direktívy sú len ich pravopis.

Ak sa oba súbory líšia, skontrolujte, či vyjadrujú rôzne predpoklady, namiesto toho, aby ste predpokladali, že jeden je nesprávny. Symetrická dvojica súborov nie je pre funkčný tunel ani nutná, ani postačujúca, a asymetria je často tou časťou, ktorá robí topológiu funkčnou.