Зошто net.ipv4.conf.default.forwarding го остава tun0 недопрено

Поставивте net.ipv4.conf.default.forwarding=1, го рестартиравте VPN, а тунелот сè уште ги фрла пакетите што портата треба да ги рутира. Поставката изгледа исправна во датотеката, а интерфејсот сè уште известува дека проследувањето е исклучено. Ништо не е скршено: ја сменивте вредноста што ја наследуваат идните интерфејси, а не онаа што ја користи активниот тунел.

Поминете го ова на домаќинот што го поседува тунелот, во мрежниот namespace каде тунелот навистина постои. Контејнер или мрежен namespace може да го држи интерфејсот додека домаќинот покажува други броеви.

Читајте ги трите вредности заедно

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Чест резултат е ip_forward = 0, default.forwarding = 1 и tun0.forwarding = 0. Првите две не се согласуваат за улогата на домаќинот, а третата покажува што интерфејсот навистина прави. Таа комбинација одговара на домаќин што никогаш не бил конфигуриран како рутер, туку добил само вредност од шаблон. Трите броја не си противречат; тие одговараат на три различни прашања. Ниту запишувањето на вредноста од шаблонот не ја одлучува улогата на домаќинот.

Зошто се поместува токму глобалниот прекинувач

net.ipv4.ip_forward е контролата за целата порта. Неговата промена ги ажурира поставките за проследување по интерфејс како дел од истата операција, затоа еден запис може да го натера постоечкиот тунел да почне да проследува. default.forwarding засејува само интерфејси што се иницијализираат потоа, па тунелот што веќе постоел ја задржува вредноста со која е роден.

Документацијата на јадрото го означува ip_forward како посебен од поврзана причина: неговата промена ресетира низа други IPv4 параметри на стандардните вредности за домаќин или рутер. Тоа го прави тап алат. Да се постави еднаш како дел од воспоставувањето на улогата на портата е во ред; постојаното префрлање како трик за отстранување грешки може тивко да ја препише конфигурацијата на која сте потрошиле време.

Вредностите по интерфејс исто така постојат со причина. Намерно управувана порта може да го држи проследувањето исклучено на интерфејс што никогаш не би требало да рутира, дури и кога домаќинот проследува на друго место. Затоа е важно да се чита активниот интерфејс и затоа само глобалната вредност не е целиот одговор. Таквиот исклучок читајте го како свесна одлука и запишете зошто тој интерфејс е различен. Инаку следниот инженер ќе го "поправи" со добра волја.

Направете ја поставката трајна на вистинското место

Успешен еднократен sysctl -w докажува дека јадрото ја прифаќа вредноста. Тој не преживува рестартирање и не преживува мрежен менаџер што при повторно поврзување повторно го применува своето сфаќање за конфигурацијата на интерфејсот. Ставете ја улогата на портата во конфигурациската датотека на sysctl или во мрежниот менаџер што го поседува домаќинот, потоа рестартирајте ја услугата што ја применува.

Редоследот е важен кај тунелите. Ако менаџерот го создава интерфејсот при подигање и го применува проследувањето потоа, интерфејсот може да го наследи стариот стандард. Рестартирањето на услуга што го пресоздава тунелот е исто така настан на создавање и лесно се пропушта кога unit-от изгледа здрав. Проверете го редоследот, не само конечната содржина на датотеката.

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

Не го поправајте ова со погрешен алат

Кога проследувањето изгледаше скршено, искушението е да се испразни огнениот ѕид или да се додаде masquerading. Ниту едното не се занимава со прекинувачот за проследување. Состојбата на проследување, дозволата за проследување, рутата до дестинацијата и повратниот пат се четири одделни барања, и само првото е sysctl.

Тестирајте и со правилниот тек. Барањето направено на самата порта воопшто не го вежба проследувањето; тоа е локално генериран сообраќај. Прашањето е дали пакетот што доаѓа од VPN клиент или LAN домаќин се прифаќа и се рутира понатаму, па тестот мора да започне зад портата.

Држете го случајот IPv6 одделно

Овде сè е IPv4. Проследувањето на IPv6, најавите на рутерот и однесувањето на accept_ra имаат свои контроли, а копирањето на ipv4 патека во ipv6 поставка создава датотека што изгледа уверливо и не прави ништо корисно. Порта со двоен стек треба свесно да ги конфигурира двете множества.

Последна проверка: откако вредностите ќе се совпаднат, потврдете дека рутата на тунелот е избрана за дестинацијата и дека повратниот пат постои. Вклучено проследување на интерфејс без рута е сè уште црна дупка, и тој дефект изгледа исто од страната на клиентот.