অফিস ও VPN-এর জন্য একটি URL? কেন অনুমোদিত তালিকার কল্পনা ব্যর্থ হয়

VPN সংযোগ অনুমোদিত সাইটটি যে ঠিকানা দেখে তা বদলায় না। URL যোগ করার আগে প্রকৃত নির্গমন, বিশ্বস্ত প্রক্সি হপ এবং IPv6 পথ যাচাই করুন।

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

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

কল্পনা: সংযোগ করা মানে রাউটিং নয়

একটি টানেল প্রতিষ্ঠিত হয়, এবং ক্লায়েন্ট কিছু প্রিফিক্সের জন্য রুট ইনস্টল করে। সংযোগ করার কাজ পুরোটাই এটুকু। একটি সম্পর্কহীন HTTPS অনুরোধ টানেলের ভেতর দিয়ে যাবে কি না, এবং পৌঁছালে এটি কোন পাবলিক ঠিকানা থেকে আসছে বলে দেখাবে, এগুলি পরের সিদ্ধান্ত যা নেয় অন্য উপাদান: রাউটিং টেবিল পথ বেছে নেয়, আর প্রস্থান উৎস বেছে নেয়।

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

তিনটি অনুরোধ-অবস্থা, দুটি অনুমোদিত প্রস্থান

ফায়ারওয়াল স্পর্শ করার আগেই ম্যাট্রিক্সটি লিখে ফেলুন, কারণ সারণিটিই নকশা আর নিয়মটি তার একটি বাস্তবায়ন মাত্র। নিচের ঠিকানাগুলি ডকুমেন্টেশন রেঞ্জ; এগুলি নিজের রক্ষণাবেক্ষিত মান দিয়ে বদলান এবং সাইট-মালিক যেখানে যাচাই করতে পারেন সেখানে রাখুন।

Request pathSource the site seesIntended decision
Office, no tunnelOffice public exitAdmit to the application login
Remote, approved full tunnelApproved VPN egressAdmit to the same login
Remote, ordinary connectionNeither approved addressDeny at the network boundary

এই পরিকল্পনাগুলির বেশিরভাগই ভেঙে পড়ে মাঝের সারিতে। গণ্য হয় সেই ঠিকানা যা প্রয়োগকারী ডিভাইস দেখে, ল্যাপটপ টানেলের ভেতরে যে ব্যক্তিগত ঠিকানা রাখে তা নয় এবং তার LAN ঠিকানাও নয়। 10.8.0.6 এর মতো একটি মান পাবলিক সাইটের কাছে কিছুই বোঝায় না, 192.168.1.44-ও না। টানেলের ঠিকানা টানেলের অ্যাড্রেসিং-বিস্তারিত, সাইট যাচাই করতে পারে এমন কোনো পরিচয়পত্র নয়।

আপনার VPN যদি স্থিতিশীল, নথিভুক্ত নির্গমন দিতে না পারে, তবে ম্যাট্রিক্সে বৈধ মাঝের সারি নেই এবং যতই অনুমোদিত তালিকা বানান না কেন একটি তৈরি হবে না। সেই মুহূর্তে সৎ বিকল্প হলো স্পষ্ট ব্যক্তিগত রুট দিয়ে পৌঁছানো একটি ব্যক্তিগত সাইট, বা অ্যাপ্লিকেশনের সামনে পরিচয়-সচেতন অ্যাক্সেস গেটওয়ে। দুটিরই পাবলিক অনুমোদিত তালিকার চেয়ে ভিন্ন চুক্তি, আর দুটিই নিরীক্ষকের কাছে ব্যাখ্যা করা সহজ, এমন একটি তালিকার চেয়ে যা কাজ করতে শুরু করা পর্যন্ত বেড়েছে।

যেখানে সিদ্ধান্ত নেওয়া হয় সেখানেই উৎসটি পড়ুন

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

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

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

বিভক্ত টানেল: যে অনুরোধ কখনো ঢোকে না

একটি বিভক্ত টানেল কেবল তার তালিকার প্রিফিক্সগুলি বহন করে। অফিসের অভ্যন্তরীণ সাবনেট সাধারণত সেই তালিকায় থাকে; পাবলিক ওয়েবসাইট থাকে না। ব্রাউজার নামটি রিজলভ করে, নির্বাচিত ঠিকানাটি রাউটিং টেবিলের সঙ্গে মেলায়, এবং তবুও সামনে স্থানীয় ডিফল্ট গেটওয়ে খুঁজে পায়।

তাই অনুরোধটি আসে ব্যবহারকারীর হোম সংযোগ থেকে, প্রত্যাখ্যাত হয়, আর প্রতিবেদনে লেখা হয় VPN নষ্ট, অথচ টানেল ঠিক তা-ই করছে যার জন্য এটি কনফিগার করা হয়েছিল। দুটি সমাধান বৈধ: ওই গন্তব্যটি টানেলের ভেতর দিয়ে পাঠান এবং অনুমোদিত নির্গমনকে এটি বহন করতে দিন, অথবা মেনে নিন যে সাইটটি সরাসরি পৌঁছায় এবং দূরবর্তী ব্যবহারকারীদের অ্যাক্সেস গেটওয়ের মতো অন্য একটি অনুমোদিত পথ দিন। সাইটের পাবলিক অনুমোদিত তালিকা বাড়াতে থাকা যতক্ষণ না কোনো হোম ঠিকানা দৈবাৎ ঢুকে পড়ে, তা কোনোটিই নয়, এবং এটি সেই সীমাই সরিয়ে দেয় যা নকশার প্রয়োগ করা কথা ছিল। প্রথম দুটি ম্যাট্রিক্সকে সৎ রাখে; তৃতীয়টি নীরবে তা থেকে একটি সারি মুছে দেয়।

অস্বীকৃতি প্রমাণ করুন, তারপর পুনরুদ্ধার

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

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

নেটওয়ার্কে প্রবেশের পরে অ্যাপ্লিকেশন প্রমাণীকরণ রাখুন, কারণ অফিস প্রস্থান ও VPN নির্গমন প্রত্যেকটি অনেক মানুষের প্রতিনিধিত্ব করে এবং কোনোটিই কোনো ব্যক্তিকে শনাক্ত করে না। ব্যবহারকারীদের নির্দেশ সংক্ষিপ্ত থাকে: অনুমোদিত টানেল চালু করুন, তারপর আবার চেষ্টা করুন। এটাই একটি URL-কে সুবিধাজনক রাখে যখন উৎস-নিয়মটি অনুমানের বদলে সিদ্ধান্তই থাকে।

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