Nëse porta e përparme pranon lidhje pasi SSH del, inspektoni të tre njësitë. Soketi i aktivizimit, ndihmësi systemd-socket-proxyd dhe dëgjuesi SOCKS i krijuar nga SSH kanë jetëgjatësi të ndryshme:

SoketNdihmësSSHInterpretim
DëgjonJoaktivJoaktivMund të presë normalisht kërkesën
DëgjonAktivAktivProceset ekzistojnë; shëndeti i destinacionit pasardhës mbetet i paprovuar
DëgjonAktivJoaktivFronti mund të pranojë punë pa backendin e vet

Nisja e ndihmësit dhe SSH së bashku nuk përcakton tranzicionin e mëvonshëm të ndalimit. Për një ndihmës që nuk duhet të mbetet aktiv pa tunelin e vet, systemd dokumenton një marrëdhënie më të fortë:

[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.service

Aplikojeni në njësinë e duhur në dizajnin aktual. Requires= dhe renditja zgjidhin vetëm një pjesë të marrëdhënies. Një front tashmë aktiv përndryshe mund të mos aktivizojë kurrë më pas zhdukjes së backendit. Kontrolloni gjithashtu gjendjen e njësive të dështuara dhe kufijtë e shkallës së nisjes; varësitë nuk i anulojnë këta kufij.

Më pas vendosni gatishmërinë e nisjes. After= rendit punët, jo gatishmërinë e një dëgjuesi SSH Type=simple. Një pauzë fikse mund të dështojë gjatë vërtetimit të ngadaltë. Përdorni një kontratë nisjeje që vendos dëgjuesin e kërkuar; ExitOnForwardFailure=yes kap dështimin e konfigurimit të përcjelljes, jo arritshmërinë e mëvonshme të destinacionit.

Së fundi, përcaktoni daljen në papunësi dhe riaktivizimin. Opsioni i daljes në papunësi i demonit të përcjelljes ka të bëjë me mungesën e lidhjeve aktive, jo me mungesën e bajteve në një lidhje të hapur. Një sesion i qetë mund ta mbajë atë aktiv. Kërkesa tjetër duhet të aktivizojë shërbimet e nevojshme, dhe sythet e rinisjes duhet të mbeten të kufizuara dhe të dukshme. Rikrijimi i dëgjuesit pranon lidhje të reja; nuk i rikthen sesionet e vjetra TCP të përfaqësuara.

Artikuj të ngjashëm