টানেল চালু হওয়ার পরেই UFW VPN-এর DNS সার্ভার ব্লক করে
ডিফল্ট-ডিনাই UFW পলিসি টানেল ইন্টারফেসকেও ঢেকে দেয়। ট্রাফিক দিক অনুযায়ী সাজান, tun0-এ পুশ করা রিজলভার অনুমোদন করুন, তারপর বাইরের পথ খুলুন।
VPN সংযুক্ত হওয়ার মুহূর্তেই নাম রিজলভ হওয়া বন্ধ হয়ে যায়, অথচ একটি পাবলিক ঠিকানায় ping এখনও উত্তর দেয় এবং ফায়ারওয়াল স্ট্যাটাসে ভুল দেখায় এমন কিছু থাকে না। পলিসিতে কিছুই বদলায়নি; যা বদলেছে তা হলো একটি নতুন ইন্টারফেস এসেছে, আর ডিফল্ট ডিনাই প্রথম প্যাকেট থেকেই সেটিকে ঢেকে দেয়। UFW দিক ও ইন্টারফেস অনুযায়ী সিদ্ধান্ত নেয়, তাই ওয়্যারলেস লিংকের জন্য লেখা নিয়ম টানেল থেকে বেরোনো ট্রাফিক সম্পর্কে কিছুই বলে না। সমাধান হলো অল্প কয়েকটি সংকীর্ণ নিয়ম, নির্দিষ্ট ক্রমে প্রয়োগ করা।
লক্ষণটি কেবল টানেল চালু হওয়ার পরেই দেখা যায়
ডিফল্ট-ডিনাই পলিসি ঠিক যা বলা হয়েছে তাই করে: মিলে যাওয়া নিয়ম নেই এমন সবকিছু প্রত্যাখ্যাত হয়, বিদ্যমান প্রতিটি ইন্টারফেসে। নিয়মগুলো লেখার সময় টানেলের অস্তিত্ব ছিল না, তাই তাদের কোনোটিই এটির সঙ্গে মিলতে পারে না, আর যে ডিনাই সব সময় ছিল তা এখন নাম রিজলিউশনে প্রয়োগ হয়। আক্ষরিক ঠিকানায় সরাসরি ট্রাফিক তখনও কাজ করতে পারে যখন কোনো প্রশস্ত allow সেটিকে ঢেকে দেয়, তাই পাবলিক রিজলভারে ping সফল হয় অথচ নাম খোঁজা ব্যর্থ হয়। ফাঁকটি হলো এমন একটি ইন্টারফেসের নিয়ম যা পলিসি কখনও দেখেনি।
এটাই আরও ব্যাখ্যা করে কেন ব্যর্থতাটি পরিষ্কারভাবে উল্টে যায়: টানেল নামিয়ে দিন আর নাম আবার রিজলভ হয়, কারণ কোয়েরিটি এমন ইন্টারফেসে ফিরে যায় যার নিয়ম আছে। কেবল টানেল চালু থাকা অবস্থায় ব্যর্থ হওয়া পলিসি DNS সমস্যা নয়, আর রিজলভার নিজেই টিউন করা এখানে সবচেয়ে বেশি সময় নষ্ট করে। রিজলভার কনফিগারেশন পড়ার আগে ইন্টারফেস তালিকা পড়ুন।
তিন দিক, তিনটি ভিন্ন নিয়ম-সেট
একটি সেশন একাধিক দিকে নিয়ম স্পর্শ করে, আর টানেল প্রায় প্রতিটিতেই দ্বিতীয় একটি ইন্টারফেস যোগ করে। ট্রাফিক আগে দিক ও ইন্টারফেস অনুযায়ী সাজালে বাকিটা যান্ত্রিক হয়ে যায়, কারণ নিচের প্রতিটি সারির নিজের জায়গায় নিজের নিয়ম দরকার। উদাহরণগুলো tun0 এবং 10.8.0.0/24 পুল ব্যবহার করে, তাই ক্লায়েন্টের নিজের আউটপুট থেকে নাম ও রেঞ্জ বসান।
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
দুটি সারি প্রায়ই গুলিয়ে যায়, কারণ দুটিই টানেলের কথা বলে। রিজলভারের নিয়ম ক্লায়েন্ট টানেলে যে ট্রাফিক পাঠায় তা অনুমোদন করে, আর SSH-এর নিয়ম সার্ভার তা থেকে যে ট্রাফিক পায় তা অনুমোদন করে; তারা আলাদা মেশিনে থাকে এবং স্বতন্ত্রভাবে ব্যর্থ হয়। সবচেয়ে বেশি ভুলে যাওয়া সারিটি দ্বিতীয়টি, কারণ সার্ভারের পাবলিক ঠিকানায় ক্লায়েন্টের ট্রাফিক অনুমোদিত না হওয়া পর্যন্ত ক্লায়েন্ট টানেলই তৈরি করতে পারে না। উপর থেকে নিচে কাজ করুন এবং প্রতিটি ব্যর্থতার একটি সম্ভাব্য কারণ থাকে।
পুশ করা রিজলভারের নিজের নিয়ম দরকার
টানেল DNS বহন করবে কি না তা নির্ভর করে সার্ভার কী পাঠায় তার উপর। যে সার্ভার রিজলভার অপশন পুশ করে সে ক্লায়েন্টের কনফিগারেশনে একটি প্রাইভেট ঠিকানা বসায়, আর সেই ঠিকানা কেবল টানেলের মধ্য দিয়েই রুটযোগ্য। সার্ভার কিছুই পুশ না করলে ক্লায়েন্ট আগের রিজলভারই রাখে, আর নিচের নিয়মগুলোর অনুমোদন করার মতো কিছু থাকে না। কিছু লেখার আগে পুশ করা অবস্থা ও বর্তমান কোয়েরি ফলাফল দেখুন:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedস্ট্যাটাস আউটপুট ব্যবহার হচ্ছে এমন রিজলভার এবং এটি যে লিংকে বাঁধা তার নাম বলে, আর তার পেছনের রুট লুকআপ দেখায় কোন ইন্টারফেস ওই ঠিকানায় কোয়েরি বহন করবে। রিজলভার অন্য লিংকে থাকলে সমস্যাটি ফায়ারওয়ালের আগেই, আর কোনো নিয়মই সাহায্য করবে না। দুটোই টানেলের ব্যাপারে একমত হলে দুটি নিয়ম দরকার, কারণ বেশিরভাগ কোয়েরি UDP বহন করে আর উত্তর কেটে গেলে TCP দায়িত্ব নেয়। দুটি মানই লিখে রাখুন, কারণ নিয়মগুলো ঠিক এগুলোর নামই নেবে:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'ভেতরের পথের আগে বাইরের পথ খুলুন
টানেল তৈরির আগেই ক্লায়েন্টকে সার্ভারের পাবলিক ঠিকানায় পৌঁছাতে হয়, তাই এর নিয়মটি ফিজিক্যাল লিংকে বসে এবং আগে থেকেই থাকতে হয়। যে পলিসি রিজলভার অনুমোদন করে কিন্তু সার্ভার ভুলে যায়, তা ক্লায়েন্টকে টানেলই তৈরি করতে দেয় না, আর এই লক্ষণকে সাধারণত kill switch-এর উপর চাপানো হয়। তারপর আপনি আসলে যে সেবাগুলো টানেল দিয়ে চেয়েছিলেন সেগুলো অনুমোদন করুন, একবারে একটি সংকীর্ণ নিয়ম করে, ইন্টারফেস পুরোটা খোলার বদলে। সংকীর্ণ নিয়মগুলোই সেই কারণ যার জন্য ডিনাই জায়গায় থাকতে পারে।
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'পরীক্ষার সময় ক্রম গুরুত্বপূর্ণ, কারণ প্রথম নিয়মটিই টানেলকে আদৌ চালু হতে দেয়। এটি যোগ করুন, সংযুক্ত হন, এবং সেবা-নিয়ম যোগ করার আগে টানেল চালু আছে নিশ্চিত করুন, কারণ দুটোই একসাথে করলে ব্যর্থতা কোন অর্ধেকটা ভুল তা কিছুই বলে না। উপরের ডকুমেন্টেশন ঠিকানার জায়গায় ক্লায়েন্ট যে এন্ডপয়েন্ট ব্যবহার করতে কনফিগার করা আছে তা বসান।
ইচ্ছাকৃতভাবে সংযোগ বিচ্ছিন্ন করে ক্লায়েন্টের দিকটি শেষ করুন। ডিনাই এখনও সেই ট্রাফিক প্রত্যাখ্যান করবে যা আপনি ইচ্ছাকৃতভাবে বাদ দিয়েছেন, কারণ টানেল চালু থাকা অবস্থায় উত্তর দেওয়া রিজলভার সন্দেহ হলে প্রত্যাখ্যান করা পলিসির কেবল অর্ধেকটা ঢাকে।
সংযুক্ত হওয়া ক্লায়েন্ট এখনও অনুমোদিত নয়
সার্ভারেরও নিজের দিক ভাবতে হয়, আর হ্যান্ডশেক সম্পূর্ণ করা ক্লায়েন্ট সার্ভার তাকে অনুমোদন না করা পর্যন্ত সার্ভারে চলা কিছুই পৌঁছাতে পারে না। পাবলিক লিসেনার নিয়ম কেবল টানেলের অস্তিত্বের অনুমতি দেয়; তা টানেলের ট্রাফিক ঢুকতে দেয় না। সার্ভারে এটি দুটি নিয়ম আর সঙ্গে একটি পরীক্ষা যে সেবাটি সত্যিই শুনছে:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'নিয়মের পুলটি সার্ভার যে রেঞ্জ বরাদ্দ করে তার সমান হতে হবে, আর টানেল নম্বরটি সার্ভার তৈরি করা নম্বরের সঙ্গে মিলতে হবে, কারণ ভিন্ন ইন্টারফেসের নিয়ম আর কোনো নিয়ম না থাকা আলাদা করা যায় না। limit প্রশাসনিক পোর্টের জন্য ইচ্ছাকৃত, কারণ এটি পুনরাবৃত্তি সংযোগ সীমিত করে, সীমাহীনভাবে অনুমোদন করার বদলে। লিসেনার পরীক্ষা বন্ধ পোর্ট আর ফেলে দেওয়া প্যাকেটের মধ্যে পার্থক্য করে, যা ক্লায়েন্টের দিক থেকে একইরকম দেখায়। নম্বরযুক্ত নিয়মগুলোও পুরো চিত্র নয়: UFW-এর before নিয়ম এবং হাতে লেখা যেকোনো nftables লাইন আগে মেলে এবং তালিকা যে প্যাকেট অনুমোদন করে বলে মনে হয় তাও এখনও প্রত্যাখ্যান করতে পারে।