Асобны выхад: пул VPN на usb0, трафік шлюза на eth0

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

Пераканайцеся, што адрас крыніцы дажывае да рашэння аб маршрутызацыі

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

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

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

Пабудуйце выбраную табліцу, якая поўная

Табліца — гэта не маршрут па змаўчанні з сябрам. Ёй патрэбна дастаткова маршрутаў, каб кожны пошук вырашаўся ўнутры яе, уключаючы звязаны маршрут для падсеткі WAN, каб наступны хоп быў дасяжны. Для пула 10.77.0.0/24 на tun1, адраса WAN 203.0.113.20/24 з наступным хопам 203.0.113.1 і табліцы 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

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

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

Трымайце ўласны трафік слухача па-за палітыкай

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

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

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

Зрабіце так, каб перанакіраванне і трансляцыя ўзгадняліся з маршрутам

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

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

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

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

Вырашыце, што адбудзецца, калі usb0 знікне

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

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

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