Зрабіце перасылку IPv4 устойлівай пасля перазапуску VPN-шлюза

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

Трымайце шлях drop-in, уладальніка прасторы імёнаў і каманду чытання разам у runbook. Хто возьме гэта далей, павінен мець магчымасць прачытаць значэнне, убачыць, хто ім валодае, і на працягу хвіліны вырашыць, ці праблема ва ўстойлівасці, ці ў астатнім шляху.