Неге 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 қайта қосылғаннан кейін және қайта жүктеуден кейін сол үш мәнді қайта оқыңыз. Жаңадан жасалған туннель — жаңа интерфейс, ал жаңа интерфейс жасалу сәтінде қолданыстағы әдепкі мәнді қабылдайды. Егер сандар осы оқиғалар арасында өзгерсе, конфигурацияны сіз әлі анықтамаған нәрсе қолданып жатыр.

Мұны қате құралмен түзетпеңіз

Жіберу бұзылғандай көрінгенде, firewall-ды тазалау немесе masquerading қосу азғырады. Екеуі де жіберу қосқышын шешпейді. Жіберу күйі, жіберу рұқсаты, межеге маршрут және қайтару жолы — төрт бөлек талап, және тек біріншісі ғана sysctl.

Дұрыс ағынмен де сынап көріңіз. Шлюздің өзінде жасалған сұрау жіберуді мүлде қолданбайды; ол жергілікті жасалған трафик. Мәселе VPN клиентінен немесе LAN хосттан келген пакеттің қабылданып, әрі қарай бағытталуында, сондықтан сынақ шлюздің артынан басталуы керек.

IPv6 жағдайын бөлек ұстаңыз

Мұнда бәрі IPv4. IPv6 жіберуінің, маршрутизатор хабарландыруларының және accept_ra мінез-құлқының өз басқарулары бар, ал ipv4 жолын ipv6 параметріне көшіру сенімді көрінетін, бірақ пайдалы ештеңе жасамайтын файл жасайды. Қос стекті шлюз екі жиынды да әдейі конфигурациялауы керек.

Соңғы тексеру: мәндер сәйкес келгеннен кейін туннель маршрутының меже үшін таңдалғанын және жауап жолының бар екенін растаңыз. Маршрутсыз интерфейсте қосулы жіберу әлі де қара құрдым, және бұл ақау клиент жағынан бірдей көрінеді.