দুটি আলাদা নিয়ম ঠিক করে একটি VPN টানেল ফায়ারওয়াল পার হবে কি না: ক্লায়েন্ট যে পোর্টে ডায়াল করে, আর যে প্রোটোকল পেলোড বহন করে। শুধু প্রথমটি খুললে টানেল প্রমাণীকরণ পার হয়, তারপর কোনো ডেটা চলে না। সর্বনিম্ন হলো PPTP-এর জন্য একটি TCP পোর্ট ও GRE, L2TP/IPsec ও IKEv2-এর জন্য দুটি UDP পোর্ট ও ESP, আর SSTP, OpenVPN ও WireGuard-এর জন্য একটি করে পোর্ট। দিক, অবস্থা ট্র্যাকিং ও NAT বাকিটা ঠিক করে।

ক্লায়েন্ট যে পোর্টে ডায়াল করে সেখান থেকেই শুরু করুন

প্রতিটি পরিবারের একটি প্রবেশবিন্দু থাকে যেখানে ক্লায়েন্ট প্রথম যোগাযোগ করে, আর আপনার অনুমতি নিয়মে সেই প্রবেশবিন্দুরই নাম থাকতে হবে। PPTP ক্লায়েন্ট TCP 1723-এ সংযোগ করে। L2TP/IPsec UDP 500-এ IKE শুরু করে এবং NAT ট্রাভার্সাল চালু হলে UDP 4500-এ সরে যায়, আর L2TP ফ্রেম নিজে টানেলের ভিতরে UDP 1701-এ থাকে। SSTP সেশনটি TCP 443-এ TLS-এ মুড়ে দেয়, IKEv2 UDP 500 ও 4500-এ দরকষাকষি করে, OpenVPN ডিফল্টে UDP 1194 ব্যবহার করে কিন্তু প্রায়ই TCP 443-এ সরানো হয়, আর WireGuard UDP 51820-এ শোনে।

FamilyRule to add on the gatewayTypical mistake
WireGuardUDP port from ListenPort, for the peer addressAssuming 51820 when the config says otherwise
OpenVPNThe configured UDP or TCP port, often 443Opening 1194 after the server moved
SSTPTCP 443 limited to the gateway IPAllowing 443 to any destination
IKEv2UDP 500 and UDP 4500, plus ESPAllowing only 500 and losing NAT-T
L2TP/IPsecUDP 500, 4500, ESP, and 1701 inside the tunnelExposing 1701 to the internet
PPTPTCP 1723 and IP protocol 47Writing a rule for TCP 47

ওই সংখ্যাগুলোকে নির্দিষ্ট বৈশিষ্ট্য নয়, ডিফল্ট মান হিসেবে ধরুন। একটি WireGuard ইন্টারফেস তার কনফিগারেশন যে লিসেন পোর্ট ঘোষণা করে সেটাই ব্যবহার করে, আর একটি OpenVPN সার্ভার প্রশাসকের বেছে নেওয়া যেকোনো পোর্টে বসতে পারে। নিয়ম লেখার আগে সার্ভার কনফিগারেশন পড়ুন, কারণ 1194-এর জন্য খোলা ফায়ারওয়াল 443-এ সরানো সার্ভারের জন্য কিছুই করে না।

তৃতীয় কলামটাই যেখানে বেশিরভাগ পরিবর্তন টিকিট ভুল হয়ে যায়। নিয়মটি আছে, কিন্তু তা ভুল গন্তব্য, ভুল দিক বা ভুল ট্রান্সপোর্টের দিকে ইশারা করে।

GRE ও ESP প্রোটোকল নম্বর, পোর্ট নয়

GRE ও ESP-এর কোনো পোর্টই নেই, তাই যে ফায়ারওয়াল ফর্ম শুধু পোর্ট নম্বর নেয় তা এদের প্রকাশ করতে পারে না। GRE হলো IP প্রোটোকল 47 আর ESP হলো IP প্রোটোকল 50, দুটোই IP হেডারের প্রোটোকল ফিল্ড দিয়ে মেলানো হয়। TCP পোর্ট 47 হিসেবে লেখা নিয়ম কোনো কিছুর সঙ্গে মেলে না, এভাবেই একটি PPTP নীতি সঠিক দেখায় অথচ হ্যান্ডশেকের পর প্রতিটি প্যাকেট ফেলে দেয়।

ভোক্তা রাউটার এটা লুকিয়ে রাখে একটি পাসথ্রু চেকবক্সের পিছনে, যা প্রোটোকল নিয়মটি বসায় এবং GRE-এর ক্ষেত্রে প্রবাহ ম্যাপ করার জন্য দরকারি NAT সহায়কটিও বসায়। আসল ফায়ারওয়ালে আপনি নিজেই প্রোটোকল যোগ করেন: PPTP সার্ভারে IP প্রোটোকল 47 অনুমোদন করুন, IPsec গেটওয়েতে IP প্রোটোকল 50 অনুমোদন করুন। যেখানে প্ল্যাটফর্মে প্রোটোকল ফিল্ড নেই, সেখানে এনক্যাপসুলেশনই পথ, তাই IKEv2 UDP 4500-এ ফিরে যেতে পারে এবং তাই OpenVPN ও WireGuard কখনো এই সমস্যায় পড়ে না।

ক্লায়েন্টকে দোষ দেওয়ার আগে দেখুন নিয়মটি আসলে কী মেলায়। গেটওয়েতে শূন্যে থেমে থাকা প্যাকেট কাউন্টার বলে নিয়মটি কখনো চালু হয়নি, আর ক্লায়েন্টের দিকে যতবারই পুনরায় ইনস্টল করুন তা বদলায় না।

দিক, অবস্থা ও NAT উত্তর বদলে দেয়

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

NAT ট্রাভার্সালই সেই অংশ যা বাদ পড়ে। IKEv2 UDP 500-এ শুরু হয়, NAT ডিভাইস শনাক্ত করে, তারপর UDP 4500-এ চলতে থাকে, তাই শুধু 500 অনুমোদনকারী নীতি এমন টানেল দেয় যা প্রতিষ্ঠিত হয় তারপর চুপ হয়ে যায়। L2TP/IPsec-ও একই সরে যায়। আপনার ক্যাপচার যদি প্রথম বিনিময় দেখায় কিন্তু স্থায়ী ট্রাফিক না দেখায়, তাহলে 500-এ থেমে যাওয়া নিয়ম খুঁজুন।

প্রতিটি নিয়মের সঙ্গে দিক লিখে রাখুন। «UDP 4500 অনুমোদন করুন» অর্থহীন যতক্ষণ না বলেন কোথা থেকে কোথায়, আর ভ্রাম্যমাণ ক্লায়েন্টের জন্য ঠিক নিয়ম সাধারণত সাইট-থেকে-সাইট সমকক্ষের জন্য ভুল।

ক্যাপচার দিয়ে প্রতিটি পথ যাচাই করুন

ক্যাপচার গেটওয়েতে চালান, ক্লায়েন্টে নয়: ক্লায়েন্ট শুধু যা এসেছে তা লিখে রাখে। এই ফিল্টারগুলো উপরের পরিবারগুলো ঢেকে দেয় এবং কোন ধাপটি অনুপস্থিত তা দেখায়:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

আউটপুটটি একটি ক্রম হিসেবে পড়ুন। যখন দরকষাকষি দেখা যায় কিন্তু পেলোড প্রোটোকল দেখা যায় না, ড্রপটি ক্লায়েন্ট ও গেটওয়ের মাঝে কোথাও ঘটে। যখন দুটোই দেখা যায় আর পৃষ্ঠা তবুও ব্যর্থ হয়, তখন ফায়ারওয়াল আর সন্দেহভাজন নয়; রাউটিং, DNS বা ক্লায়েন্টকে দেওয়া অ্যাড্রেস পুল দেখুন।

tcpdump নেই এমন বক্সে একই প্রমাণ আসে ইন্টারফেস ও নিয়ম কাউন্টার থেকে। টানেল ইন্টারফেসে বাইট ঢোকে কিন্তু বেরোয় না, তা প্রাথমিক অনুমতি নিয়মের নয় বরং ফেরার পথের দিকে ইশারা করে।

এমন নিয়মের সেট রেখে যান যা আপনি রক্ষা করতে পারেন

TCP 443-এ SSTP যেকোনো পোর্টভিত্তিক ফিল্টারের কাছে সাধারণ HTTPS থেকে আলাদা করা যায় না, আর নেটওয়ার্ক যখন শুধু ওয়েব ট্রাফিক অনুমোদন করে তখন এটাই উদ্দেশ্য। এজন্যই 443-এর নিয়মে গোটা ইন্টারনেটের বদলে গেটওয়েকে গন্তব্য হিসেবে নাম দিতে হবে। টানেল কাজ করা মাত্র সাময়িক যে-কেউ-থেকে-যে-কেউ নিয়ম মুছে ফেলুন। কোন নিয়ম মিলল, যেখানে আছে সেখানে প্রোটোকল নম্বর, আর দিক লিখে রাখুন, যাতে পরের ব্যক্তি প্রমাণ থেকে শুরু করতে পারেন।

ক্লাউড পয়েন্ট-টু-সাইট গেটওয়ে বেছে নেওয়াটা দৃশ্যমান করে: ডাউনলোড করা প্রোফাইল হয় 443-এ SSTP নয়তো 500 ও 4500-এ IKEv2 ব্যবহার করে, আর প্রোফাইলটি আসলে যেটি বেছে নেয় শুধু সেটিই খোলা উচিত। আধুনিক নেটওয়ার্কে PPTP GRE ব্যতিক্রমের যোগ্য নয়, কারণ মোবাইল অপারেটররা আপনার ফায়ারওয়াল নির্বিশেষে প্রোটোকল 47 প্রায়ই ফেলে দেয়। টিকিট বন্ধ করার আগে নিশ্চিত করুন যে নিয়মটি সার্ভার কনফিগের পোর্টের সঙ্গে মেলে, প্রোটোকল ফিল্ড সেখানে সেট আছে যেখানে পরিবারের তা দরকার, আর গন্তব্য যেকোনো অ্যাড্রেস নয় বরং গেটওয়ে।

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