การระบุที่อยู่ ip สำหรับการเชื่อมต่อขาออกบนโฮสต์หลายตัว


15

หนึ่งในเซิร์ฟเวอร์ของฉัน (Debian 5.0.6) มีที่อยู่ IP สาธารณะสองอันบนอินเทอร์เฟซเดียวกัน ใช้งานได้ดีเป็นเดือน แต่ทันใดนั้นก็ใช้ที่อยู่ IP "ผิด" สำหรับการเชื่อมต่อขาออก ปัญหานี้เป็นปัญหาเนื่องจากการค้นหาแบบย้อนกลับจะไม่ตรงกันและอีเมลจะได้รับคะแนนสแปม

eth0      Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:81.169.180.51  Bcast:81.169.180.51  Maske:255.255.255.255
          inet6-Adresse: fe80::21b:21ff:fe14:8e9c/64 Gültigkeitsbereich:Verbindung

eth0:0    Link encap:Ethernet  Hardware Adresse 00:1b:21:14:8e:9c  
          inet Adresse:85.214.157.120  Bcast:85.214.157.120  Maske:255.255.255.255


Kernel-IP-Routentabelle
Destination     Router          Genmask         Flags Metric Ref    Use Iface
81.169.180.1    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
0.0.0.0         81.169.180.1    0.0.0.0         UG    0      0        0 eth0

ปัจจุบันใช้ 85.214.157.120 สำหรับการเชื่อมต่อขาออก ฉันจะทำให้ใช้ 81.169.180.51 ได้อย่างไร

แก้ไข : netmask ของ 255.255.255.255 สอดคล้องกับทั้งเอกสารและการตอบสนอง DHCP ของ บริษัท โฮสติ้ง การเรียก /etc/init.d/networking การรีสตาร์ทหลายครั้งในที่สุดก็จะจบลงด้วยการที่อยู่ IP ที่ถูกต้องสำหรับการเชื่อมต่อ outbount แต่เห็นได้ชัดว่าไม่ใช่ทางออกที่มั่นคง / แก้ไข

แก้ไข 2 : เพื่อให้แน่ใจว่าเส้นทางโฮสต์ไม่เกี่ยวข้องกับปัญหาของฉันฉันตั้งค่าเครือข่ายทดสอบท้องถิ่น:

eth0      inet Adresse:192.168.0.2  Bcast:192.168.0.255  Maske:255.255.255.0
eth0:0    inet Adresse:192.168.0.3  Bcast:192.168.0.255  Maske:255.255.255.0

192.168.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.0.1     0.0.0.0         UG    0      0        0 eth0

หากใครมีความคิดวิธีการตรวจสอบให้แน่ใจว่าแหล่งที่มาที่อยู่ ip 192.168.0.2 ใช้ในการเชื่อมต่อ TCP ขาออกฉันจะขอบคุณ / แก้ไข 2

คำตอบ:


24

อัปเดตค่าเริ่มต้น:

ip route change default via 81.169.180.1 src 81.169.180.51

ตรวจสอบการกำหนดค่า:

ip route list

1
วิธีทำอย่างถาวรหลังจากรีบูต?
dezhi

3

คำตอบโดย bindbn นั้นดี แต่ฉันพบว่ามีอาการแทรกซ้อนบางอย่าง

1) คุณควรตรวจสอบ "รายการเส้นทาง IP" ตามที่ bindbn พูด กฎอื่น ๆ ในรายการอาจมีความสำคัญเหนือกว่าเส้นทางเริ่มต้น คุณอาจต้องลบกฎนั้นหรือสร้างกฎที่แตกต่างออกไปเล็กน้อย

2) การเปลี่ยนแปลงทั้งหมดที่ทำผ่านคำสั่ง ip จะทำงานจนกว่าจะรีบูตครั้งต่อไปเท่านั้น คำตอบนี้เพิ่มกฎการกำหนดเส้นทางนโยบายแหล่งที่มาอย่างถาวรอธิบายวิธีทำให้คงอยู่

โดยสรุปคุณสามารถเพิ่มคำสั่ง ip route ที่คุณต้องการเรียกใช้เป็นบรรทัด "up" หรือ "post-up" ไปยัง / etc / network / interfaces คุณสามารถเพิ่มบรรทัด "ลง" ที่เกี่ยวข้องเพื่อลบเส้นทาง


1

ลองเปลี่ยน

 allow-hotplug eth0

ถึง

 auto eth0

นั่นควรบังคับให้ส่วนต่อประสานทางกายภาพของคุณปรากฏขึ้นก่อน คุณอาจหรือไม่จำเป็นต้องเปลี่ยนรายการ allow-hotplug สำหรับ eth0: 0 เช่นกัน


1

จากความอยากรู้เหตุใดที่อยู่ IP ของคุณจึงมี netmask จำนวน 255.255.255.255 ไม่เป็นไปได้เพราะจะหมายถึงที่อยู่ทั้งหมดเป็นเครือข่าย ไม่มีที่ว่างสำหรับโฮสต์ ความจริงที่ว่าที่อยู่การออกอากาศของคุณเหมือนกับ IP โฮสต์ของคุณก็เป็นกังวลเช่นกัน แต่น่าจะเกิดจากปัญหา netmask ดูเหมือนว่า netmask ของคุณควรเป็น 255.255.255.0

สิ่งนี้ทำเพื่อให้คุณมีสองโฮสต์ในซับเน็ตเดียวกันหรือไม่ อาจเป็นการดีกว่าที่จะทำการเปลี่ยนแปลงเพื่อให้แต่ละอินเตอร์เฟสอยู่ในซับเน็ตที่แตกต่างกัน 255.255.255.128 จะวาง eth0 และเกตเวย์ของคุณ (จาก 81.169.180.1) บนซับเน็ตเดียวกันโดยมี eth0: 0 บนซับเน็ตแยกต่างหาก อย่างไรก็ตามนั่นหมายความว่า eth0 สามารถสื่อสารกับ 81.169.180.1-81.169.180.127 ได้เท่านั้น และ eth0: 0 เริ่มจาก 129-254 แต่ที่ถูกกล่าวว่าฉันไม่เห็นจริง ๆ ว่าทำไมการตั้งค่าปัจจุบันของคุณทำงานเลย

ตอนนี้สิ่งนี้จะทำให้เกิดปัญหาที่คุณเห็นด้านบนหรือไม่ ฉันไม่เห็นลิงก์โดยตรง แต่เป็นไปได้
แน่นอนว่ามันเป็นสิ่งที่ฉันปรับแต่ง หากวิธีนี้ไม่ได้ผลบางทีคุณสามารถอธิบายได้ว่าทำไมคุณต้องติดตั้งสิ่งต่าง ๆ ด้วยวิธีนี้


แก้ไข:มันทำงานได้ดีบนโฮสต์นี้หรือเป็นเครื่อง / OS อื่นหรือไม่ ความคิดอะไรที่อาจมีการเปลี่ยนแปลง? เหตุผลที่ฉันถามคือเพราะ Linux ไม่ชอบที่จะมีสองอินเตอร์เฟสบนซับเน็ตเดียวกัน มันเป็นแรงผลักดันให้ฉันพยายามอย่างมากที่จะทำงานบนเครือข่ายของฉันเอง ฟังดูเป็นไปได้มากที่คุณได้ทำงานกับ IP ที่ถูกต้องจนกระทั่งคุณเริ่มต้น / เริ่มบริการเครือข่ายใหม่ จากนั้นมันก็เกิดขึ้นโดยใช้อินเตอร์เฟสที่ไม่ถูกต้อง อ้างอิง: http://anders.com/cms/258

คุณสามารถลองifdownใช้ eth0: 0 แล้วเพิ่มเส้นทางจากนั้นifupกลับเข้าไปใหม่ ที่อาจรับประกันว่า IP ที่ถูกต้องถูกนำมาใช้

การเพิ่มความช่วยเหลือด้วยตนเองdev eth0 อาจปรากฏขึ้น แต่ดูเหมือนว่าเส้นทางนั้นทำอย่างถูกต้อง


เพิ่มเติมแก้ไข:iproute 2คุณอาจลองใช้เครื่องมือใหม่ล่าสุดการจัดการทรัพย์สินทางปัญญาในเด ( ลิงค์รอง ) ดูเหมือนว่าเป็นบางสิ่งบางอย่างตามแนวของ
Bringin up interface: ip link set eth0 up

ip addr add 192.168.0.2/24 dev ethe0
ip addr add 192.168.0.3/24 dev eth0

จากนั้นตั้งค่าตารางเส้นทางด้วย
ip route add 10.0.0.0/16 via 192.168.0.2


--Christopher Karel


netmask ของ 255.255.255.255 สอดคล้องกับทั้งเอกสารของ บริษัท โฮสติ้งและการตอบสนอง DHCP ตาม Google เป็นเรื่องปกติที่จะมี 255.255.255.255 ในเครือข่ายแบบจุดต่อจุด เท่าที่ฉันสามารถบอกได้มันจะค่อนข้างโง่ของ บริษัท โฮสติ้งที่จะใช้เครือข่ายแบบไม่มีจุดต่อจุดเนื่องจากความเสี่ยงด้านความปลอดภัยของการมีโฮสต์ที่ไม่น่าเชื่อถือในโดเมนออกอากาศชั้นเดียวกัน
Hendrik Brummermann

เช่นเดียวกับ Wolfgangsz ที่ได้กล่าวไว้ข้างต้น a / 32 ไม่ใช่มาตรฐานสำหรับการเชื่อมโยงแบบจุดต่อจุด ฉันรู้ว่าสามารถทำได้ / 31 แต่เห็นได้ชัดว่าฆ่าตัวระบุการออกอากาศและเครือข่าย 'เส้นทางโฮสต์' ที่คุณเห็นกล่าวถึงหมายถึงมันใช้ในตารางเส้นทาง เช่นมันเป็นเส้นทางไปยังโฮสต์ที่เฉพาะเจาะจงไม่ได้ไปยังเครือข่าย ดังนั้นการเกิดขึ้นใน RFC ที่คุณเชื่อมโยงกับ OSPF ซึ่งเป็นโปรโตคอลการกำหนดเส้นทาง ดังที่กล่าวไว้หากคุณแน่ใจว่า ISP ของคุณแนะนำให้คุณทำเช่นนั้นกับระบบปฏิบัติการของคุณคุณอาจต้องติดตามด้วย
Christopher Karel

ตกลงทำการแก้ไขเล็กน้อยซึ่งอาจช่วยแก้ไขปัญหาต้นฉบับของคุณได้
Christopher Karel

-1

การตั้งค่าปัจจุบันของคุณไม่ควรใช้งานได้จริง เนื่องจาก netmask สำหรับทั้งสองอินเตอร์เฟสคือ 255.255.255.255 จึงไม่มีที่ว่างสำหรับเกตเวย์ อย่างไรก็ตามเพื่อให้การรับส่งข้อมูลที่มีความหมายเซิร์ฟเวอร์ของคุณต้องการเกตเวย์ ISP ที่ให้ที่อยู่ IP สาธารณะทั้งสองควรให้การตั้งค่า netmask และเกตเวย์สำหรับที่อยู่ IP ทั้งสองด้วย

ตัวอย่าง (นี่คือเซิร์ฟเวอร์ส่วนตัวของฉันและที่อยู่ IP เป็นของจริง):

ตารางการกำหนดเส้นทาง IP เคอร์เนล
เกตเวย์ปลายทาง Genmask ตัวชี้วัดการอ้างอิง Ref ใช้ Iface
217.10.144.208 0.0.0.0 255.255.255.248 U 0 0 0 eth0
0.0.0.0 217.10.144.209 0.0.0.0 UG 0 0 0 eth0

เซิร์ฟเวอร์นั้นอยู่ใน 217.10.144.210 ซึ่งอยู่ในเครือข่ายย่อยเดียวกันกับเกตเวย์ (ต้องทำเช่นนั้นไม่เช่นนั้นจะไม่มีการรับส่งข้อมูล) สันนิษฐานว่า ISP นั้นให้บริการซับเน็ตเดียวกันสำหรับลูกค้ารายอื่นเช่นกัน

หากคุณอยู่บนเซิร์ฟเวอร์นั้นและคุณ ping ไปที่เกตเวย์ของคุณคุณควรได้รับข้อความ "ไม่มีเส้นทางไปยังโฮสต์"

พูดคุยกับ ISP และรับการตั้งค่าที่ถูกต้องจากนั้นอัปเดตการกำหนดค่าอินเทอร์เฟซของคุณรีสตาร์ทเครือข่ายและตรวจสอบอีกครั้ง


2
netmask ของ 255.255.255.255 สอดคล้องกับทั้งเอกสารของ บริษัท โฮสติ้งและการตอบสนอง DHCP ตาม Google เป็นเรื่องปกติที่จะมี 255.255.255.255 ในเครือข่ายแบบจุดต่อจุด เท่าที่ฉันสามารถบอกได้มันจะค่อนข้างโง่ของ บริษัท โฮสติ้งที่จะใช้เครือข่ายแบบไม่มีจุดต่อจุดเนื่องจากความเสี่ยงด้านความปลอดภัยของการมีโฮสต์ที่ไม่น่าเชื่อถือในโดเมนออกอากาศชั้นเดียวกัน
Hendrik Brummermann

หากคุณมีเครือข่ายแบบจุดต่อจุด netmask ของคุณจะเป็น 255.255.255.252 สิ่งนี้จะช่วยให้โฮสต์ทั้งสองที่ประกอบขึ้นเป็นสองจุดปลายที่อยู่เครือข่ายและที่อยู่การออกอากาศ นี่เป็นสถานการณ์ปกติสำหรับการเชื่อมต่อชนิดนั้น ในกรณีของคุณโฮสต์อื่นจะเป็นประตูสู่ส่วนที่เหลือของโลก ฉันไม่สนใจสิ่งที่คุณขุดใน google แต่นี่เป็นวิธีการทำงานของเครือข่าย TCP / IP และค่อนข้างชัดเจนว่ามันไม่ทำงานสำหรับคุณ ฉันออกจากข้อสรุปกับคุณ
wolfgangsz

ขอบคุณ แต่ส่วนนี้ใช้ได้ดีสำหรับฉัน โดยวิธีที่เรียกว่า "เส้นทางโฮสต์" ในมาตรฐานอินเทอร์เน็ตอย่างเป็นทางการ: rfc-editor.org/rfc/rfc2328.txt
Hendrik Brummermann

ปัญหาของฉันคือการทำซ้ำในเครือข่ายท้องถิ่นเช่นกัน: ifconfig eth0 192.168.0.2 mask 255.255.255.0 / ifconfig eth0: 1 192.168.0.3 รูปแบบหน้ากาก 255.255.255.0 / เส้นทางเพิ่มค่าเริ่มต้น gw 192.168.0.1
Hendrik Brummermann
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.