Два адрасы службы на адным кліенце OpenVPN: iroute і lo

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

Псеўданім лакальны, уладанне — аддаленае

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

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

Трымайце два дыяпазоны асобна і ў сваіх нататках. Адрасы ў прыкладзе — дакументацыйныя значэнні, і перасячэнне іх з рэальнай LAN — найхутчэйшы спосаб прымусіць працоўную ўстаноўку выглядаць зламанай.

Дадайце адрас на кліенце пастаянна

Змесціце адрас службы на loopback з прэфіксам хоста, каб хост разглядаў яго як лакальны ўвод, а не як падсетку, да якой трэба дабрацца. ip address add 10.66.0.10/32 dev lo робіць гэта для аднаго адраса, а паўтор каманды для другога адраса мадэлюе дзве службы.

Запусціце гэта як разовы тэст, затым перанясіце ў тое, што валодае сеткавай канфігурацыяй хоста, бо даданне падчас выканання знікае пасля перазагрузкі, а дублікаты назапашваюцца паміж перападлучэннямі. Юніт systemd, упарадкаваны пасля сеткі, — адзін варыянт, а сеткавы мэнэджар дыстрыбутыва — другі. Што б вы ні выбралі, адрас павінен існаваць да таго, як прыкладанне звяжацца, інакш служба ўзнімецца на няправільным сокеце. Праверце з дапамогай ip address show dev lo пасля перазагрузкі, а не пасля ручной каманды.

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

Запатрабуйце яго ў файле CCD, які хаб сапраўды чытае

На серверы дэкларацыя ўладання ідзе ў файл кліента, выбраны аўтэнтыфікаваным агульным імем, унутры каталога, названага client-config-dir. Радок — iroute 10.66.0.10 255.255.255.255, адзін на адрас, і ён кажа серверу, які партнёр павінен атрымліваць трафік для гэтага прызначэння.

Дзве дэталі ламаюць гэта ціха. Імя файла павінна супадаць з імем, якое сервер сапраўды выкарыстоўвае, а яно адрозніваецца, калі задзейнічаны username-as-common-name. І iroute дзейнічае толькі ў рэжыме TUN з наладжаным каталогам канфігурацыі кліента, таму той жа радок нічога не робіць у маставым разгортванні. Дадавайце радкі ў існуючы файл, а не замяняйце яго, бо ён можа ўжо несці фіксаваны адрас або опцыі push. Даведнік OpenVPN 2.6 апісвае і каталог, і дырэктыву ўладання.

Уласнае ядро хаба таксама мае патрэбу ў шляху да гэтых прызначэнняў, каб лакальна згенераваны трафік трапляў у працэс тунеля. route 10.66.0.10 255.255.255.255 у канфігурацыі сервера пакрывае трафік, які паходзіць ад сервера, а іншым кліентам патрэбны push "route 10.66.0.10 255.255.255.255", каб даведацца пра прызначэнне самастойна.

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

Праверце палітыку ўводу і шлях адказу

Пакет, адрасаваны псеўданіму, прыходзіць на хост-уладальнік як лакальны ўвод, таму пытанне ў тым, ці дазваляе лакальны файрвол гэтую крыніцу і порт. Дазвольце канкрэтны порт службы з дыяпазону крыніц VPN замест адкрыцця ўсяго адраса.

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

Сачыце за другім праслухоўвальнікам на тым жа порце, прывязаным да іншага адраса, бо ядро дастаўляе таму сокету, які супаў, і вынікі выглядаюць выпадковымі. Праверце з дапамогай ss -lntp і пацвердзіце, што прывязаны адрас — гэта псеўданім службы. NAT крыніцы тут не патрабуецца, а яго даданне хавае ідэнтычнасць выклікальніка, ад якой залежаць вашыя журналы.

Тэстуйце адрасы і ўладанне асобна

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

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