টানেল ইন্টারফেসে TCP 873 অনুমোদন করলে rsync OpenVPN-এর মধ্য দিয়ে যায় না, আর তাতেও দূর প্রান্ত মডিউলটি গ্রহণ করে না। টানেল একটি অভ্যন্তরীণ সংযোগ বহন করে যার প্রোটোকল ও গন্তব্য নিয়ম আগের মতোই থাকে। তাই প্রথম প্রশ্ন কোন পোর্ট খুলব তা নয়, বরং rsync কোন ধরনের সংযোগ করছে তা। নিচের সবকিছু ধরে নেয় টানেল ইতিমধ্যে চালু এবং কেবল অভ্যন্তরীণ সেবাটিই সন্দেহে আছে।

rsync আসলে কোন সংযোগ করে তা নির্ধারণ করুন

কমান্ডের রিমোট আর্গুমেন্ট সাধারণত ফায়ারওয়াল বদলের আগেই ওই প্রশ্নের উত্তর দেয়। ডাবল কোলন বা URL স্কিম ডেমন বেছে নেয়, আর হোস্ট নামের পরে একক কোলন রিমোট শেল বেছে নেয়। ডকুমেন্টেশনের উদাহরণের আর্গুমেন্ট নয়, আপনি সত্যিই যে আর্গুমেন্ট চালাচ্ছেন সেটি পড়ুন।

স্পষ্ট রিমোট-শেল অপশন উত্তরটি আবার বদলে দিতে পারে, কারণ এটি rsync-কে বলে পরিবহনের জন্য কোন প্রোগ্রাম চালু করতে হবে। শুধু হোস্ট অংশ নয়, উত্তরাধিকারসূত্রে পাওয়া র‍্যাপার স্ক্রিপ্টসহ পুরো কমান্ড লাইনটি পড়ুন।

Remote argumentWhat it opens
rsync://vault.corp.internal/archive/rsync daemon, normally TCP 873
vault.corp.internal::archive/rsync daemon, normally TCP 873
[email protected]:/srv/archive/Remote shell, normally SSH on its configured port

ডেমন মোড: বাইন্ড ঠিকানা, মডিউল ও পোর্ট

ডেমন সিনট্যাক্সে পথের অংশটি ডিস্কের কোনো ডিরেক্টরি নয়, একটি কনফিগার করা মডিউল বোঝায়। সংযোগ গ্রহণের পরেই কেবল মডিউল পাসওয়ার্ড যাচাই হয়, এবং মডিউলটি অতিরিক্তভাবে শুধু-পাঠযোগ্য বা তালিকা থেকে লুকানো থাকতে পারে। ত্রুটি পড়ার সময় এই ক্রমটি গুরুত্বপূর্ণ, কারণ প্রত্যাখ্যাত সংযোগ আর প্রত্যাখ্যাত মডিউল দুটি ভিন্ন ধাপের ব্যর্থতা। কোনও বার্তাই টানেল সম্পর্কে কিছু বলে না।

একটি স্বতন্ত্র ডেমন তার কনফিগারেশন ফাইলে টানেল ঠিকানায় পিন করা যায়, যা কোনো ফায়ারওয়াল নিয়ম ছাড়াই এটিকে পাবলিক ইন্টারফেসের বাইরে রাখে। ডেমন বাইন্ড করার সময় মানটি থাকতেই হবে, আর সকেট-সক্রিয় বা inetd-পরিচালিত লিসেনার এটি সম্পূর্ণ উপেক্ষা করতে পারে।

address = 10.44.0.1
port = 873
[archive]
    path = /srv/archive
    read only = yes

তারপর পাবলিক নাম নয়, ব্যক্তিগত ঠিকানার বিরুদ্ধে পরীক্ষা করুন। পাবলিক হোস্ট নাম WAN ঠিকানায় রিজলভ হয় এবং ভিন্ন পথ নেয়, এমনকি যখন একই মেশিন দুটিতেই উত্তর দেয়।

rsync --list-only rsync://10.44.0.1/archive/

রিমোট-শেল মোড: SSH-ই স্থানান্তর বহন করে

একক কোলন দিয়ে rsync একটি রিমোট-শেল প্রোগ্রাম চালু করে এবং সেই চ্যানেলের উপর দিয়ে তার প্রোটোকল বলে, তাই পৌঁছানো যায় কেবল SSH-তে, সার্ভার যে পোর্টেই শুনুক। rsync ডেমন কখনও চলে না, পোর্ট 873 অপ্রাসঙ্গিক, আর প্রবেশের সিদ্ধান্ত হয়ে যায় SSH অ্যাকাউন্টের সিদ্ধান্ত। রিমোট পথ তখন দূর প্রান্তের শেল যে বাস্তব ফাইলসিস্টেম পথ ব্যাখ্যা করে তা। এজন্যই 873 লক্ষ্য করা ফায়ারওয়াল বদল এই মোডে কিছুই করে না।

এই নকশার জন্য দরকার একটি অনুমোদিত অ্যাকাউন্ট ও হোস্ট কী যাচাই, এবং এটি SSH-এর নিজস্ব প্রমাণীকরণ নীতি উত্তরাধিকারে পায়। স্থানান্তরকে যখন অবিশ্বস্ত নেটওয়ার্ক পেরোতে হয় তখন এটি প্রায়ই ভালো পছন্দ, কারণ এনক্রিপশন এমন একটি প্রোটোকলের, যা তার জন্যই তৈরি। পাসওয়ার্ড চাওয়া ডেমন একই জিনিস নয়।

শুধু আপনি যে পথ বেছেছেন সেটিই খুলুন

মোড ঠিক হয়ে গেলে, টানেল বহনকারী একক ইন্টারফেসে একক অভ্যন্তরীণ সেবাটি অনুমোদন করুন। নিয়মটিকে ইন্টারফেস, সোর্স পুল ও গন্তব্য ঠিকানা দিয়ে সীমাবদ্ধ করুন, যাতে পরে ডিফল্ট-ডিনাই বদল চুপচাপ এটিকে প্রশস্ত করতে না পারে। এরপর নিয়মের ক্রম পর্যালোচনা করুন, কারণ চেইনের আগে থাকা অনুমোদনমূলক নিয়ম সংকীর্ণ নিয়মটিকে নিছক সাজসজ্জা করে তোলে।

ডেমন যদি VPN গেটওয়ের নিজের বদলে তার পেছনের মেশিনে চলে, তবে গেটওয়েরও একটি ফরওয়ার্ডিং পথ দরকার এবং লক্ষ্যের নিজস্ব অনুমতি ও ফেরত পথ দরকার। কেবল গেটওয়েতে পোর্ট খুললে এমন সংযোগ তৈরি হয় যা গ্রহণ হয় এবং তারপর কোথাও যায় না।

ক্লায়েন্ট থেকে উৎপাদনে যে মোড ও গন্তব্য ব্যবহারের ইচ্ছা আছে সেগুলো দিয়েই যাচাই করুন। সফল তালিকা লিসেনার, পথ ও নিয়ম একসাথে প্রমাণ করে; সময়সীমা পথের দিকে ইঙ্গিত করে, আর প্রত্যাখ্যান লিসেনারের দিকে।

ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873

সম্পর্কিত নিবন্ধ