Два шлюзы, адзін VPN: чаму OpenVPN выбірае няправільны канал уверх

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

Адрас тунэля — не канчатковы пункт

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

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

Знайдзіце адрас, да якога кліент сапраўды падключыўся

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

Замацуйце канчатковы пункт і прачытайце парадак палітыкі

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

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

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

ip rule show
ip route get 203.0.113.40

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

Калі канчатковы пункт зрушваецца

Імя хоста, якое вырашаецца ў некалькі адрасоў, робіць пастаянны /32 несапраўдным, як толькі адказ змяняецца. Профіль з некалькімі радкамі remote мае тую ж праблему, бо кліент можа апынуцца на любым з іх. Абнаўляйце маршрут з уласных перахапляльнікаў жыццёвага цыклу кліента замест таго, каб дадаваць яго ўручную. Скрыпт up, які чытае ўзгоднены суразмоўцу і ўсталёўвае маршрут да хоста, трымае выключэнне ў адпаведнасці з рэальнасцю, а адпаведны скрыпт down выдаляе яго.

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

Трымайце ўнутраную палітыку асобна

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

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

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