Зашто VPN јединица креће пре мреже и затим умире

Подигните машину, пријавите се и сазнајте да је тунел отишао горе и умро неколико секунди касније. Профил је био у реду, сертификат је био у реду, а једини преостали траг је журнал тог подизања. Оно што се обично догодило је трка: јединица је кренула пре него што је машина имала адресу, а редослед који је декларисала није значио оно на шта личи. Све испод говори о томе како ту трку доказати из доказа и исправно је затворити.

Циљ је место сусрета, не управник

network-online.target нема појма шта је мрежа. То је координациона тачка која сакупља ону услугу која треба да одложи покретање док веза не постане употребљива, и преноси дефиницију на оног мрежног менаџера који поседује машину. На већини радних станица и сервера то значи услугу чекања коју испоручује NetworkManager или systemd-networkd. Ако не укључите ниједну, циљ нема шта да чека, па се завршава у тренутку када га нешто повуче унутра, а то може бити много пре него што DHCP одговори. Ред о редоследу у вашој јединици био је искрен и ипак бескористан.

Прво питање зато није шта ваша јединица декларише. Него да ли нешто на овој машини заиста обавља чекање.

Читајте последње подизање, а не датотеку јединице

Датотеке јединица описују намеру, а журнал описује шта се догодило. Затражите само то подизање, са монотоним временским ознакама како би свака порука стајала на једном сату. Затим нађите два реда: тренутак када је јединица тунела почела да се покреће и тренутак када се адреса појавила или је услуга чекања завршила. Поређајте та два броја и трка је или потврђена или искључена.

Приказ зависности то потврђује. Ако критични ланац за јединицу тунела не садржи услугу чекања, ништа на том путу није одложило покретање и циљ није обавио посао који сте претпоставили. Два приказа, један закључак.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Додајте чекање, затим поновни покушај

Користите drop-in уместо уређивања спаковане јединице, да ажурирање пакета не одбаци измену тихо. Важне су две директиве: јединица мора бити поређана после циља и мора повући циљ у исту трансакцију. Само поређање не признаје циљ; то чини жеља.

Спакована јединица OpenVPN клијента већ носи обе. Руком писане јединице обично носе једну или ниједну, што вреди проверити пре него што било шта додате.

[Service]
Restart=on-failure
RestartSec=15

Зашто је фиксни сан замка

Сан у ExecStartPre делује као исправка редоследа и понаша се као одлагање са додатним корацима. Успорава свако подизање, укључујући она која су била здрава, и још губи када веза траје дуже од броја који сте изабрали.

Још горе, он скрива да ли услуга чекања ради, па се следећи неуспех појављује као потпуно нов проблем, а не исти са другим временом. Кратко одлагање поновног покретања је бољи инструмент: не кошта ништа при здравом подизању и претвара изгубљену трку у још један покушај. Држите интервал скромним и пустите јединицу да успе. Ако се поново покреће заувек, профил је покварен и никаква количина покушаја то неће променити, зато читајте журнал уместо да подижете интервал.

Када је редослед исправан, а имена ипак падају

Активна јединица са рутом тунела значи да је редослед обавио свој посао и да преостали дефект седи један слој изнад. Уобичајени облик је подешавање резолвера које up скрипта тунела примени пре него што су веза или резолвер били спремни да га задрже. Упоредите стање резолвера током неуспеха са стањем после поновног покретања јединице тунела.

Ако поновно покретање поправља претраге, имате дефект редоследа покретања, а не погрешан DNS сервер, и та два траже различите поправке. Затим докажите све хладним подизањем уместо поновним покретањем услуге, јер поновно покретање ради против мреже која је већ горе и сакриће управо дефект који гањате. Поновите то са намерно спором везом и сматрајте јединицу која ради само кад је мрежа брза још увек поквареном.