কেন ASA-র দূরবর্তী ব্যবহারকারী সাবনেটে পৌঁছায় কিন্তু অ্যাপে পৌঁছায় না
রুট প্রমাণ করে টানেল কাজ করছে, ব্যবহারকারী অ্যাপ খুলতে পারবেন তা নয়। সেশন যে ফিল্টার পেয়েছে তা পড়ুন, তারপর অনুমোদিত ও প্রত্যাখ্যাত সংযোগ পরীক্ষা করুন।
আপনার ব্যবহারকারী সংযুক্ত হন, ঠিকানা পান, অ্যাপের সাবনেটে থাকা সার্ভারে পিং করেন, তবুও সেটির পরিষেবা খুলতে পারেন না। এই সমন্বয় ASA-তে স্বাভাবিক, কারণ সফল টানেল এবং ব্যবহারযোগ্য অনুমতি ভিন্ন সেটিংসে নির্ধারিত হয়। স্প্লিট-টানেল তালিকা বেছে নিয়েছিল কোন গন্তব্যগুলো টানেলে ঢুকবে; VPN ফিল্টার এবং গন্তব্যের নিজস্ব অ্যাক্সেস নিয়ম নির্ধারণ করে ডিক্রিপ্ট করা অনুরোধ কোথায় পৌঁছাতে পারে। রুট তালিকা চওড়া করার বদলে তিনটি সিদ্ধান্ত ক্রমে দেখুন, কিছু বদলানোর আগেই।
সহজে গুলিয়ে ফেলা তিনটি সিদ্ধান্ত
প্রবেশ বলে ব্যবহারকারী আদৌ টানেল তৈরি করতে পারেন কি না: শংসাপত্র, সার্টিফিকেট এবং যেকোনো দ্বিতীয় উপাদান। রুট নির্বাচন বলে ক্লায়েন্ট কোন গন্তব্যগুলো ওই টানেলে পাঠায়। অনুমোদন বলে ডিক্রিপ্ট করা অনুরোধ পরিষেবায় পৌঁছাতে পারে কি না। ব্যবহারকারী যে ত্রুটি জানান তা কেবল তৃতীয়টিই তৈরি করে।
সেগুলো আলাদা করার দ্রুত উপায় হলো জিজ্ঞাসা করা, একটি পরিবর্তন কী ভাঙবে। স্প্লিট তালিকা থেকে রুট সরালে ওই সাবনেটে ট্রাফিক থামে কিন্তু কিছু দেয় না; VPN ফিল্টারে ACE যোগ করলে গন্তব্য দেওয়া হয় কিন্তু ক্লায়েন্ট টানেলে কী পাঠায় তা বদলায় না।
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
সেশন আসলে যে ফিল্টার পেয়েছে তা পড়ুন
আপনি যেটি প্রযোজ্য মনে করেন সেই কনফিগারেশন থেকে নয়, জীবন্ত সেশন থেকে শুরু করুন। show vpn-sessiondb detail anyconnect নির্ধারিত গ্রুপ নীতি এবং ওই সেশনে সংযুক্ত ফিল্টারের নাম ছাপে। ক্ষেত্রটি খালি হলে কোনো ফিল্টার কিছু প্রয়োগ করছে না এবং অবরোধ অন্য জায়গা থেকে আসছে।
তারপর যে নীতির মালিকানায় মানটি আছে তা ডিফল্টসহ পড়ুন, কারণ ফিল্টার আপনি যেখানে দেখছেন সেখানে লেখা না হয়ে উত্তরাধিকারে আসতে পারে:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
সেশনে থাকা ফিল্টার নামটি আপনি এইমাত্র সম্পাদনা করা ACL-এর সঙ্গে তুলনা করুন। ব্যবহারকারী কখনো না পাওয়া একই রকম নামের ACL ওই সেশনের সম্পদ নীতি বদলাতে পারে না, এবং সঠিক দেখতে পাওয়া পরিবর্তনের প্রভাব না থাকার এটাই সবচেয়ে সাধারণ কারণ।
অগ্রাধিকার বাকিটা ব্যাখ্যা করে। ফিল্টার সেটিংয়ের জন্য DAP রেকর্ড ব্যবহারকারীর নামের বৈশিষ্ট্যের উপরে, এবং ব্যবহারকারীর নামের বৈশিষ্ট্য গ্রুপ নীতির উপরে। সেশন অপ্রত্যাশিত ফিল্টার দেখালে গ্রুপ স্পর্শ করার আগে ওই ব্যবহারকারীর সঙ্গে মিলে যাওয়া DAP নীতি খুঁজুন।
স্প্লিট তালিকা ও ফিল্টার আলাদা ক্ষেত্র
ASA 9.x-এ গ্রুপ নীতি split-tunnel-network-list এবং vpn-filter কে ভিন্ন সেটিং হিসেবে রাখে, এবং 9.22 গ্রুপ-নীতি নির্দেশিকা ঠিক সেই কারণেই সেগুলো আলাদাভাবে নথিভুক্ত করে। নেটওয়ার্ক তালিকা ক্লায়েন্টের জন্য রাউটিং সংকেত; ফিল্টার হলো ডিক্রিপ্ট করা ট্রাফিকে প্রয়োগ করা অ্যাক্সেস নিয়ন্ত্রণ তালিকা।
ব্যবহারকারীর সাবনেটে একটিমাত্র HTTPS পরিষেবা দরকার হলে এই পার্থক্য গুরুত্বপূর্ণ। প্যাকেট টানেলে ঢোকার জন্য সাবনেটটি স্প্লিট তালিকায় রাখুন, তারপর ফিল্টারে কেবল সেই পরিষেবার অনুমতি দিন। রুট তালিকা চওড়া করলে কিছুই অনুমোদিত হয় না, আর সংকুচিত করা প্রয়োগের কৌশল নয়।
ইন্টারফেস ACL আদৌ পথে আছে কি না দেখুন
ডিক্রিপ্ট করা দূরবর্তী অ্যাক্সেস ট্রাফিক সবসময় বাইরের ইন্টারফেস ACL দিয়ে যায় না যেভাবে মানুষ ধরে নেয়। যেখানে sysopt connection permit-vpn সক্রিয়, সেখানে ASA ওই ট্রাফিকের জন্য তার নথিভুক্ত VPN বাইপাস প্রয়োগ করে, আর প্রযোজ্য VPN ফিল্টার তারপরও কার্যকর থাকে। সেটিংটি show run all sysopt দিয়ে পরীক্ষা করুন, টপোলজি চিত্র থেকে অনুমান না করে।
যেভাবেই হোক, গন্তব্য হোস্টের নিজস্ব ফায়ারওয়াল এবং অ্যাপের অনুমোদন পথেই থাকে। TCP 443 অনুমোদনকারী ASA নিয়ম অ্যাপকে ব্যবহারকারী গ্রহণ করতে বাধ্য করে না।
প্রত্যাখ্যাত সংযোগ দিয়েও পরিবর্তনটি গ্রহণ করুন
কেবল অনুমোদিত পরীক্ষা খুব কম প্রমাণ করে, কারণ ফিল্টার থাকুক বা না থাকুক কার্যকর টানেল একই প্রথম প্যাকেট তৈরি করে। ক্লায়েন্ট থেকে নির্দিষ্ট পরিষেবাটি খুলুন, তারপর বন্ধ থাকা উচিত এমন গন্তব্য চেষ্টা করুন এবং সঠিক কারণে ব্যর্থ হয় তা নিশ্চিত করুন।
টিকিট বন্ধ করার সময় চারটি তথ্য নথিভুক্ত করুন: গৃহীত পরিচয়, সেশন আসলে যে নীতি ও ফিল্টার পেয়েছে, স্প্লিট তালিকার গন্তব্যগুলো এবং ব্যবহারকারী যে সম্পদে পৌঁছানোর অনুমতি পেয়েছিলেন। এই চারটি রুট তালিকাকে ফায়ারওয়ালে পরিণত না করেই ট্রাফিক কোথায় নিয়ন্ত্রিত হয় তা ব্যাখ্যা করে।
ফিল্টার অনুমতি দেওয়ার পরেও পরিষেবা প্রত্যাখ্যান করলে হোস্টে যান: শ্রবণ ঠিকানা, হোস্ট ফায়ারওয়াল এবং অ্যাপের নিজস্ব ব্যবহারকারী ম্যাপিং। তখন টানেল তার কাজ করেছে, এবং ASA-তে আরও পরিবর্তন কেবল ঝুঁকি যোগ করে।