Чаму VPN-кліент у офіснай лакальнай сетцы губляе кожны адказ

Ноўтбук сядзіць у офіснай сетцы /24 праз Ethernet і адначасова далучаецца да сервера OpenVPN, які жыве ў той жа /24. Калега пінгуе адрас тунеля; запыт відавочна даходзіць, а ў адказ не прыходзіць нічога. Журнал тунеля чысты, агляданне сайтаў працуе, значыць тунель — няправільны падазроны. Праверка крыніцы IPv4 на машыне, якая прымае, адкідае пакет, перш чым што-небудзь яго прачытае.

Адкіданне адбываецца раней, чым што-небудзь прачытае пакет

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

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

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

Дакажыце рэжым, які дзейнічае, перш чым чапаць sysctl

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

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

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

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

Што кожны рэжым rp_filter фактычна прымае

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

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

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

Выберыце найменшую змену, якая здымае двухсэнсоўнасць

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

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

Які б шлях вы ні выбралі, запішыце яго ў файл sysctl drop-in, а не ў жывую каманду. Задайце ключы all і default разам, каб перападключэнне не магло ціха вярнуць строгі рэжым.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Што нястрогі рэжым губляе і дзе

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

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

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