Праграма прывязана да інтэрфейсу? Яе шлях праз VPN не стандартны

Адна праграма на машыне выходзіць праз VPN, а другая не, і абодва карыстальнікі клянуцца, што нічога не мянялі. Розніца часта ў рашэнні аб прывязцы, якое прымае сама праграма: сокет, прывязаны да прылады, адрас крыніцы, выбраны да злучэння, або прастора імёнаў з уласнай табліцай маршрутызацыі. Кожнае з гэтага змяняе шлях, які ўжываецца, і ніводнае не відаць у звычайнай IP-праверцы браўзера.

Тры розныя прывязкі, тры розныя вынікі

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

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

Вызначце, што праграма насамрэч усталёўвае

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

У Linux опцыі сокета, такія як SO_BINDTODEVICE, маюць апісаныя межы і патрабаванні да правоў, і непрывілеяваны працэс можа наогул не здолець іх усталяваць. Гэтае абмежаванне — карысная падказка: калі опцыю нельга прымяніць, праграма, верагодна, не з’яўляецца крыніцай розніцы.

Палітычная маршрутызацыя чытае крыніцу

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

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

Раздзелены тунель і дапаможныя працэсы

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

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

Праверце ўласны шлях праграмы

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

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