Одговори 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>

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

Нађите неслагање пре него што промените проверу

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

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

Не искључујте провере извора глобално као прву реакцију. То мења конкретну дијагнозу за широку промену понашања које ћете касније морати да памтите.

Селективно прилагођавање које можете да браните

Ако је уско прилагођавање заиста потребно, ограничите га на интерфејс којем је потребно, запишите зашто, и ставите га у конфигурацију која поседује тај интерфејс да преживи поновно покретање. Затим поново тестирајте тачно онај ток који није успео, од истог извора до исте дестинације, уместо ping-а ка нечему згодном.

Укључите случај који и даље треба да буде одбијен. Ако тај случај сада успе, прилагођавање је ослабило више од једног пута који сте хтели да поправите.

Држите IPv4 и IPv6 одвојено

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

Запишите режим, интерфејс, излаз тражења руте и разлог промене на једном месту. Следећа особа ће наћи поставку и никакво објашњење, и или ће је уклонити или ће је копирати тамо где јој није место.