Неге 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 сервері емес, іске қосу ретінің ақауы бар, және бұл екеуіне бөлек түзетулер керек. Содан кейін бүкіл нәрсені қызметті қайта іске қосудың орнына суық жүктеумен дәлелдеңіз, өйткені қайта іске қосу қазірдің өзінде көтерілген желіге қарсы жүреді және сіз қуған ақауды дәл жасырады. Мұны байланысты әдейі баяу қылып қайталаңыз, және желі жылдам болғанда ғана жұмыс істейтін бірлікті әлі де бұзылған деп есептеңіз.