FreeBind супраць After=: прывязка сокета systemd да адрасу VPN

Пры загрузцы сокет-юніт, які прывязвае фіксаваны адрас VPN, можа збаіць яшчэ да таго, як тунель прызначыць гэты адрас, і служба за ім так і не запусціцца. Два перамыкачы выглядаюць як рашэнне і вырашаюць розныя паловы гэтай праблемы. FreeBind дазваляе systemd стварыць слухач, пакуль адрас яшчэ адсутнічае. After= толькі ўпарадкоўвае заданні, таму ён змяняе, калі што пачынаецца, але не прыносіць адрас раней.

Дзве розныя праблемы, два розныя перамыкачы

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

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

FreeBind: слухач існуе да адрасу

FreeBind кажа ядру дазволіць прывязку да нелакальнага адрасу, каб systemd мог стварыць слухаючы сокет пры загрузцы і перадаць яго праграме, калі тая запусціцца. У гэтым і сэнс актывацыі сокета, і прычына, чаму сокет можа перажыць службу за ім.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Пустое прызначэнне ачышчае запісы слухання, атрыманыя ад юніта пастаўшчыка, перш чым дадаць новы, што не дае рэшткаваму слухачу wildcard адказваць на кожным інтэрфейсе. Замяніце адрас і порт на свае і праверце эфектыўны юніт, а не адзін толькі drop-in файл. Выкарыстоўвайце drop-in пад імем юніта замест рэдагавання файла пакета на месцы, бо наступнае абнаўленне пакета перазапіша праўку і не пакіне ніякага следу намеру. Затым ужывіце яго праз працэдуру перазагрузкі і перазапуску, якую чакае сокет-юніт.

Даведнік па сокетах systemd апісвае паводзіны IPv4 і IPv6 за гэтай опцыяй, і важкая дэталь у тым, што яна тычыцца прывязкі, а не маршрутызацыі. Нішто ў ёй не прызначае адрас і не запускае VPN. FreeBind — гэта дазвол, дадзены слухачу, а не замена інтэрфейсу.

After= і Wants=: парадак — гэта не гатоўнасць

Парадак і патрабаванне — розныя восі, і іх блытаніна спараджае юніты, якія пачынаюцца ў правільным парадку і ўсё роўна збаяць. After=vpn-client.service азначае толькі тое, што калі абодва заданні запушчаны, гэта чакае запуску другога. Ён не прыцягвае VPN і не чакае, пакуль VPN скончыць падключэнне.

Дырэктывы патрабавання, такія як Wants= і Requires=, займаюцца актывацыяй і адрозніваюцца тым, што адбываецца пры збоі залежнасці: адна працягвае, другая спыняецца. Ні адна з іх не ведае, што значыць падключаны тунель. Працэс VPN можа быць актыўным без прызначанага адрасу або з прызначаным адрасам і без маршруту да партнёра, і абодва станы задавальняюць залежнасць. Калі праграме патрэбна, каб адрас існаваў, мадэлюйце гэтую ўмову яўна, замест таго каб лічыць запуск працэсу доказам гатоўнасці.

Праверце, што юніт насамрэч абвяшчае, з дапамогай systemctl cat і systemctl show -p After -p Wants -p Requires. Drop-in з трох розных каталогаў могуць дадаць дырэктывы, якіх вы ніколі не пісалі, і systemd чытае толькі эфектыўны юніт.

Што network-online.target не робіць

Юніт, упарадкаваны пасля network-online.target, чакае, пакуль кіраўнік сеткі абвясціць сетку прыдатнай, а гэта пункт сінхранізацыі загрузкі, а не бесперапынная ўмова. Ён нічога не кажа пра тое, ці падняты пэўны тунель, і не спрацуе зноў, калі VPN перападключыцца пасля абеду. Ставіцца да яго як да манітора перападлучэння — самая распаўсюджаная памылка чытання гэтай цэлі.

Праект systemd непасрэдна дакументуе гэтае адрозненне, і практычная выснова такая: усё, што мае патрэбу ў адрасе тунеля, павінна само валодаць залежнасцю. Юніт, які чакае network-online, а затым прывязвае адрас тунеля, правільны толькі тады, калі тунель выпадкова паднімаецца першым, а гэта выпадак, а не праект.

Праверце жыццёвы цыкл, які вы насамрэч абралі

Праверце чыстую загрузку, запыт пасля з’яўлення адрасу і паводзіны пасля таго, як VPN падае і вяртаецца. Гэтыя тры выпадкі аддзяляюць працаздольны слухач ад працаздольнай службы.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

Першая каманда ловіць памылкі файла юніта да перазагрузкі, другая паказвае аб’яднаны юніт, а трэцяя даказвае, ці існуе слухач і на якім адрасе. Слухач на адрасе wildcard там, дзе вы чакалі адрас тунеля, — гэта менавіта тая рэштка, якую пусты ListenStream павінен быў прыбраць. Паўтарыце трэцюю каманду пасля перападлучэння VPN, каб убачыць, ці змяніўся адрас.

Выбірайце жыццёвы цыкл свядома: альбо свабодна прывязаны слухач, які чакае вяртання стабільнага адрасу, альбо служба, якая спыняецца разам з тунелем і зноў запускаецца пры аднаўленні. Гэта розныя праекты, і яны збаяць па-рознаму. Затым трымайце палітыку доступу прывязанай да тых крыніц і шляхоў, якія вы мелі на ўвазе, бо прывязка адрасу прызначэння не патрабуе, каб прынятыя пакеты прыйшлі праз давераны інтэрфейс.