Адказы Linux VPN знікаюць? Праверце rp_filter і маршрут

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

Што вырашае праверка крыніцы

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

Важнае слова — праўдападобны. Пакет можа быць цалкам законным і ўсё ж не прайсці праверку, бо правяраецца не законнасць.

Чытайце фактычны рэжым, а не адно поле

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

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

Знайдзіце неадпаведнасць, перш чым змяняць праверку

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

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

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

Выбарчае ўмяшанне, якое можна абараніць

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

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

Трымайце IPv4 і IPv6 асобна

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

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