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 дахин холбогдсоны дараа гурав дахь командыг давтаарай.

Амьдралын мөчлөгийг санаатайгаар сонгоорой: тогтвортой хаяг буцаж ирэхийг хүлээдэг чөлөөтэй холбогдсон сонсогч, эсвэл туннельтай хамт зогсоод сэргэх үед дахин эхэлдэг үйлчилгээ. Эдгээр нь өөр загварууд бөгөөд өөр өөрөөр бүтэлгүйтдэг. Дараа нь хандалтын бодлогыг таны зорьсон эх сурвалж, замуудтай холбоотой байлгаарай, учир нь очих хаягыг холбох нь хүлээн авсан багцууд итгэмжлэгдсэн интерфэйсээр ирсэн байхыг шаарддаггүй.