ทำไม ICMP Redirect Host จึงเกิดขึ้น


25

ฉันกำลังตั้งค่ากล่อง Debian เป็นเราเตอร์สำหรับเครือข่ายย่อย 4 แห่ง สำหรับสิ่งที่ฉันได้กำหนดอินเทอร์เฟซเสมือน 4 บน NIC ที่เชื่อมต่อ LAN ( eth1)

eth1      Link encap:Ethernet  HWaddr 94:0c:6d:82:0d:98  
          inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::960c:6dff:fe82:d98/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6026521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35331299 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:673201397 (642.0 MiB)  TX bytes:177276932 (169.0 MiB)
          Interrupt:19 Base address:0x6000 

eth1:0    Link encap:Ethernet  HWaddr 94:0c:6d:82:0d:98  
          inet addr:10.1.2.1  Bcast:10.1.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:19 Base address:0x6000 

eth1:1    Link encap:Ethernet  HWaddr 94:0c:6d:82:0d:98  
          inet addr:10.1.3.1  Bcast:10.1.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:19 Base address:0x6000 

eth1:2    Link encap:Ethernet  HWaddr 94:0c:6d:82:0d:98  
          inet addr:10.1.4.1  Bcast:10.1.4.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:19 Base address:0x6000 

eth2      Link encap:Ethernet  HWaddr 6c:f0:49:a4:47:38  
          inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::6ef0:49ff:fea4:4738/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:199809345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:158362936 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:3656983762 (3.4 GiB)  TX bytes:1715848473 (1.5 GiB)
          Interrupt:27 

eth3      Link encap:Ethernet  HWaddr 94:0c:6d:82:c8:72  
          inet addr:192.168.2.5  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::960c:6dff:fe82:c872/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:110814 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73386 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:16044901 (15.3 MiB)  TX bytes:42125647 (40.1 MiB)
          Interrupt:20 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:22351 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22351 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2625143 (2.5 MiB)  TX bytes:2625143 (2.5 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:41358924 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23116350 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:3065505744 (2.8 GiB)  TX bytes:1324358330 (1.2 GiB)

ฉันมีคอมพิวเตอร์สองเครื่องเชื่อมต่อกับเครือข่ายนี้ หนึ่งมี IP 10.1.1.12 (subnet mask 255.255.255.0) และอีกอันหนึ่ง 10.1.2.20 (subnet mask 255.255.255.0) ฉันต้องการเข้าถึง 10.1.1.12 จาก 10.1.2.20

เนื่องจากการส่งต่อแพ็คเก็ตเปิดใช้งานในเราเตอร์และนโยบายของ FORWARD chain นั้นเป็นที่ยอมรับ (และไม่มีกฎอื่น ๆ ) ฉันเข้าใจว่าไม่ควรมีปัญหาในการ ping จาก 10.1.2.20 ถึง 10.1.1.12 ที่จะผ่านเราเตอร์

อย่างไรก็ตามนี่คือสิ่งที่ฉันได้รับ:

$ ping -c15 10.1.1.12
PING 10.1.1.12 (10.1.1.12): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 81d4   0 0000  3f  01 e2b3 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 1
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 899b   0 0000  3f  01 daec 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 2
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 78fe   0 0000  3f  01 eb89 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 3
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 14b8   0 0000  3f  01 4fd0 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 4
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 8ef7   0 0000  3f  01 d590 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 5
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 ec9d   0 0000  3f  01 77ea 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 6
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 70e6   0 0000  3f  01 f3a1 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 7
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 b0d2   0 0000  3f  01 b3b5 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 8
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f8b4   0 0000  3f  01 6bd3 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 1c95   0 0000  3f  01 47f3 10.1.2.20  10.1.1.12 

Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
92 bytes from router2.mydomain.com (10.1.2.1): Redirect Host(New addr: 10.1.1.12)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 62bc   0 0000  3f  01 01cc 10.1.2.20  10.1.1.12 

ทำไมสิ่งนี้ถึงเกิดขึ้น

จากสิ่งที่ฉันได้อ่านการRedirect Hostตอบสนองมีบางสิ่งที่เกี่ยวข้องกับความจริงที่ว่าโฮสต์ทั้งสองอยู่ในเครือข่ายเดียวกันและมีเส้นทางที่สั้นกว่า (หรือฉันเข้าใจ) พวกเขาอยู่ในเครือข่ายทางกายภาพเดียวกัน แต่ทำไมจะมีเส้นทางที่ดีกว่าหากพวกเขาไม่ได้อยู่ในเครือข่ายย่อยเดียวกัน (พวกเขาไม่สามารถมองเห็นกัน)

ฉันพลาดอะไรไป

ข้อมูลพิเศษบางอย่างที่คุณอาจต้องการดู:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
127.0.0.1       0.0.0.0         255.255.255.255 UH    0      0        0 lo
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth3
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth2
10.1.4.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.1.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.1.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.1.3.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth2
0.0.0.0         192.168.2.1     0.0.0.0         UG    100    0        0 eth3

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   

# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  -- !10.0.0.0/8           10.0.0.0/8          
MASQUERADE  all  --  10.0.0.0/8          !10.0.0.0/8          

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

คำตอบ:


22

หน้าแรกหน้าแดงดูเหมือนว่า Debian กำลังยืดขอบเขตสำหรับการส่งการเปลี่ยนเส้นทาง ICMP ข้อความRFC 792 (Internet Protocol)

  The gateway sends a redirect message to a host in the following
  situation.  A gateway, G1, receives an internet datagram from a
  host on a network to which the gateway is attached.  The gateway,
  G1, checks its routing table and obtains the address of the next
  gateway, G2, on the route to the datagram's internet destination
  network, X.  If G2 and the host identified by the internet source
  address of the datagram are on the same network, a redirect
  message is sent to the host.  The redirect message advises the
  host to send its traffic for network X directly to gateway G2 as
  this is a shorter path to the destination.  The gateway forwards
  the original datagram's data to its internet destination.

ในกรณีนี้ G1 คือ10.1.2.1( eth1:0ด้านบน), X คือ10.1.1.0/24และ G2 คือ10.1.1.12และแหล่งที่มาคือ10.1.2.20(เช่นG2 and the host identified by the internet source address of the datagram are **NOT** on the same network) บางทีนี่อาจถูกตีความในอดีตแตกต่างกันในกรณีของนามแฝงของอินเทอร์เฟซ (หรือที่อยู่รอง) บนอินเทอร์เฟซเดียวกัน แต่พูดอย่างเคร่งครัดฉันไม่แน่ใจว่าเราควรเห็น Debian ส่งการเปลี่ยนเส้นทางนั้น

ทั้งนี้ขึ้นอยู่กับความต้องการของคุณคุณอาจจะสามารถแก้ปัญหานี้โดยการทำเครือข่ายย่อยสำหรับeth1สิ่งที่ต้องการ10.1.0.0/22(ที่อยู่โฮสต์จาก10.1.0.1- 10.1.3.254) แทนการใช้นามแฝงอินเตอร์เฟซสำหรับแต่ละ/24บล็อก ( eth1, eth1:0, eth1:1, eth1:2); ถ้าคุณทำอย่างนี้คุณจะต้องเปลี่ยน netmask ของทุกครอบครัวที่แนบมาและคุณจะไม่สามารถที่จะใช้ 10.1.4.x /21จนกว่าคุณจะขยายไป

แก้ไข

เรากำลังเสี่ยงนอกขอบเขตของคำถามเดิม แต่ฉันจะช่วยแก้ไขปัญหาการออกแบบ / ความปลอดภัยที่ระบุไว้ในความคิดเห็นของคุณ

หากคุณต้องการแยกผู้ใช้ในสำนักงานของคุณออกจากกันลองย้อนกลับไปหนึ่งวินาทีแล้วดูที่ปัญหาด้านความปลอดภัยกับสิ่งที่คุณมีตอนนี้:

ขณะนี้คุณมีเครือข่ายย่อยสี่โดเมนในหนึ่งโดเมนการออกอากาศอีเธอร์เน็ต ผู้ใช้ทุกคนในโดเมนออกอากาศหนึ่งไม่ตอบสนองความต้องการความปลอดภัยที่คุณก้องอยู่ในความคิดเห็น (เครื่องทั้งหมดจะเห็นการถ่ายทอดจากเครื่องอื่น ๆ และเป็นธรรมชาติสามารถส่งการเข้าชมแต่ละอื่น ๆ ที่ Layer2 โดยไม่คำนึงถึงความเป็นอยู่เกตเวย์เริ่มต้นของพวกเขาeth1, eth1:0, eth1:1หรือeth1:2) ไม่มีสิ่งใดที่ไฟร์วอลล์ Debian ของคุณสามารถทำได้เพื่อเปลี่ยนแปลงสิ่งนี้ (หรือฉันควรจะบอกว่าไม่มีสิ่งใดที่ไฟร์วอลล์ Debian ของคุณควรทำเพื่อเปลี่ยน :-) นี้

  • คุณต้องกำหนดผู้ใช้เป็น Vlans ตามนโยบายความปลอดภัยที่ระบุไว้ในความคิดเห็น Vlan ที่ตั้งค่าไว้อย่างถูกต้องจะช่วยแก้ไขปัญหาต่าง ๆ ที่กล่าวถึงข้างต้นได้ หากสวิตช์อีเธอร์เน็ตของคุณไม่รองรับ Vlans คุณควรรับสวิตช์ดังกล่าว
  • สำหรับการเข้าถึงหลายโดเมนความปลอดภัย10.1.1.12คุณมีตัวเลือกสองทาง:
    • ตัวเลือกที่ 1 : กำหนดความต้องการสำหรับผู้ใช้ทั้งหมดในการเข้าถึงบริการ10.1.1.12คุณสามารถใส่ผู้ใช้ทั้งหมดในเครือข่ายย่อย IP เดียวและใช้นโยบายความปลอดภัยกับPrivate Vlans (RFC 5517)สมมติว่าสวิตช์อีเธอร์เน็ตของคุณรองรับสิ่งนี้ ตัวเลือกนี้จะไม่ต้องใช้iptablesกฎในการ จำกัด ทราฟฟิกภายในสำนักงานจากการข้ามขอบเขตความปลอดภัย (ซึ่งทำได้ด้วย Vlans ส่วนตัว)
    • ตัวเลือกที่ 2 : คุณสามารถใส่ผู้ใช้ลงในซับเน็ตที่แตกต่างกัน (สอดคล้องกับ Vlans) และใช้iptablesกฎเพื่อปรับใช้นโยบายความปลอดภัยของคุณ
  • หลังจากที่คุณได้รักษาความปลอดภัยเครือข่ายของคุณในระดับ Vlan แล้วให้ตั้งค่านโยบายการกำหนดเส้นทางตามแหล่งข้อมูลเพื่อส่งผู้ใช้ที่แตกต่างกันออกไป

ถ้าคุณมีเราเตอร์ที่รองรับVRFบางอย่างจะง่ายขึ้นกว่าเดิม IIRC คุณมีเครื่อง Cisco IOS ในสถานที่ ขึ้นอยู่กับรุ่นและอิมเมจซอฟต์แวร์ที่คุณมีอยู่แล้วซึ่ง Cisco สามารถทำงานที่ยอดเยี่ยมในการแยกผู้ใช้ของคุณออกจากกันและใช้นโยบายการกำหนดเส้นทางตามแหล่งที่มา


โดยทั่วไปสิ่งที่ฉันต้องการคือมีเครือข่ายย่อย 4 แห่งสำหรับพื้นที่ต่าง ๆ ของสำนักงาน ซับเน็ตบางส่วนจะออกไปทางอินเทอร์เน็ตโดยใช้ ISP หนึ่งเครื่องและอื่น ๆ จะใช้อินเทอร์เน็ตอื่น เครื่องจากเครือข่ายย่อยต่าง ๆ ไม่ควรมองเห็นหรือเชื่อมต่อซึ่งกันและกัน ยกเว้นสำหรับโฮสต์ 10.1.1.12 ซึ่งเสนอบริการบางอย่างที่ควรมีให้สำหรับทุกคน ขณะนี้ฉันยังไม่ได้ตั้งค่ากฎการส่งต่อที่เหมาะสมสำหรับสิ่งนี้ อย่างไรก็ตามเนื่องจากการส่งต่อทั้งหมดได้รับการยอมรับฉันคิดว่าฉันควรจะสามารถ ping จาก 10.1.2.20 ถึง 10.1.1.12
El Barto

อืม ... โอเคขอบคุณไมค์ ฉันจะตรวจสอบ VLANs อย่างลึกซึ้งยิ่งขึ้น ฉันคิดเกี่ยวกับมันก่อนที่จะเริ่มทั้งหมดนี้และคิดว่าฉันไม่ต้องการมัน สวิตช์ที่เรารองรับ VLAN แม้ว่ามันจะเป็นสวิตช์ที่ไม่มีการจัดการดังนั้นหากฉันไม่ผิดฉันเดาว่าฉันจะต้องติดแท็กบนเราเตอร์ Debian ใช่ไหม การแยกซับเน็ตไม่ได้เป็นปัญหาสำคัญในออฟฟิศนี้ แต่เป็นสิ่งที่ฉันคิดว่ามันจะดีถ้ามีมันไม่ต้องใช้งานมากเกินไป ฉันจะตรวจสอบและดูว่าฉันสามารถทำอะไรได้บ้าง :)
El Barto

@ElBarto หากสวิตช์ของคุณไม่รองรับการติดแท็ก Vlan (และนั่นไม่น่าเป็นไปได้ถ้าพวกเขาไม่ได้รับการจัดการ) ดังนั้นการติดแท็กบน Debian จะไม่ช่วย หากการแยกซับเน็ตภายในสำนักงานไม่ใช่ปัญหาสำคัญให้วางทุกคนไว้ในเครือข่ายย่อยสองเครือข่ายและทำให้ทุกอย่างเป็นเรื่องง่าย (เครือข่ายย่อยสองแห่งช่วยให้คุณสามารถกำหนดเส้นทางนโยบายใน Debian ได้) ฉันจะบอกว่ารูปแบบปัจจุบันที่มีนามแฝงของอินเทอร์เฟซ Debian สี่รายการไม่มีการแยกซับเน็ตจริงและเพิ่มความซับซ้อนมากขึ้น
Mike Pennington

ถูกต้องจากสิ่งที่ฉันเข้าใจจากคู่มือผู้ใช้สวิตช์สนับสนุน "รักษาแท็ก" แต่ไม่ "ทำการติดแท็กจริง" ขอบคุณสำหรับการชี้แจงเกี่ยวกับเดเบียน ประเด็นก็คือแม้ว่าฉันจะเก็บเครือข่ายย่อยสองเครือข่ายไว้ฉันก็ยังต้องใช้เครื่องจากเครือข่ายย่อย 10.1.2.0/24 เพื่อเข้าถึง 10.1.1.12
El Barto

เครื่องในซับเน็ตที่แตกต่างกันควรยังสามารถเข้าถึง10.1.1.12ได้ หากคุณบล็อก linux ไม่ให้ส่ง ICMP ที่ไม่สามารถเข้าถึงได้iptablesคุณจะยังคงเบิร์น CPU จากการส่งข้อความ ICMP แต่อย่างน้อยพวกมันจะไม่ได้รับการติดตั้งในตารางโฮสต์ของคุณ ที่กล่าวว่าหากคุณเพิ่มอีเธอร์เน็ตอินเทอร์เฟซอื่นบน Debian (เช่นอุทิศหนึ่งอินเทอร์เฟซสำหรับผู้ใช้ 'คลาส') Debian ไม่ควรส่ง ICMP ที่ไม่สามารถเข้าถึงได้อีกต่อไป นั่นแปลว่าคุณมีสวิตช์อีเธอร์เน็ตสองสวิตช์: สวิตช์หนึ่งตัวสำหรับผู้ใช้แต่ละคน 'คลาส' ช่างเทคนิคการเดินสายของคุณจะไม่ชอบ แต่ก็ทำงานเสร็จแล้ว
Mike Pennington

3

ไม่ชัดเจนว่าคุณกำลังพยายามทำอะไร แต่ฉันสามารถพูดได้ดังต่อไปนี้

เครือข่ายย่อยเหล่านี้เชื่อมต่อกับส่วนต่อประสานทางกายภาพเดียวกัน เราเตอร์ Linux จะส่งคืนข้อความเปลี่ยนเส้นทาง ICMP เมื่อแพ็กเก็ตที่ได้รับควรถูกส่งต่อผ่านส่วนต่อประสานทางกายภาพเดียวกัน


ฉันต้องจัดการเครือข่ายย่อยทั้ง 4 นี้ซึ่งเชื่อมต่อทั้งหมดผ่าน NIC เดียวกัน แนวคิดคือโฮสต์จากเครือข่ายย่อยต่าง ๆ ไม่ควรเชื่อมต่อเข้าด้วยกันยกเว้นสำหรับโฮสต์ 10.1.1.12 ที่ควรมีให้สำหรับทุกคน ฉันยังไม่ได้กำหนดกฎล่วงหน้าสำหรับสิ่งนี้ดังนั้นฉันคิดว่าโฮสต์ใด ๆ จากเครือข่ายย่อยเหล่านั้นควรจะสามารถเข้าถึง 10.1.1.12 ได้ มีวิธีใดที่จะหลีกเลี่ยงการเปลี่ยนเส้นทาง ICMP หรือไม่
El Barto

1
@ElBarto วิธีหนึ่งคือการเพิ่มiptablesกฎที่ลดลงเปลี่ยนเส้นทางออกไปeth1
ไมค์เพนนิงตัน

1

ฉันเห็นด้วยกับความคิดเห็นของ Khaled และจะเพิ่มในตอนท้ายของวลีของเขา:

"เครือข่ายย่อยเหล่านี้จะเชื่อมต่อกับอินเตอร์เฟซกายภาพเดียวกัน. เราเตอร์ลินุกซ์จะกลับข้อความเปลี่ยนเส้นทาง ICMP เมื่อแพ็คเก็ตที่ได้รับควรจะส่งต่อเหนือติดต่อทางเดียวกัน" กับเครือข่ายย่อยปลายทางเดียวกันแล้วเปลี่ยนเส้นทางการร้องขอไปยังฮอปต่อไป ที่เกิดขึ้นกับฉันในวันนี้โดยใช้เราเตอร์ Mikrotik linux และอุปกรณ์ F5 bigip LTM

root@(primaryadc)(cfg-sync In Sync)(Standby)(/Common)(tmos)# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.153.20: icmp_seq=1 Redirect Host(New nexthop: 192.168.153.2)
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=82.8 ms
From 192.168.153.20: icmp_seq=2 Redirect Host(New nexthop: 192.168.153.2)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=123 ms
**routing table**
0.0.0.0  192.168.153.20  0.0.0.0         UG        0 0          0 external
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.