Чаму 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. Першыя два не згаджаюцца адносна ролі хоста, а трэці паказвае, што інтэрфейс робіць насамрэч. Такая камбінацыя адпавядае хасцi, які ніколі не наладжваўся як маршрутызатар, а атрымаў толькі значэнне шаблона. Тры лічбы не супярэчаць адна адной; яны адказваюць на тры розныя пытанні. Запіс значэння шаблона таксама не вырашае ролю хоста.

Чаму рухаецца менавіта глабальны перамыкач

net.ipv4.ip_forward — гэта агульнае для шлюза кіраванне. Яго змена абнаўляе налады перасылкі для кожнага інтэрфейса ў межах той жа аперацыі, таму адзін запіс можа прымусіць існуючы тунель пачаць перасылаць. default.forwarding задае толькі інтэрфейсы, якія ініцыялізуюцца пазней, таму тунель, які ўжо існаваў, захоўвае значэнне, з якім нарадзіўся.

Дакументацыя ядра пазначае ip_forward як асаблівы па звязанай прычыне: яго змена скідвае шэраг іншых параметраў IPv4 да значэнняў па змаўчанні для хоста або маршрутызатара. Гэта робіць яго грубым інструментам. Задаць яго адзін раз падчас усталявання ролі шлюза — нармальна; перамыкаць яго раз за разам як хітрую прыладу адладкі можа ціха перазапісаць канфігурацыю, якую вы старанна даводзілі.

Значэнні для кожнага інтэрфейса існуюць таксама нездарма. Наўмысна кіраваны шлюз можа трымаць перасылку выключанай на інтэрфейсе, які ніколі не павінен маршрутызаваць, нават калі хост перасылае ў іншае месца. Таму важна чытаць жывы інтэрфейс і таму адно глабальнае значэнне — не ўвесь адказ. Чытайце такое выключэнне як свядомае рашэнне і запішыце, чым гэты інтэрфейс адрозніваецца. Інакш наступны інжынер з гатоўнасцю яго "паправіць".

Зрабіце наладу пастаяннай у правільным месцы

Паспяховы аднаразовы sysctl -w даказвае, што ядро прымае значэнне. Ён не перажывае перазагрузку і не перажывае сеткавага мэнэджара, які пасля перападлучэння зноў ужывае сваё ўяўленне пра канфігурацыю інтэрфейса. Запішыце ролю шлюза ў файл канфігурацыі sysctl або ў сеткавы мэнэджар, які валодае хостам, а затым перазапусціце службу, якая гэта ўжывае.

Парадак мае значэнне для тунеляў. Калі мэнэджар стварае інтэрфейс пры загрузцы і ўжывае перасылку пасля, інтэрфейс можа атрымаць стары default. Перазапуск службы, які стварае тунель нанова, таксама з'яўляецца падзеяй стварэння, і гэта лёгка прапусціць, калі unit выглядае здаровым. Правярайце паслядоўнасць, а не толькі канчатковы змест файла.

Перачытайце тыя ж тры значэнні пасля перападлучэння VPN і яшчэ раз пасля перазагрузкі. Новаствораны тунель — гэта новы інтэрфейс, а новы інтэрфейс бярэ default, які дзейнічае ў момант стварэння. Калі лічбы змяняюцца паміж гэтымі падзеямі, канфігурацыю ўжывае нешта, што вы яшчэ не вызначылі.

Не рамантуйце гэта няправільным інструментам

Калі перасылка выглядала зламанай, узнікае спакуса ачысціць файрвол або дадаць masquerading. Ні тое, ні другое не вырашае перамыкач перасылкі. Стан перасылкі, дазвол на перасылку, маршрут да прызначэння і зваротны шлях — гэта чатыры асобныя патрабаванні, і толькі першае з іх — sysctl.

Таксама тэстуйце правільным патокам. Запыт, зроблены на самім шлюзе, зусім не ўжывае перасылку; гэта лакальна згенераваны трафік. Пытанне ў тым, ці прымаецца пакет, які прыйшоў ад кліента VPN або хоста LAN, і ці накіроўваецца далей, таму тэст павінен пачынацца за шлюзам.

Трымайце выпадак IPv6 асобна

Тут усё пра IPv4. Перасылка IPv6, аб'явы маршрутызатара і паводзіны accept_ra маюць уласныя элементы кіравання, і капіраванне шляху ipv4 у наладу ipv6 стварае файл, які выглядае праўдападобна і не робіць нічога карыснага. Шлюз з двайным стэкам патрабуе свядомай налады абодвух набораў.

Апошняя праверка: пасля таго як значэнні супадуць, пераканайцеся, што маршрут тунеля выбіраецца для прызначэння і што зваротны шлях існуе. Уключаная перасылка на інтэрфейсе без маршруту — гэта ўсё яшчэ чорная дзірка, і з боку кліента гэтая памылка выглядае аднолькава.