VPN шлюзу кайра иштетилгенден кийин да IPv4 багыттоо туруктуу болсун

Шлюзга 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 файлын да окуйт, ал эми systemd'дин sysctl.d тартиби такыр башка ырааттуулук. Кийинки дайындоо ошол эле ачкычты дароо кайтарып коюшу мүмкүн, ошондо файлыңыз туура, ал эми натыйжалуу маани туура эмес болуп калат. Ошол талашты утуу үчүн бар администратор файлын кайра жазбаңыз; ээсин таап, ошол жерден өзгөртүңүз.

Жүктөөдөн кийин түзүлгөн аттар мейкиндиги хосттун drop-in файлы менен таптакыр башкарылбайт. Анын параметри аны түзгөн нерсеге таандык, ал контейнердин аткаруу чөйрөсү болобу же аттар мейкиндигин даярдоо бирдиги болобу. Суроодон качуу үчүн контейнерге кеңири хост укуктарын берүү туура ээсин аныктоого он мүнөт короткондон да жаман бүтүм.

Ажыраткычты буруудан мурун анын баасын билиңиз

ip_forward зыянсыз логикалык маани эмес. Ядронун документтери аны өзгөртүү бир нече башка IPv4 параметрлерин хосттун же маршруттагычтын демейки маанилерине кайтарарын белгилейт, ошондуктан диагностикалык буруу башка жерде жасалган жөндөөнү ыргытып, аны эч качан эске албашы мүмкүн. Ага бейкапар аткарууга боло турган текшерүү катары эмес, терс таасирлери бар конфигурация өзгөртүүсү катары мамиле кылыңыз.

Бул ошондой эле кардар хостко жете албаган сайын аны өчүрүп-күйгүзүүнү жокко чыгарат. Эгер маани мурунтан бир болсо, бузулуу жолдун башка жеринде, жана ошол эле ачкычты үчүнчү жолу кайра жазуу аны козгобойт.

Туруктуулукту далилдеңиз, андан кийин жолдун калган бөлүгүн текшериңиз

Маанини төрт учурда кайра окуңуз: өзгөртүүдөн кийин дароо, VPN интерфейси пайда болгондон кийин, кайра туташкандан кийин жана пландалган кайра жүктөөдөн кийин. Ошол пункттардын кайсынысында болбосун артка кеткен маанинин экинчи ээси бар, жана дагы бир жолку жазуу аны кийинки кайра жүктөөгө чейин гана жашырат.

Күйгүзүлгөн багыттоо дагы үч нерсени текшерүүнү калтырат. Кардарга багытталган жерге маршрут керек, шлюзга мындан ары маршрут жана аны колдонуу уруксаты керек, ал эми багытталган жерге кардардын туннель дарегине кайтуу жолу керек. Жеке маршрутталган LAN автоматтык түрдө NAT талап кылбайт, ошондуктан үчөөнүн кайсынысы жетишсиз экенин билмейинче masquerading кошпоңуз, жана шлюзден эмес, көздөлгөн кардардан текшериңиз, анткени шлюзде башталган сурам жаңы эле күйгүзгөн багыттоо жолуна эч качан тийбейт. IPv6 өзүнүн багыттоо жана маршруттоо саясатын алып жүрөт, ошондуктан иштеген IPv4 текшерүүсү ал тууралуу эч нерсе айтпайт.

Runbook'то drop-in жолун, аттар мейкиндигинин ээсин жана кайра окуу буйругун бирге кармаңыз. Муну кийинки алган адам маанини окуй алышы, анын кимге таандык экенин көрө алышы жана бир мүнөттүн ичинде маселе туруктуулуктабы же жолдун калган бөлүгүндөбү экенин чече алышы керек.