Защо 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

След това повторете пингването, докато следите брояча на грешките. Надигащ се брой до заявка, която снемането вече показва, е подписът на това изхвърляне, а не на липсващ маршрут. Включете марсианско журналиране, докато сте там, за да назове ядрото източника и интерфейса, които е отхвърлило. Заедно те изключват шифъра, защитната стена и липсващ 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

Какво губи свободният режим и къде

Свободният режим все още отхвърля източник, до който никакъв маршрут не би стигнал, и спира да отхвърля подправен източник, който случайно е маршрутизируем. На лаптоп това е малка отстъпка. На устройство, което препраща чужд трафик, същият избор е много по-голяма. Затова една и съща настройка носи две много различни значения в зависимост от това къде работи.

Изключването на проверката напълно на хост, който препраща трафик за други хора, е единствената поправка, която трябва да се избягва. Нулата изхвърля проверката, която свободният режим внимателно пази. Ако хостът препраща за други, защитавайте вместо това варианта с правило за политика от предишния раздел.

Оставете бележка, която назовава двата интерфейса, застъпващия се префикс и точната проба, която сега успява. Това е по-полезно за следващия инженер от ред, който казва, че филтрирането е коригирано.