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

Што се откажува лабавиот режим, и каде

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

Целосното исклучување на проверката на домаќин што проследува сообраќај за други луѓе е единствената поправка што треба да се избегне. Нулата ја фрла проверката што лабавиот режим внимателно ја чува. Ако домаќинот проследува за други, наместо тоа залагајте се за опцијата со правило за политика од претходниот дел.

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