Як запісаць канчатковы пункт IPv6 у канфігурацыі VPN

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

Праверце тып поля, перш чым уводзіць адрас

Для поля WireGuard Endpoint з портам літарал IPv6 выкарыстоўвае дужкі вакол адраса, напрыклад [2001:db8::10]:51820. Прэфікс дакументацыі ў гэтым прыкладзе не з’яўляецца публічным серверам, і дужкі — частка сінтаксісу, а не адраса.

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

Бярыце літарал у дужкі, калі порт знаходзіцца ў тым жа полі

Правіла простае: дужкі з’яўляюцца, калі ў той жа радок ідзе порт. Яны не з’яўляюцца, калі адрас стаіць адзін у полі без порта.

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

Асобныя палі адраса і порта

Калі кліент дае вам два палі, змясціце адрас у адно, а порт у другое. Аб’яднаная форма, устаўленая ў поле адраса, дае памылку разбору або, што горш, адрас, які вырашаецца ў нешта непажаданае.

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

Асцярожна абыходзьцеся з ідэнтыфікатарамі зоны

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

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

Спачатку праверце разбор, потым дасяжнасць

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

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

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