Зашто 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

Чега се лабави режим одриче, и где

Лабави режим још одбија извор до којег ниједна путања не би стигла и престаје да одбија лажни извор који је случајно усмерљив. На преносном рачунару то је уска уступка. На уређају који прослеђује саобраћај који није његов, исти избор је много шири. Зато иста поставка носи два врло различита значења зависно од тога где ради.

Потпуно искључивање провере на домаћину који прослеђује саобраћај за друге људе је једина поправка коју треба избегавати. Нула одбацује проверу коју лабави режим пажљиво чува. Ако домаћин прослеђује за друге, залажите се уместо тога за опцију са правилом политике из претходног одељка.

Оставите белешку која именује два интерфејса, преклапајући префикс и тачан тест који сада успева. То је корисније следећем инжењеру од реда који каже да је филтрирање прилагођено.