মাল্টি: ক্লায়েন্টের কাছ থেকে খারাপ উত্স ঠিকানা - কোনও ওয়ান-অফ সমাধান?


10

সেটআপ: আমার একটি ওপেনভিএনএন ক্লায়েন্ট / সার্ভার সেটআপ রয়েছে (নীচে কনফিগার করা ফাইলগুলি) এবং আমি MULTI: bad source address from client [192.168.x.x], packet droppedসার্ভারে কুখ্যাত বার্তাটি পাই । সার্ভারের একটি সার্বজনীন আইপি ঠিকানা রয়েছে, যখন ক্লায়েন্ট NAT এর পিছনে রয়েছে।

পূর্বে প্রস্তাবিত সমাধানের ভুলত্রুটি:client-config-dir সার্ভার কনফিগ বর্তমানে খালি সংজ্ঞায়িত। পূর্ববর্তী পোস্টগুলি (এখানে এবং ওপেনভিএনপিএন সমর্থন ফোরামে) সমস্যাগুলির সমাধানের জন্য DEFAULTযথাযথ বিধি দ্বারা নামক একটি ফাইল client-config-dirযুক্ত করা বা সেই নিয়মগুলির সাথে প্রতি ব্যবহারকারী ফাইল যুক্ত করার পরামর্শ দেয়।

তবে এটি কোনও দীর্ঘমেয়াদী সমাধান বলে মনে হচ্ছে না, কারণ এই নিয়মগুলি ক্লায়েন্ট-অবস্থান নির্দিষ্ট। সুতরাং, আমি ক্লায়েন্টকে 192.168.x.0সংযুক্ত হতে অনুমতি দেওয়ার জন্য একটি বিধি যুক্ত করতে পারি । তবে যদি তারা অন্য কোনও নেটওয়ার্ক থেকে সংযোগ করে যা পরিবর্তে 192.168.y.0NAT এর জন্য ব্যবহার করে তবে একটি নতুন নিয়ম প্রয়োজন হবে।

প্রশ্নাবলী:

  • প্রয়োজনীয় নিয়মগুলি জেনেরিক / ওয়ান-অফ উপায়ে লেখা যায়?
  • এই সমস্যাটি প্রথম স্থানে কেন ঘটে যায় কেউ ব্যাখ্যা করতে পারেন?

সার্ভার কনফিগারেশন:

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

ক্লায়েন্ট কনফিগারেশন:

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

আপনার সমস্ত ক্লায়েন্ট কি 192.168.xy নেটওয়ার্কে রয়েছে?
আইসমেজ

এটি আমার কাছে পরিষ্কার নয় ... আপনি কী বোঝাতে চেয়েছেন যে আপনি কোনও ক্লায়েন্ট চালু 192.168.x.0এবং 192.168.y.0নেটওয়ার্কে থাকা ক্লায়েন্টকে অন্যভাবে যাত্রা করতে চান ? 192.168.x.x/16আপনি যে সংজ্ঞায়িত করেছেন তারা সমস্ত একই নেটওয়ার্কে ... (?)
krisFR

উত্তর:


12

আপনি জিজ্ঞাসা করেছিলেন: " এই সমস্যাটি প্রথম স্থানে কেন ঘটে যায় কেউ ব্যাখ্যা করতে পারেন? "

অফিসিয়াল ওপেনভিপিএন এফএকিউ-র প্রতিবেদনের উপর ভিত্তি করে আমি বাজি ধরেছি যে এটি ওপেনভিপিএন ইঞ্জিনের মধ্যে একটি রাউটিং সমস্যার কারণে ঘটেছে।

দৃশ্যের আরও ভালভাবে স্পষ্ট করতে নীচের চিত্রটি উল্লেখ করুন:

এখানে আপনি দেখতে পারেন:

  • HEADQUARTER অভ্যন্তরীণ নেটওয়ার্কের সাথে সংযুক্ত একটি ওপেনভিপিএন "সার্ভার" (10.0.1.0/24)
  • একটি ওপেনভিপিএন "ক্লায়েন্ট" একটি দূরবর্তী সাইটে চলমান, এবং দূরবর্তী 192.168.1.0/24 নেটওয়ার্কের সাথে সংযুক্ত

এছাড়াও

  • আমরা ধরে নিচ্ছি যে ওপেনভিপিএন টানেলটি প্রতিষ্ঠিত হয়েছে এবং:
    • ওপেনভিপিএন "সার্ভার" তার নিজস্ব টিউন ইন্টারফেসের মাধ্যমে 10.10.0.1 ঠিকানার মাধ্যমে পৌঁছানো যায় । এছাড়াও টি 2 পি ঠিকানা, টিউন ইন্টারফেস দ্বারা ব্যবহৃত হয় 10.10.0.2 ( এটি পরবর্তী আলোচনার জন্য গুরুত্বপূর্ণ, সুতরাং আসুন এটির উপর জোর দিন )
    • ওপেনভিপিএন "ক্লায়েন্ট" এর আইপি 10.10.0.2 এর সাথে একটি সুরের ইন্টারফেস রয়েছে

এখন, ধরে নেওয়া যাক:

  • ওপেনভিপিএন "ক্লায়েন্ট" এটির ডিফল্ট গেটওয়েটিকে নতুনভাবে সংজ্ঞায়িত করেছে, তাই টানেলের মধ্যে সমস্ত বহির্গামী আইপি ট্র্যাফিক পুনর্নির্দেশ করতে;
  • ওপেনভিপিএন "ক্লায়েন্ট" এ আইপি_ফোরওয়ার্ডিং সক্ষম করেছে এবং এর মতো, অভ্যন্তরীণ ল্যান থেকে আগত প্যাকেটগুলি রুট করতে পারে (192.168.1.0/24) ( আমি এই বিষয়টির উপর জোর দিচ্ছি, কারণ এটি আমাদের আলোচনার জন্য গুরুত্বপূর্ণ )।

এ জাতীয় দৃশ্যধারণের জায়গায়, আসুন, বিশদভাবে পরীক্ষা করে দেখি যে আরএপসিসি 1 (192.168.1.2) এলপসিসি 1 (10.0.1.2) এ ইকো-অনুরোধের মতো একটি প্যাকেট প্রেরণ করবে তখন:

  1. আরএপসিসি 1 এনআইসি ছাড়ার পরে, প্যাকেটটি ওপেনভিপিএন ক্লায়েন্টে পৌঁছে;
  2. ওপেনভিপিএন ক্লায়েন্ট (এটি একটি সাধারণ রাউটার হিসাবে কাজ করার জন্য কনফিগার করা হয়েছে), এটির রাউটিং টেবিল অনুযায়ী এটি রুট করুন। এটির ডিফল্ট-গেটওয়েটি সুড়ঙ্গ হওয়ায় এটি প্যাকেটটি টানেলের কাছে প্রেরণ করে;
  3. প্যাকেট ওপেনভিপিএন সার্ভারের টিউন ইন্টারফেসে পৌঁছেছে। ওপেনভিপিএন এটি "দেখবে" এবং যেমন এটি (ওপেনভিপিএন সার্ভার) জানে যে 10.0.1.2 টি এটির ল্যান সাবনেটের একটি ঠিকানা, এটি প্যাকেটটি "টিআরএন" থেকে লুন পর্যন্ত;
  4. প্যাকেট L_PC1 এ পৌঁছেছে।

সুতরাং সবকিছু ঠিক আছে ...

এখন আসুন পরীক্ষা করুন যে এলএপসি 1 R_PC1 কে উত্তর দেয় এমন প্রতিধ্বনির সাথে কী হয়।

  1. ইকো-জবাব L_PC1 NIC ছেড়ে যায় এবং ওপেনভিপিএন সার্ভার ল্যান ইন্টারফেসে পৌঁছে (10.0.1.1);

এখন, আমরা যদি ওপেনভিপিএন সার্ভারটি প্রত্যন্ত সাইটে পৌঁছাতে সক্ষম হতে চাই, তবে আমাদের একটি "স্থির রুট" দিয়ে রাউটিংটি সংজ্ঞায়িত করতে হবে। কিছুটা এইরকম:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

গেটওয়ে হিসাবে ব্যবহৃত পি 2 পি ঠিকানা দয়া করে নোট করুন

এ জাতীয় স্থিতিশীল রুটগুলি ওএস-স্তরে পরিচালিত হবে। অন্য কথায়, অপারেটিং সিস্টেমের সঠিকভাবে প্যাকেটটি রুট করার জন্য এটি প্রয়োজন। এর অর্থ এইরকম: "দয়া করে, 192.168.1.0/24 সাবनेटকে সম্বোধন করা সমস্ত ট্র্যাফিকের ওপেনভিপিএন ইঞ্জিনে ফরোয়ার্ড করা দরকার, যার সাথে ওএস পি 2 পি ঠিকানার মাধ্যমে কথা বলতে সক্ষম হয়"। এই ধরণের স্থিতিশীল রুটের জন্য ধন্যবাদ, এখন ...

  1. প্যাকেটটি ওএস-রাউটিং প্রসঙ্গে ছেড়ে যায় এবং ওপেনভিপিএন-এ পৌঁছে যায়। ওপেনভিপিএন সার্ভারে চলছে ওপেনভিপিএন দৃষ্টান্ত। সুতরাং, এই মুহুর্তে, ওএসের আরও কিছু করার নেই এবং সমস্ত রাউটিং (ভিপিএন এর মধ্যে) ওপেনভিপিএন সার্ভার সফ্টওয়্যারটিতে ছেড়ে যায়।

সুতরাং, এখন, সমস্যাটি হল: কীভাবে, ওপেনভিএনপি সার্ভার সফ্টওয়্যার, এসআরসি_আইপি 10.0.1.2 এবং ডিএসআইআইপি 192.168.1.2 দিয়ে কোনও প্যাকেটের রুট নির্ধারণ করতে সক্ষম হবে ?

দয়া করে মনে রাখবেন যে ওপেনভিপিএন সার্ভারের কনফিগারেশনের উপর ভিত্তি করে এটি 192.168.1.0/24 নেটওয়ার্ক বা 192.168.1.2 হোস্ট সম্পর্কে কিছুই জানে না । এটা না একটি সংযুক্ত ক্লায়েন্ট। এটা না একটি স্থানীয় ক্লায়েন্ট। এবং তাই? VPN খুলুন, এছাড়াও, জানে যে এটা না "অপারেটিং সিস্টেম-রাউটার", তাই এটি সত্যিই চায় না (এবং .... পারেন) স্থানীয় গেটওয়েতে প্যাকেট ফেরত পাঠাতে। সুতরাং এখানে একমাত্র বিকল্পটি একটি ত্রুটি বাড়ানো। ঠিক আপনি যে ত্রুটিটি ভোগ করছেন তা ঠিক

এফএকিউ এর ভাষায় এটি বলতে: " ... এই মেশিনে প্যাকেটটি কীভাবে চালানো যায় তা এটি জানে না, সুতরাং এটি প্যাকেটটি ফেলে দেয় ... "।

কীভাবে আমরা সমস্যার সমাধান করতে পারি?

আপনি যেমন অফিসিয়াল ডকুমেন্টেশন থেকে দেখতে পাচ্ছেন , অপ্রয়োজনীয় বিকল্পটি আমাদের ক্ষেত্রের জন্য সঠিকভাবে কাজ করে:

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

সুতরাং আপনার একটি প্রয়োজন:

--iroute 192.168.1.0 255.255.255.0

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

আপনি আশ্চর্য উচিত কেন এই সমস্যা নেই না পদক্ষেপ 2 ঘটে) সর্বোপরি, আমার বোঝার যে VPN খুলুন ক্লায়েন্ট হয় জানেন কিভাবে এটা রুট, 'কারণ এটা জানে যে VPN এর টানেল একটি ডিফল্ট-গেটওয়ে প্রত্যাবর্তন করতে হবে।

ওপেনভিপিএন সার্ভারে একই কাজ করা যায় না, কারণ সেখানে ডিফল্ট গেটওয়ে টিপিকভাবে ওভাররাইড হয় না । এছাড়াও, বিবেচনা করুন যে আপনার প্রচুর ওপেনভিপিএন ক্লায়েন্ট সহ একটি ওপেনভিপিএন সার্ভার থাকতে পারে: প্রতিটি ক্লায়েন্ট কীভাবে সার্ভারে পৌঁছতে জানেন তবে ... সার্ভার, কীভাবে ক্লায়েন্টটি কোনও অজানা সাবনেটের গেটওয়ে হিসাবে কাজ করতে পারে তা সিদ্ধান্ত নিতে পারে?


আপনার প্রথম প্রশ্ন হিসাবে ( প্রয়োজনীয় নিয়মগুলি জেনেরিক / এক-অফ উপায়ে লেখা যেতে পারে? ), আমি দুঃখিত তবে আমি আপনার খুব সমস্যা হচ্ছি না। আপনি কি আরও বিশদ বিবরণ প্রদান করতে পারেন?



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

1
@jollyroger: tipical "রাস্তা-যোদ্ধারা" এ দৃশ্যকল্প (ক একক পিসি একটি VPN ক্লায়েন্ট হিসাবে একটি openpn-সার্ভার প্রতি অভিনয়) আপনি না কোনো "iroute" ডিরেক্টিভের প্রয়োজন! সুতরাং, আপনি যদি সর্বজনীন-ওয়াইফাইয়ের মাধ্যমে সংযুক্ত হন তবে আমি নিশ্চিত যে আপনার এটির দরকার নেই। আপনার কেবল টিপিক্যাল ল্যান-টু-ল্যান কনফিগারেশনে এটির প্রয়োজন হবে যেখানে ওপেনভিপিএন ক্লায়েন্টের পিছনে আপনার কাছে ওপেনভিপিএন সার্ভার দ্বারা অ্যাক্সেস করার জন্য একটি সম্পূর্ণ নেটওয়ার্ক রয়েছে। আমি নিশ্চিত যে আপনি যখন সংযুক্ত হন ... "অন্য জনসাধারণের ওয়াই-ফাই থেকে" এমনটি হয় না sure যদি আমার অনুমানগুলি ভুল হয় তবে দয়া করে আপনার টিপিকাল নেটওয়ার্ক কনফিগারেশন সম্পর্কে বিশদ দিন (স্পষ্টতই যখন পাবলিক-ওয়াইফাইয়ের মাধ্যমে সংযোগ করার সময়)
দামিয়ানো ভারজুলি

এটি বেশিরভাগ ওপেনভিপিএন-এর মাধ্যমে এসআইপি ব্যবহারের সাথে সম্পর্কিত। ধরুন আপনার ওয়ানলান্দে আপনার 192.168.0.111/24 এবং ওপেনভিপিএন-এর সাথে আপনার টিউন 0.10.10.5/30 রয়েছে। ধরে নিন ওপেনভিপিএন সার্ভারের অতিরিক্ত নেট 10.11.10.2/24 এস্টারিকের সাথে 10.11.10.1 এ রয়েছে এবং প্রয়োজনীয় সমস্ত রুটগুলি ক্লায়েন্টের দিকে ঠেলা যায় (পিং উভয় দিকেই সফল হয়)। সমস্যাটি হ'ল এসআইপি টিউন সোর্স আইপি ব্যবহার না করে আপনার wlan0 এর সোর্স আইপিযুক্ত প্যাকেটগুলি টিউন 0 ইন্টারফেসে রুট করার সিদ্ধান্ত নিতে পারে এবং এটি যখন আপনি সমস্যাটি পাবেন তখন - নক্ষত্র আপনাকে ভাববে না যে আপনি নাট-এড আছেন যদিও আপনি নন।
jollyroger

@ জলিরোজার: যদি আমি ঠিকই বলি, NAT বাক্সের পিছনে এসআইপি ক্লায়েন্ট থাকা পুরোপুরি সম্ভব, সুতরাং এটি আপনার ওপেনভিপিএন ক্লায়েন্টের মধ্যে NAT আউটবাউন্ড ভিপিএন ট্র্যাফিকের (টিউন 0 ইন্টারফেস ছেড়ে) হওয়া উচিত। আপনার জন্য কেন এটি কোনও বিকল্প নয় বলে কিছু সুনির্দিষ্ট কারণ রয়েছে?
দামিয়ানো ভেরজুলি

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

1

আমার মতো সমস্যা দেখা গেছে যা একই রকম মনে হয় তবে আমি নিশ্চিত নই যে এটি আপনার সমস্যার মতো কিনা। আমি ওপেনভিএনএন ক্লায়েন্ট থেকে ওপেনভিএনএন সার্ভারের স্থানীয় নেটওয়ার্কে (সার্ভারের কনফিগারেশনে রুটেড) কম্পিউটারে পিং দেওয়ার চেষ্টা করছিলাম, কোনও উত্তর পাইনি এবং আমি সার্ভারের ওপেনভিএনএন লগের "খারাপ উত্স ঠিকানা" বার্তাটি দেখতে পেলাম।

এটি সমাধান করার জন্য, আমাকে 2 টি জিনিস করতে হয়েছিল:

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

এটা আমার জন্য এটি স্থির।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.