له بیا پیل وروسته د VPN سرور د بیا رغیدو ازموینه: لومړی څه وګورئ

سرور بیا پیل کړئ پرته له دې چې څوک ننوتی وي، بیا له هغه شبکې څخه وصل شئ چې تاسو یې کنټرول نه لرئ۔ همدا یوه ازموینه ځواب ورکوي چې ایا بیا رغیدل ریښتینی دي، ځکه هغه تونل چې یوازې وروسته له دې چې څوک په لاس کمانډ وچلوي کار کوي، بیا رغیدل نه دي، ترمیم دي۔ ډیری ګړنې ډیر ژر بنديږي: ډیمون فعال ښکاري، انټرفیس پورته کیږي، او پاڼه لا هم نه لوډیږي۔ توپیر نږدې تل د تونل شاوخوا برخو په دوام کې وي، نه په خود د تونل کمانډ کې۔

څلور مالکین، څلور بیلابیلې ازموینې

له بیا پیل مخکې، هغه څه ونوموئ چې باید تونل بېرته راولي۔ هغه ازموینه چې تاسو ترسره کوئ او هغه سمون چې تطبیقوئ دواړه په هغه ځواب پورې تړلي دي، او څلور عام مالکین شته: د VPN ډیمون لپاره یو systemd unit، د WireGuard انټرفیس لپاره د wg-quick یو نمونه unit، د کانټینر رنټایم، یا د شبکې مدیر پروفایل۔ که مالک ونومولی نه شئ، ودریږئ او ومومئ یې، ځکه پرته له تمه شوې پیل لارې د بیا پیل ازموینه یوازې تاسو ته وایي چې یو څه وشول۔

هر مالک خپله ترتیب په بل ځای کې ساتي۔ د systemd لخوا اداره شوی OpenVPN سرور خپل ترتیب په پیل کې لولي، نو هغه څه چې د بوټ په وخت کې په فایل کې وي هماغه چلیږي۔ wg-quick انټرفیس خپل پته، لارې او DNS له همدې فایل څخه اخلي، یعنې هغه انټرفیس چې په لاس له شیل څخه پورته شوی او کله هم د unit په توګه فعال شوی نه وي بېرته نه راځي۔ کانټینر خپل د ننوتلو ټکی بېرته راولي، خو د کوربه د فایر وال بدلونونه نه، پرته له دې چې هغه د کانټینر څخه بهر وي۔

لومړی بنسټیز حالت، که نه نو پایله هیڅ معنی نه لري

د کار حالت ثبت کړئ کله چې کار کوي: په تونل کې پته، د پیرودونکي فرعي شبکې لپاره لارې، د NAT یا لیږد قواعد، اوریدونکی ساکټ، او د لیږد sysctl۔ ip addr show wg0, ip route, nft list ruleset یا iptables-save, ss -lunp او sysctl net.ipv4.ip_forward په ډیرو کوربه وو کافي دي۔

ثبت کړئ چې خدمت څنګه د پیل لپاره ترتیب شوی، نه یوازې دا چې چلیږي۔ systemctl is-enabled wg-quick@wg0 او systemctl is-active wg-quick@wg0 بیلابیلو پوښتنو ته ځواب وایي، او د بوټ په وخت کې فعال حالت مهم دی، لکه څنګه چې په systemctl(1) کې بیان شوی۔ د OpenVPN لپاره، وګورئ چې کوربه کوم ټیمپلیټ کاروي، ځکه openvpn@server او openvpn-server@server بیلابیل unitونه دي چې بیلابیل ډیفالټ لري۔

بیا پیل ترسره کړئ او لومړنی ناکامي ولولئ

په قصد بیا پیل کړئ، په هغه وخت کې چې تاسو ټاکلی وي، په خلاص کنسول یا د باندې لار سره۔ د پیښو ترتیب وګورئ نه وروستی حالت: کوربه د لاسرسي وړ، unit فعال شو، انټرفیس شته، لارې نصب شوې، د فایر وال قواعد شته، اوریدونکی تړل شوی، پیرودونکی ومنل شو۔ لومړی ګام چې نه کیږي هماغه موندنه ده؛ له هغې وروسته هر څه شور دي۔

ډیمون کیدای شي فعال وي پداسې حال کې چې تونل بې ګټې دی، او دا ترټولو عام غلط تیریدل دي۔ پیل کیدای شي د شبکې له آنلاین کیدو مخکې بشپړ شي که unit یوازې د network.target انتظار کوي نه د network-online.target۔ هغه فایلونه چې اشاره ورته شوې لکه سندونه، کیلي یا CRL کیدای شي په هغه شیبه کې د لوستلو وړ نه وي، ځکه چې ماونټ یا د رازونو لار لا نه ده چمتو۔ دواړه ستونزې په systemctl status کې نه ښکاري ترڅو چې د unit ژورنال ولولئ۔

له کوربه بهر ازموینه وکړئ۔ په همدې LAN کې پیرودونکی کیدای شي د داسې لارې له لارې بریالی شي چې هیڅ لیرې پیرودونکی به یې کله هم ونه کاروي، او ماشین ته SSH ناسته د تونل په اړه هیڅ نه ثابتوي۔ وصل شئ، یو داخلي نوم حل کړئ، شخصي سرچینې ته ورسیږئ، بیا یو ځل بیا وصل شئ ترڅو تایید کړئ چې د لغوه کولو حالت او کیلي لا هم پلي کیږي۔

هغه درې شرایط چې ستاسو سمون ټاکي

که تونل بېرته راشي خو پیرودونکي هیڅ ځای ته نه رسیږي، ناکامي په لارښوونه یا د NAT په دوام کې ده۔ که پیرودونکي حتی لاس ورکول نشي بشپړولی، ناکامي په انټرفیس یا د تصدیق موادو کې ده۔ که خدمت کله هم پیل نه شي، ناکامي په unit فایل یا د هغې په تړاوونو کې ده۔ دا درې څانګې بیلابیلو سمونونو ته رسوي، نو ځکه پرته له بنسټیز حالت څخه ړوند بیا پیل د خوندي کړي وخت څخه ډیر وخت اخلي۔

سمون هغه ځای وکړئ چې تنظیم مالکیت لري۔ لیږد په sysctl drop-in کې کیږدئ، د NAT قواعد په هغه قواعدو ټولګه کې کیږدئ چې د بوټ په وخت کې لوډیږي، unit فعال کړئ نه دا چې یې پیل کړئ، او رازونه په داسې لاره کې وساتئ چې د unit له پیل مخکې شتون لري۔ unit ته خوب ورزیاتول تړاو پټوي نه دا چې اعلان یې کړي۔

پایله په runbook کې ثبت کړئ

ولیکئ چې څه پخپله بېرته راغلل، څه مجبور شوئ پیل کړئ، او توپیر څومره دوام وکړ۔ هغه دقیق کمانډونه شامل کړئ چې د تایید لپاره مو کارولي، ترڅو بل کس ازموینه تکرار کړي نه نوی جوړ کړي۔ که هر ګام لاسي کمانډ ته اړتیا لري، هغه کمانډ د ترتیب برخه ده، په runbook کې د تلپاتې ګام په توګه نه۔

بیا بلې ازموینې لپاره د کوربه د شبکې سټک په راتلونکي بدلون وروسته وخت وټاکئ، نه د شپږو میاشتو وروسته کیلنډر نیټې لپاره۔ هغه ناکامي چې تاسو ترې ساتنه کوئ یو لنډمهاله کمانډ دی چې تلپاتې ښکاریده، او هغه په سمه توګه هغه وخت ښکاري چې څوک د فایر وال قواعد سمونړي یا خدمت نوي unit ته لېږدوي۔