लिनक्स में एक ही सबनेट पर दो नेटवर्क इंटरफेस और दो आईपी पते


22

मैं हाल ही में एक स्थिति में भाग गया, जहां मुझे एक ही लिनक्स होस्ट को सौंपे गए एक ही सबनेट पर दो आईपी पते की आवश्यकता थी ताकि हम दो एसएसएल / टीएलएस साइटों को चला सकें। मेरा पहला दृष्टिकोण IP अलियासिंग का उपयोग करना था, उदाहरण के लिए eth0: 0, eth0: 1, आदि का उपयोग करना, लेकिन हमारे नेटवर्क व्यवस्थापक के पास सुरक्षा के लिए कुछ काफी सख्त सेटिंग्स हैं जो इस विचार को तोड़ देती हैं:

  1. वे डीएचसीपी स्नूपिंग का उपयोग करते हैं और आम तौर पर स्थिर आईपी पते की अनुमति नहीं देते हैं। स्टेटिक एड्रेसिंग को स्थिर डीएचसीपी प्रविष्टियों का उपयोग करके पूरा किया जाता है, इसलिए एक ही मैक एड्रेस को हमेशा एक ही आईपी असाइनमेंट मिलता है। यदि आप पूछते हैं तो यह सुविधा स्विचपोर्ट के अनुसार अक्षम की जा सकती है और आपके पास इसके लिए एक कारण है (शुक्र है कि नेटवर्क लोगों के साथ मेरे अच्छे संबंध हैं और ऐसा करना मुश्किल नहीं है)।
  2. स्विचपोर्ट पर डीएचसीपी स्नूपिंग अक्षम होने के साथ, उन्हें स्विच पर एक नियम रखना पड़ता है जिसमें कहा गया है कि मैक एड्रेस एक्स को आईपी एड्रेस वाई की अनुमति है। दुर्भाग्य से इसका साइड इफेक्ट यह भी है कि मैक एड्रेस एक्स को केवल अनुमति है आईपी ​​एड्रेस वाई। आईपी एलियासिंग के लिए आवश्यक है कि मैक एड्रेस एक्स को दो आईपी पते सौंपे गए थे, इसलिए यह काम नहीं किया।

स्विच कॉन्फ़िगरेशन पर इन मुद्दों के आसपास एक रास्ता हो सकता है, लेकिन नेटवर्क के साथ अच्छे संबंधों को संरक्षित करने के प्रयास में मैंने एक और तरीका खोजने की कोशिश की। दो नेटवर्क इंटरफेस होने के कारण अगले तार्किक कदम की तरह लग रहा था। शुक्र है कि यह लिनक्स सिस्टम एक आभासी मशीन है, इसलिए मैं आसानी से एक दूसरा नेटवर्क इंटरफ़ेस जोड़ने में सक्षम था (बिना रिबूट किए, मैं जोड़ सकता हूं - बहुत अच्छा)। कुछ कीस्ट्रोक्स बाद में मेरे पास दो नेटवर्क इंटरफेस थे और चल रहे थे और दोनों ने डीएचसीपी से आईपी पते खींच लिए थे।

लेकिन फिर समस्या यह आई: नेटवर्क व्यवस्थापक दोनों स्विच के लिए एआरपी प्रविष्टि को देख सकते हैं (स्विच पर), लेकिन केवल पहला नेटवर्क इंटरफ़ेस जो मैं लाया था वह पिंग्स या किसी भी प्रकार के टीसीपी या यूडीपी ट्रैफ़िक का जवाब देगा।

बहुत खोदने और पोक करने के बाद, यहाँ मैं क्या लेकर आया हूँ। यह काम करने लगता है, लेकिन यह कुछ के लिए बहुत काम भी लगता है जो ऐसा लगता है कि यह सरल होना चाहिए। किसी भी वैकल्पिक विचारों वहाँ?


चरण 1: सभी इंटरफेस पर ARP फ़िल्टरिंग सक्षम करें:

# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

लिनक्स कर्नेल डॉक्स में फ़ाइल नेटवर्किंग / ip-sysctl.txt से:

arp_filter - BOOLEAN
    1 - Allows you to have multiple network interfaces on the same
    subnet, and have the ARPs for each interface be answered
    based on whether or not the kernel would route a packet from
    the ARP'd IP out that interface (therefore you must use source
    based routing for this to work). In other words it allows control
    of which cards (usually 1) will respond to an arp request.

    0 - (default) The kernel can respond to arp requests with addresses
    from other interfaces. This may seem wrong but it usually makes
    sense, because it increases the chance of successful communication.
    IP addresses are owned by the complete host on Linux, not by
    particular interfaces. Only for more complex setups like load-
    balancing, does this behaviour cause problems.

    arp_filter for the interface will be enabled if at least one of
    conf/{all,interface}/arp_filter is set to TRUE,
    it will be disabled otherwise

चरण 2: स्रोत-आधारित रूटिंग को लागू करें

मैंने मूल रूप से सिर्फ http://lartc.org/howto/lartc.rpdb.multiple-links.html से निर्देशों का पालन किया , हालांकि उस पृष्ठ को एक अलग लक्ष्य को ध्यान में रखते हुए (दो आईएसपी के साथ व्यवहार करते हुए) लिखा गया था।

मान लें कि सबनेट 10.0.0.0/24 है, गेटवे 10.0.0.1 है, eth0 के लिए IP पता 10.0.0.100 है, और eth1 के लिए IP पता 10.0.0.101 है।

Eth0 और eth1 in / etc / iproute2 / rt_tables नाम की दो नई रूटिंग तालिकाओं को परिभाषित करें:

... top of file omitted ...
1    eth0
2    eth1

इन दो तालिकाओं के लिए मार्गों को परिभाषित करें:

# ip route add default via 10.0.0.1 table eth0
# ip route add default via 10.0.0.1 table eth1
# ip route add 10.0.0.0/24 dev eth0 src 10.0.0.100 table eth0
# ip route add 10.0.0.0/24 dev eth1 src 10.0.0.101 table eth1

नई रूटिंग तालिकाओं का उपयोग करने के नियमों को परिभाषित करें:

# ip rule add from 10.0.0.100 table eth0
# ip rule add from 10.0.0.101 table eth1

मुख्य रूटिंग टेबल का पहले से ही डीएचसीपी द्वारा ध्यान रखा गया था (और यह भी स्पष्ट नहीं है कि इस मामले में इसकी कड़ाई आवश्यक है), लेकिन यह मूल रूप से इसके लिए समान है:

# ip route add default via 10.0.0.1 dev eth0
# ip route add 130.127.48.0/23 dev eth0 src 10.0.0.100
# ip route add 130.127.48.0/23 dev eth1 src 10.0.0.101

और वोइला! सब कुछ ठीक काम करने लगता है। दोनों IP पते पर पिंग भेजना ठीक काम करता है। इस सिस्टम से अन्य सिस्टम में पिंग भेजना और पिंग को एक विशिष्ट इंटरफ़ेस का उपयोग करने के लिए मजबूर करना ठीक है ( ping -I eth0 10.0.0.1, ping -I eth1 10.0.0.1)। और सबसे महत्वपूर्ण बात, सभी टीसीपी और यूडीपी ट्रैफिक / से या तो आईपी पते की अपेक्षा के अनुरूप काम करते हैं।


तो फिर, मेरा सवाल यह है: क्या ऐसा करने का एक बेहतर तरीका है? यह एक साधारण सी समस्या के लिए बहुत काम की तरह लगता है।


अद्यतन: ऊपर का समाधान अधूरा होने के कारण समाप्त हो गया। यदि ट्रैफ़िक एक ही सबनेट पर रहता है, तो चीजें ठीक होती हैं, लेकिन 2 डी इंटरफ़ेस का उपयोग करने वाले अन्य सबनेट पर संचार ठीक से काम नहीं करेगा। एक बड़ा छेद खोदने के बजाय मैंने नेटवर्क व्यवस्थापक से बात करना समाप्त कर दिया और उन्हें एक इंटरफेस के लिए कई आईपी पते की अनुमति दी और आईपी एलियासिंग (उदाहरण के लिए eth0 और eth0: 0) का उपयोग किया।


याद रखने के लिए महत्वपूर्ण अंतर यह है कि आईपी इंटरफ़ेस से संबंधित नहीं है, यह मशीन से संबंधित है। इसलिए इस सेटअप में या तो आईपी के लिए या तो इंटरफ़ेस भेजना सही है, इसलिए ऐसा करने के लिए कुछ चालबाजी की आवश्यकता होती है।
मिकीबी

मेरा मानना ​​है कि इस मामले में स्रोत राउटिंग आवश्यक नहीं है क्योंकि arp फ़िल्टरिंग केवल तभी लागू होनी चाहिए जब स्विच किसी इंटरफ़ेस पर भेज रहा हो / उसे इसके पोर्ट्स के बीच खोजना हो। मैं गलत हो सकता है, लेकिन जब मशीन स्विच की ओर डेटा भेजती है, तो स्रोत क्षेत्र में आईपी (आईपी हेडर) की जांच नहीं की जाती है, बस पैकेट भेजने वाले एआरपी।
एंड्रियासएम

मिकीबी सही है, स्रोत मार्ग एकमात्र तरीका है। मशीन किसी भी आउटबाउंड इंटरफ़ेस को चुन सकती है जिसे वह ट्रैफ़िक भेजना चाहता है, जब तक कि वह उसी सबनेट पर न हो। अगर आईपी इंटरफ़ेस वास्तव में उस इंटरफ़ेस पर स्थित है या नहीं, तो कोई बात नहीं।
पैट्रिक

2
AndreasM: आने वाले पैकेट समस्या नहीं हैं, यह आउटगोइंग पैकेट हैं जो समस्या हैं। स्रोत रूटिंग के बिना, सभी आउटगोइंग पैकेट डिफ़ॉल्ट मार्ग का उपयोग करेंगे, जो एक इंटरफ़ेस या दूसरे से जुड़ा हुआ है। भले ही आउटगोइंग पैकेट में सही स्रोत आईपी पता होगा, स्विच पर फिल्टर उन्हें बाहर जाने की अनुमति नहीं देगा क्योंकि आईपी पता उस इंटरफ़ेस के मैक पते से संबंधित नहीं है। स्विच करने के लिए ऐसा लगता है कि एक ग्राहक दूसरे ग्राहक के आईपी को खराब करने की कोशिश कर रहा है। (ये स्मार्ट लेयर 3 स्विच हैं)।
स्कॉट डकवर्थ

आईपी ​​उपनाम अप्रचलित और एक हैक हैं, वास्तविकता को प्रतिबिंबित नहीं करते हैं, यह उल्लेख नहीं करने के लिए कि प्राथमिक को नीचे ले जाने से सभी उपनाम कम हो जाएंगे। उपयोग ipसे iproute2एक ही इंटरफ़ेस करने के लिए एक से अधिक पते जोड़ने के लिए।
पिलोना

जवाबों:


8

हां, बेहतर तरीका यह है कि एक उचित व्यावसायिक मामला बनाया जाए, और उन्हें स्विच पर नियमों को शिथिल किया जाए ताकि आपके पास एक एनआईसी पर कई आईपी हो सकें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.