Направете препраќањето на IPv4 да остане по рестарт на VPN портата

Ping до портата работи, а пристапот до ништо зад неа не, и тоа е форма на проблем со препраќање, а не со тунел. Локалната достава до портата докажува дека тунелот се подигнал и дека доделувањето адреса работело; таа не кажува ништо за тоа дали јадрото ќе пренесе пакет од еден интерфејс на друг. Пред да допрете било кој sysctl, потврдете дека машината е наменета да го рутира овој сообраќај и пронајдете го мрежниот контекст што го држи интерфејсот кон клиентот. Потоа прочитајте ја вредноста таму, а не таму каде што последниот прочитан водич случајно погледнал.

Да се стигне до портата не е исто што и препраќање

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

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

Прочитајте ја вредноста таму каде што пакетите навистина се

На порта што рутира во именскиот простор на домаќинот, една команда одговара на прашањето: sysctl net.ipv4.ip_forward. Кога влезниот и понатамошниот пат живеат во именуван именски простор, прашајте го тој простор: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Вредноста на домаќинот не ја заменува вредноста на именскиот простор, и единица на домаќинот не е доказ за ништо.

Не секој контекст на рутирање има ознака што можете да ѝ ја дадете на ip netns. Контејнерските извршни средини и услугите создаваат именски простори што никогаш не се регистрираат под пријателско име, и за нив ги користите алатките за проверка на извршната средина. Заменете го vpn-gw со вистинското име или со механизмот на извршната средина што го достигнува истиот контекст, и престанете да погодувате на ниво на домаќин.

Дајте му на поставувањето еден сопственик

На конвенционална домаќинска порта со systemd, трајната форма е drop-in датотека со име избрано од администраторот, како /etc/sysctl.d/60-vpn-forwarding.conf, што содржи net.ipv4.ip_forward = 1. Запишете ја датотеката, потоа вчитајте ја токму таа датотека за да се промени и живото состојба: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, по што следи повторно читање. Името на датотеката е пример, а не резервирана VPN патека, и почетниот број е важен зашто датотеките подредени подоцна победуваат.

Приоритетот е местото каде што трајноста тивко се крши. Проверете го и вчитувачот на дистрибуцијата и вашата drop-in датотека, зашто procps sysctl --system на крајот ја чита и /etc/sysctl.conf, додека редоследот sysctl.d на systemd е сосема друга низа. Подоцнежно доделување може истиот клуч веднаш да го врати, оставајќи ја вашата датотека точна, а ефективната вредност погрешна. Не препишувајте постоечка администраторска датотека за да ја добиете таа расправа; најдете го сопственикот и сменете таму.

Именски простор создаден по подигањето воопшто не се управува од домаќинска drop-in датотека. Неговото поставување и припаѓа на она што го создава, било тоа контејнерската извршна средина или единицата за обезбедување на именскиот простор. Да се дадат широки домаќински привилегии на контејнер за да се избегне прашањето е полоша зделка отколку десет минути потрошени за идентификување на вистинскиот сопственик.

Знајте што чини прекинувачот пред да го свртите

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

Тоа исто така го исклучува неговото исклучување и вклучување секој пат кога клиентот не може да стигне до домаќин. Ако вредноста е веќе единица, грешката е на друго место по патеката, и повторното пишување на истиот клуч трет пат нема да го помести.

Докажете ја трајноста, потоа тестирајте го остатокот од патеката

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

Вклученото препраќање и понатаму остава три работи за проверка. На клиентот му треба рута до одредиштето, на портата ѝ треба понатамошна рута плус дозвола да ја користи, а на одредиштето му треба повратна патека до тунелската адреса на клиентот. Приватна рутирана LAN не бара автоматски NAT, затоа не додавајте masquerading пред да знаете која од трите недостасува, и тестирајте од предвидениот клиент, а не од самата порта, зашто барањето што настанало на портата никогаш не ја допира патеката на препраќање што штотуку ја вклучивте. IPv6 носи своја политика за препраќање и рутирање, па работен IPv4 тест не кажува ништо за неа.

Држете ги заедно во runbook патеката на drop-in, сопственикот на именскиот простор и командата за повторно читање. Следниот што ќе го преземе ова треба да може да ја прочита вредноста, да види чија е и во рок од една минута да одлучи дали проблемот е во трајноста или во остатокот од патеката.