Ці патрэбны кожнаму peer у OpenVPN радок remote? Не зусім

Дзве канфігурацыі peer параўноўваюцца побач: у адной ёсць радок remote, у другой няма, і выснова такая, што адна з іх зламаная. Гэтая выснова памылковая дастаткова часта, каб варта было яе разгледзець. Дырэктыва апісвае, куды павінен быць адпраўлены першы пакет. Яна не выбірае, ці дзейнічае працэс як кліент, што ініцыюе злучэнне, ці як шлюз, што чакае, і не вырашае, які бок даказвае сваю асобу іншаму.

Што насамрэч задае remote

Запіс remote называе хост, пры неабходнасці порт і транспарт, а таксама, пры неабходнасці, некалькі такіх запісаў, якія спрабуюцца па чарзе.

Яго адсутнасць мае пэўнае значэнне, а не няпэўнае: працэс чакае і не апрацоўвае пакеты з адраса, пакуль гэты peer не аўтэнтыфікуецца. Таму шлюз, які абслугоўвае вандроўных карыстальнікаў, не мае прычыны называць каго-небудзь з іх загадзя.

Чытайце запіс як адносіны адрасоў. Ці давяраць далёкаму боку, адказваюць сертыфікаты і параметры праверкі, а не сам факт запісанага адраса.

Тры схемы вызначаюць адказ

Вандроўнаму кліенту патрэбна прызначэнне, бо ён павінен ініцыяваць злучэнне і без яго не ведае, дзе шлюз. Шлюзу з многімі кліентамі не патрэбна прызначэнне для кожнага карыстальніка, бо кліенты прыходзяць і аўтэнтыфікуюцца. Наўмысная сувязь двух peer з вядомымі канцавымі пунктамі можа мець прызначэнне на адным баку, на абодвух баках або ні на адным — у залежнасці ад таго, які бок ініцыюе.

Устаўка фіксаванага адраса кліента ў агульны шлюз — гэта памылка, якая вынікае з ігнаравання гэтых катэгорый. Яна працуе для аднаго peer, чый адрас запісаны, і ўводзіць у зман усіх астатніх.

Нішто ў дырэктыве не ператварае канфігурацыю ў сервер з многімі кліентамі, і нішто ў яе наяўнасці не перашкаджае ролі сервера. Даведка OpenVPN 2.6 апісвае неабавязковыя аргументы і паводзіны без remote асобна, што намякае на іх незалежнасць.

Ролі транспарту — іншая вось

Для TCP адзін бок чакае, а другі набірае. Гэта асобныя дырэктывы ад прызначэння, і іх змешванне дае пару, якая або абедзве чакаюць, або абедзве набіраюць.

Ёсць таксама роля фільтра крыніцы TCP, і менавіта таму прамое сцвярджэнне, што сервер ніколі не можа ўтрымліваць remote, памылковае.

Для UDP няма злучэння, якое трэба ўстанавіць, таму абодва канцы выкарыстоўваюць адпаведны транспарт UDP, і дырэктыва кажа толькі, куды нацэльвацца. Змены адраса аўтэнтыфікаваным peer апрацоўваюцца спецыяльнымі паводзінамі, а не даданнем новых запісаў. Правільны транспарт — умова таго, што прызначэнне будзе мець сэнс, а блытаніна паміж імі стварае канфігурацыі, якія выглядаюць праўдападобна і ніколі не завяршаюць рукапацісканне.

Чаму адсутнасць remote — не адкрытыя дзверы

Працэс без прызначэння ўсё роўна адхіляе трафік ад peer, якія не аўтэнтыфікуюцца; гэта менавіта тое, што людзі прапускаюць, чытаючы адсутны радок як слухач, адкрыты для ўсіх.

Аўтэнтыфікацыя і прызначэнне незалежныя, і менавіта першае важна для даверу.

Зваротная памылка небяспечнейшая. Фіксаваны адрас крыніцы можа здавацца кантролем доступу, бо ён канкрэтны і яго лёгка праверыць, але ён нічога не даказвае пра тых, хто на другім канцы. Захоўвайце праверку сертыфікатаў і праверкі асобы, якія прывязваюць сертыфікат да яго ролі. Замена іх супадзеннем адрасоў абменьвае рэальны кантроль на яго падабенства.

Запішыце, што мяркуе канфігурацыя

Для кожнага боку запішыце тры рэчы: як першы пакет дасягае peer, які бок можа прыняць транспарт і што кожны бок правярае ў іншага.

Гэтыя дапушчэнні і ёсць дызайн. Дырэктывы — толькі іх напісанне.

Калі два файлы розняцца, праверце, ці яны выражаюць розныя дапушчэнні, а не мяркуйце, што адзін з іх няправільны. Сіметрычная пара файлаў не з’яўляецца ні неабходнай, ні дастатковай для працуючага тунэля, і асіметрыя часта і ёсць тое, што робіць тапалогію працаздольнай.