magic-wormhole: একবারের কোডে নিরাপদ ফাইল ট্রান্সফার
Table of Contents
হ্যালো সবাইকে,
আজ আমি একটি ছোট CLI টুল নিয়ে কথা বলতে চাই, যেটাতে আমি সাপোর্ট এবং ইনসিডেন্ট পরিস্থিতিতে বারবার ফিরে আসি: magic-wormhole। এটি এমন একটা সমস্যা সমাধান করে যা সাধারণ ব্যবসায়িক পরিবেশে যেকোনো ঝকঝকে “enterprise” গল্পের চেয়ে বেশি ঘটে: আপনাকে কাউকে একটি ফাইল (বা ফোল্ডার) এখনই পাঠাতে হবে, কিন্তু ইমেইলের সীমা ছোট, ক্লাউড লিংক পলিসি বা আইনি কারণে সংবেদনশীল, আর “একটু সময়ের জন্য একটা পোর্ট খুলে দেই” অপশন নয়।
শুক্রবার, 16:47। প্রায় 60 কর্মীর একটি কোম্পানিতে জরুরি সমস্যা: কেন্দ্রীয় ফাইল সার্ভার ধীর, ব্যবহারকারীরা টাইমআউট রিপোর্ট করছে, এবং বাহ্যিক IT প্রোভাইডার logs ও ছোট একটি config export সহ একটি support bundle চাইছে। bundle প্রায় 900 MB। ইমেইল ব্লক করে, compliance কারণে SharePoint নিষিদ্ধ, আর ad-hoc FTP দাঁড় করানো 2026 সালে এমন ঝামেলা যা আপনি তৈরি করতে চাইবেন না।
এখানেই magic-wormhole কাজের: একবারের কোড শেয়ার করুন, end-to-end এনক্রিপ্টেড ট্রান্সফার করুন, হয়ে গেল।
magic-wormhole কী?
magic-wormhole হলো দুইটি কম্পিউটারের মধ্যে ad-hoc ফাইল ট্রান্সফার করার জন্য একটি হালকা টুল। কৌশলটা wormhole code (যেমন 7-coral-lion)। দুই পক্ষ একই কোড দেয়, আর সেটার ভিত্তিতে একটি end-to-end এনক্রিপ্টেড সংযোগ তৈরি হয়।
গুরুত্বপূর্ণ হলো, magic-wormhole যা লাগে না:
- কোনো অ্যাকাউন্ট নয়
- কোনো লগইন পোর্টাল নয়
- “কোথাও আপলোড করে লিংক শেয়ার” নয়
- inbound firewall rule নয়
দুই পক্ষের শুধু wormhole ইনস্টল থাকতে হবে এবং আউটবাউন্ড ইন্টারনেট লাগবে। বাস্তবে: HTTP(S) আউটবাউন্ড চললে magic-wormhole সাধারণত চলেও।
SMB-এর একটি বাস্তব উদাহরণ
শুক্রবারের কেসে বাস্তবসম্মত ফ্লো সাধারণত এমন:
- একটি support bundle তৈরি করুন (logs, export, কিছু screenshot)।
- চাইলে hash বের করুন যাতে পরে নিশ্চিত হওয়া যায় ঠিক একই প্যাকেজ পৌঁছেছে।
- bundle টি magic-wormhole দিয়ে পাঠান।
- কোডটি দ্বিতীয় চ্যানেলে শেয়ার করুন (ফোন কল, আলাদা চ্যাট, বা পড়ে শোনানো)।
sender পাশে:
tar -czf support-bundle.tgz ./logs ./config-export
sha256sum support-bundle.tgz
wormhole send support-bundle.tgz
magic-wormhole কোড দেখাবে। receiver চালাবে:
wormhole receive
কোড দিন, ডাউনলোড চলবে, তারপর hash মিলিয়ে দেখুন। বাস্তব দুনিয়ায় “দ্রুত” কিন্তু “তবুও পরিষ্কার” এই কম্বিনেশন অনেক SMB-এর জন্য দারুণ কাজে দেয়।
আমি প্র্যাক্টিসে কীভাবে ব্যবহার করি
A থেকে B-তে ফাইল পাঠানো
Sender:
wormhole send /path/to/file.zip
Receiver:
wormhole receive
ফাইলটি বর্তমান ডিরেক্টরিতে সেভ হবে। আমি প্রায়ই একটি ছোট ফোল্ডার বানিয়ে নেই যাতে Downloads আর Desktop-এর মধ্যে হারিয়ে না যায়:
mkdir -p ~/wormhole-recv && cd ~/wormhole-recv
wormhole receive
ডিরেক্টরি পাঠানো
যদি একটি পুরো ফোল্ডার পাঠাতে হয়:
wormhole send --dir ./support-bundle/
ভেতরে কী ঘটে? (সংক্ষেপে, কোনো মার্কেটিং ছাড়াই)
ভেতরে magic-wormhole তিনটি কাজ করে, যেগুলো না হলে আপনাকে নিজে বানাতে হত: peer খুঁজে পাওয়া, নিরাপদভাবে key নির্ধারণ, এবং বিশ্বস্তভাবে ডাটা ট্রান্সফার, এমনকি NAT আর firewall বাধা দিলেও।
| ধাপ | কী ঘটে | কেন গুরুত্বপূর্ণ |
|---|---|---|
| 1. কোড | sender একটি ছোট one-time code তৈরি করে। | এই ট্রান্সফারের জন্য shared secret। |
| 2. Rendezvous | দুই ক্লায়েন্ট rendezvous server-এ যুক্ত হয় (ডিফল্ট: পাবলিক “mailbox”)। | inbound পোর্ট ছাড়াই একে অপরকে খুঁজে পায়। |
| 3. PAKE | SPAKE2 (PAKE) দিয়ে কোড থেকে shared key বের হয়। | ক্লাসিক key management ছাড়াই E2E key। |
| 4. Data path | আগে direct চেষ্টা, না হলে relay/transit। | NAT-এর পেছনেও কাজ করে। |
| 5. E2E transfer | end-to-end এনক্রিপশন ও integrity protection। | relay শুধু ciphertext দেখে। |
মূল কথা: rendezvous/relay হলো ইনফ্রা, কিন্তু আপনার ডাটা plaintext-এ থাকার জায়গা নয়।
নিরাপত্তা: শক্তি, সীমা, আর কিছু নিয়ম
magic-wormhole-এর ভালো দিক হলো এর সিকিউরিটি মডেল বেশ সোজাসাপ্টা: end-to-end encryption আছে, কিন্তু identity স্বয়ংক্রিয়ভাবে আসে না।
আপনি যা পাবেন
- End-to-end encryption: sender থেকে receiver পর্যন্ত কনটেন্ট সুরক্ষিত, relay থাকলেও।
- Short-lived access: কোডটি এক ট্রান্সফারের জন্য, দীর্ঘমেয়াদি পাসওয়ার্ড নয়।
- কম attack surface: কোনো server harden করতে হয় না, user management নেই, web UI নেই।
যেখানে সতর্ক থাকা দরকার
- কোডটাই পাসওয়ার্ড। যার কাছে কোড আছে, সেই peer। কোড যদি ওপেন টিকেটে চলে যায়, সমস্যা।
- ডিফল্টে audit নেই। কারও কাছে এটা সুবিধা, কারও কাছে deal-breaker। DLP/approval/traceability লাগলে অফিসিয়াল চ্যানেল ব্যবহার করুন।
- Endpoints-ই সত্য। sender compromised হলে যে কোনো কিছু পাঠাতে পারে। receiver compromised হলে ফাইল পাওয়া মাত্রই ঝুঁকি।
প্র্যাক্টিক্যাল নিয়ম (যেগুলো সত্যিই সাহায্য করে)
- টিকেট লিংক বা ফাইল কনটেক্সটের সাথে একই চ্যানেলে কোড শেয়ার করবেন না। ভালো: ফোন কল বা আলাদা প্রাইভেট চ্যাট।
- ধরে নিন logs-এ token, hostname বা ব্যক্তিগত ডাটা থাকতে পারে। শুধু দরকারি জিনিস পাঠান।
- গুরুত্বপূর্ণ artefact হলে hash আলাদা চ্যানেলে পাঠান এবং রিসিভের পর ভেরিফাই করুন।
ইনস্টলেশন (সংক্ষেপে এবং বাস্তবসম্মত)
অনেক সিস্টেমে package manager দিয়ে এক কমান্ডই যথেষ্ট:
- Debian/Ubuntu:
sudo apt install magic-wormhole - macOS:
brew install magic-wormhole
distro প্যাকেজ পুরোনো হলে pipx প্রায়ই সবচেয়ে পরিষ্কার পথ:
pipx install magic-wormhole
pipx ensurepath
আর যদি Python একদম না চান (minimal server, container, rescue environment): wormhole-william হলো compatible Go port, single binary হিসেবে।
অটোমেশন এবং self-hosting
কন্ট্রোলড workflow-এ magic-wormhole স্ক্রিপ্ট করে ব্যবহার করা যায়:
CODE="5-alpaca-orbit"
wormhole send --code "$CODE" /path/to/db.dump
Receiver:
wormhole receive --code "$CODE" --accept-file
এটা সুবিধাজনক, কিন্তু hard-code করলে আবার credential management শুরু। অটোমেট করলে ভালো secret handling এবং short lifetime রাখুন।
rendezvous/relay পুরোপুরি নিজের কন্ট্রোলে আনতে চাইলে ক্লায়েন্টকে নিজস্ব ইনফ্রায় পয়েন্ট করা যায়, যেমন:
--relay-urlআপনার rendezvous server-এর জন্য--transit-helperআপনার transit relay-এর জন্য
উপসংহার
magic-wormhole managed ও policy-driven ট্রান্সফার প্রসেসের বিকল্প নয়। কিন্তু দৈনন্দিন টুল হিসেবে এটি দারুণ: দ্রুত, কম ঘর্ষণ, এবং পরিষ্কার সিকিউরিটি মডেলসহ।
বিশেষ করে SMB দুনিয়ায়, যেখানে প্রতিটি সাপোর্ট রিকোয়েস্টে approvals-এর দীর্ঘ চেইন বানানোর সময় বা ইচ্ছা থাকে না, “যথেষ্ট নিরাপদ এবং সাথে সাথে ব্যবহারযোগ্য” টুল অনেক সময় ঠিক সেটাই যা দরকার।
উৎস এবং আরও পড়ার জন্য
- magic-wormhole documentation (Read the Docs)
- magic-wormhole on GitHub
- wormhole-william (Go, single binary)
- magic-wormhole on PyPI
পরবর্তীবার পর্যন্ত, Joe
