फ़ायरवॉल संपादन के लिए डेडमैन स्विच
होमलैब ऑटोमेशन में सबसे डरावनी लाइन वह होती है जो उस राउटर पर फ़ायरवॉल नियम को संपादित करती है जिससे आप SSH के ज़रिए जुड़े हुए हैं।
यहाँ बताया गया है कि Claude Code और मैं उन्हें फिर भी कैसे संपादित करते हैं।
डर
मुझे UDM Pro के एक नियम को, जिसका नाम “Block inter-VLAN traffic” था, accept से drop में बदलना था। यह नियम काफी समय से गलत तरीके से कॉन्फ़िगर था — accept पर सेट था, जो इसके ऊपर के हर प्रति-प्रवाह अनुमति को शॉर्ट-सर्किट कर रहा था — और इसे वापस बंद करना ही पूरा उद्देश्य था। परिवर्तन को चलाने वाला ऑर्केस्ट्रेटर मेरे होम नेटवर्क पर एक NixOS VM था। अगर इस बदलाव ने उस VM (या मेरे अपने SSH) द्वारा उपयोग किए जाने वाले रास्ते को काट दिया, तो मैं बिना किसी कंसोल फॉलबैक के अपने ही राउटर से बाहर लॉक हो जाता।
समाधान “सावधान रहना” नहीं है। समाधान यह है कि खतरनाक संपादन को स्वचालित रूप से वापस लौटाएं जब तक कि मैं यह पुष्टि न करूं कि यह ठीक है।
आपने यह पैटर्न पहले देखा है। macOS या Windows पर अपने मॉनिटर का रिज़ॉल्यूशन बदलें और सिस्टम इसे पंद्रह सेकंड के लिए एक काउंटडाउन “क्या इन डिस्प्ले सेटिंग्स को रखें?” डायलॉग के साथ लागू करता है। अगर आपकी स्क्रीन काली हो गई, तो आप कुछ भी क्लिक नहीं कर सकते — और यही बात है। डिफ़ॉल्ट परिणाम रोलबैक है। पुष्टि ऑप्ट-इन है।
यही हम उस राउटर पर फ़ायरवॉल बदलाव के लिए चाहते हैं जिसके नियम हम बदलने वाले हैं।
तरकीब
udm_set_firewall_rules.py --flip-with-revert 300 --apply
पढ़ें: “नियम को पलटें, लेकिन 300 सेकंड में स्वचालित रूप से वापस लौटाएं जब तक कि मैं आपको ऐसा न करने को कहूं।”
यह क्रमशः क्या करता है:
- स्नैपशॉट। वर्तमान नियम को GET करता है और पूरे JSON पेलोड को UDM पर
/root/.udm-flip-revert/payload-<id>.jsonमें संग्रहित करता है। - रिवर्ट तैयार करना। पेलोड के बगल में एक छोटी सी शेल स्क्रिप्ट लिखता है जो स्नैपशॉट को UDM API पर वापस PUT करती है।
- रिवर्ट शेड्यूल करना।
systemd-run --on-active=300s --unit=udm-flip-revert-<id>स्क्रिप्ट को एक क्षणिक टाइमर के रूप में कतार में डालता है। - पलटना। नया नियम PUT करता है (
action: drop)।
अब आपके पास जाँच के लिए 5 मिनट की खिड़की है:
✓ flipped 'Block inter-VLAN traffic' to action='drop'
⏱ auto-revert scheduled (~300s)
TO KEEP THE FLIP: ssh udm 'systemctl stop udm-flip-revert-66c1d…timer'
TO ROLL BACK NOW: ssh udm 'systemctl stop …timer; bash /root/.udm-flip-revert/revert-….sh'
WAIT IT OUT: do nothing — timer will revert in ~300s
तीन परिणाम:
- काम कर गया। टाइमर बंद करें। बदलाव स्थायी है।
- कुछ टूट गया। टाइमर बंद करें, रिवर्ट स्क्रिप्ट चलाएं। या बस टाइप करना बंद करें — टाइमर N सेकंड में चलेगा और नियम अपने आप वापस आ जाएगा।
- मुझे बाहर लॉक कर दिया। वही बात। टाइमर को चलने के लिए मेरी ज़रूरत नहीं है।
तीसरा मामला ही पूरे अस्तित्व का कारण है।
systemd-run क्यों, at(1) नहीं
UDM Pro (Debian 11) के साथ atd नहीं आता। इसमें systemd है। systemd-run --on-active=Ns एक क्षणिक टाइमर बनाता है जो एक बार चलता है और खुद साफ हो जाता है — यही “N सेकंड में यह काम करो और फिर चले जाओ” का रूप है।
ssh_udm(
f"systemd-run --on-active={seconds} --unit={unit} --collect "
f"--quiet /bin/bash {script_file}"
)
--collect मुख्य फ्लैग है — इसके बिना यूनिट failed/inactive स्थिति में बनी रहती है और systemctl को अव्यवस्थित कर देती है।
सावधानी
क्षणिक systemd यूनिट /run में रहती हैं, जो tmpfs है। अगर रिवर्ट विंडो के अंदर UDM रीबूट हो जाता है, तो टाइमर गायब हो जाता है — और बदलाव बिना किसी डेडमैन की निगरानी के लागू रहता है।
विरोधाभासी लेकिन सच: विंडो को छोटा रखें। छोटे रीबूट जोखिम वाली 5 मिनट की विंडो 1 घंटे की विंडो से अधिक सुरक्षित है जहाँ 12वें मिनट में UPS की खराबी आपको स्थायी लॉकआउट दे सकती है। जाँच के लिए पर्याप्त लंबी, इतनी छोटी कि “क्या मैं किसी लंबित रिवर्ट के बारे में भूल गया?” कभी सवाल न बने।
निष्कर्ष
डेडमैन पैटर्न UDM फ़ायरवॉल नियमों से परे सामान्यीकृत होता है। जहाँ भी आप कोई बदलाव लागू करने वाले हों जो उस रास्ते को काट सकता है जिसके ज़रिए आपने इसे लागू किया — रूटिंग टेबल, sshd_config, nftables, BGP — वही आकार काम करता है:
- वर्तमान स्थिति को कैप्चर करें
- एक स्क्रिप्ट तैयार करें जो इसे पुनर्स्थापित करती है
- स्क्रिप्ट को N सेकंड में चलने के लिए शेड्यूल करें
- बदलाव लागू करें
अगर आप N+ε सेकंड बाद भी वहाँ हैं और चीज़ें अच्छी लग रही हैं, तो टाइमर रद्द करें। नहीं तो, टाइमर आपको रद्द कर देता है।
इसे टूलबॉक्स में रखकर मुझे बेहतर नींद आती है।