systemd-socket-proxyd ইয়াৰ SSH SOCKS tunnelৰ পিছতো জীয়াই থাকিব পাৰে

SSH ওলাই যোৱাৰ পিছতো যদি front port এ সংযোগ গ্ৰহণ কৰি থাকে, তেন্তে তিনিওটা unit পৰীক্ষা কৰক। activation socket, systemd-socket-proxyd helper আৰু SSH ৰ দ্বাৰা সৃষ্ট SOCKS listener ৰ জীৱনকাল বেলেগ বেলেগ:

helper আৰু SSH একেলগে আৰম্ভ কৰিলে পিছৰ stop transition নিৰ্ধাৰিত নহয়। যি helper tunnel ৰ অবিহনে সক্ৰিয় থাকিব নালাগে, তাৰ বাবে systemd ইয়াৰ বেছি দৃঢ় সম্পৰ্ক লিখিতভাৱে দিয়ে:

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

প্ৰকৃত ডিজাইনত উপযুক্ত unit ত ইয়াক প্ৰয়োগ কৰক। Requires= আৰু ordering এ সম্পৰ্কৰ এটা অংশহে সামৰে। ইতিমধ্যে সক্ৰিয় frontend এ backend নোহোৱা হ’লে পুনৰ activation কেতিয়াও নকৰিব পাৰে। failed-unit অৱস্থা আৰু start-rate limitো পৰীক্ষা কৰক; নিৰ্ভৰশীলতাই সেই সীমা অতিক্ৰম নকৰে।

তাৰ পিছত startup readiness স্থাপন কৰক। After= এ job ৰ ক্ৰম দিয়ে, Type=simple SSH listener ৰ readiness নহয়। লেহেমীয়া authentication ৰ সময়ত নিৰ্দিষ্ট sleep এ বিফল হ’ব পাৰে। প্ৰয়োজনীয় listener স্থাপন কৰা startup contract ব্যৱহাৰ কৰক; ExitOnForwardFailure=yes এ forwarding setup ৰ বিফলতা ধৰে, পিছত গন্তব্যৰ উপলব্ধতা নহয়।

শেষত idle exit আৰু reactivation নিৰ্ধাৰণ কৰক। forwarding daemon ৰ idle-exit option এ সক্ৰিয় সংযোগৰ অনুপস্থিতিৰ কথা, মুক্ত সংযোগত byte ৰ অভাৱৰ কথা নহয়। শান্ত session এ ইয়াক সক্ৰিয় ৰাখিব পাৰে। পৰৱৰ্তী চাহিদাই প্ৰয়োজনীয় service সক্ৰিয় কৰা উচিত, আৰু restart loop সীমিত আৰু দৃশ্যমান থাকা উচিত। listener পুনৰ সৃষ্টি কৰিলে নতুন সংযোগ আহে; পুৰণি proxied TCP session ঘূৰি নাহে।