Чаму адказ OpenVPN па UDP прыходзіць з няправільнага адраса

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

Што бачыць кліент, калі крыніца змяняецца

UDP-сокет, не прывязаны да пэўнага лакальнага адраса, не мае фіксаванай крыніцы, таму ядро выбірае яе ў момант адпраўкі. Гэты выбар паходзіць з пошуку маршруту да адраса кліента, і крыніцай становіцца адрас таго інтэрфейсу, які выбраў пошук. На машыне з адным інтэрфейсам выбар незаўважны; на хасце з адрасам кіравання, публічным адрасам і другасным адрасам на той жа сеткавай карце ўсё залежыць ад маршрутных метрык і палітыкі. Маршрутызацыя на аснове палітык робіць неадпаведнасць больш імавернай, а не менш, бо правіла можа выбраць апорны канал, да якога кліент ніколі не даходзіў. Дастаткова маршруту па змаўчанні, атрыманага ад аднаго правайдара, разам з правілам крыніцы, якое паказвае на іншага.

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

Што насамрэч робіць опцыя multihome

Дырэктыва запісваецца як multihome у файле канфігурацыі і як --multihome у камандным радку, і яна прымушае UDP-сервер адказваць з таго адраса, да якога дайшоў пакет кліента. Ядро перадае зыходны адрас прызначэння як дадатковыя даныя пры прыёме, і OpenVPN выкарыстоўвае гэта значэнне як крыніцу для адказу. Такім чынам, сервер, які слухае на агульным адрасе, local 0.0.0.0 для IPv4 або яго эквівалент для IPv6, паводзіць сябе так, нібы кожны кліент дасягнуў асобнага слухача. Кліенты, якія прыйшлі праз публічны адрас, атрымліваюць адказы з публічнага адраса, а кліенты на ўнутраным адрасе — з таго адраса. Больш нішто на шляху пакета не рухаецца: маршрут, правілы фільтра і канфігурацыя тунеля застаюцца такімі, якімі былі.

Менавіта гэтая апошняя ўласцівасць робіць бяспечным даданне опцыі да сервера, які ўжо працуе, і яна ж тлумачыць, чаму опцыя не можа выправіць фільтр, які дазваляе толькі адзін адрас. Пакет па-ранейшаму мусіць быць прыняты на тым шляху, якім ідзе, таму выпраўленне крыніцы змяняе паходжанне адказу і нічога больш. Гэта таксама толькі для UDP: TCP-слухач не мае такой праблемы ў той жа форме, бо злучэнне вызначаецца чацвярыком, а не адрасам крыніцы адказу.

Калі фіксаваны лакальны адрас — няправільная прадвызначанасць

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

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

Дакажыце крыніцу адказу звонку

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

Маршрутызацыя, выяўленне і фільтраванне застаюцца асобнымі

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

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