บทความ อีเทอร์เน็ต มีตาราง EtherType อยู่ตารางหนึ่ง และ แถวที่สองในนั้นเขียนว่า
0x0806 ARPตอนนั้นยังไม่ได้อธิบาย หน้านี้คือคำอธิบาย
และสิ่งที่มันแก้คือช่องว่างที่ไม่มีใครเห็นจนกว่าจะมองหา IP รู้ว่าจะส่งไปที่เลขที่อยู่ไหน อีเทอร์เน็ตรู้ว่าจะส่งถึงการ์ดใบไหนก็ได้บนสาย แต่ไม่มีอะไรบอกว่าเลขที่อยู่นั้นอยู่ที่การ์ดใบไหน
ช่องว่างระหว่างสองชั้น
สองชั้นนี้ถูกออกแบบแยกกันโดยตั้งใจ IP ไม่รู้จักอีเทอร์เน็ต และอีเทอร์เน็ตไม่รู้จัก IP ซึ่งเป็นเหตุผลที่ IP วิ่งบนอะไรก็ได้
ราคาของการแยกกันคือต้องมีอะไรสักอย่างมาแปลระหว่างสองโลก และสิ่งนั้นคือ ARP
RFC 826 เดือนพฤศจิกายน 1982 เขียนโดย David C. Plummer ตั้งชื่อตัวเองไว้ตรงตาม หน้าที่นั้นเลยว่า "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware"
เอกสารทั้งฉบับยาวไม่ถึงสิบหน้า และแทบไม่เคยถูกแก้อีกเลยตั้งแต่นั้น
ถ้ายังไม่เคยดู เริ่มตรงนี้
ตารางแปลที่ว่านั้นอยู่ในเครื่องทุกเครื่อง และเปิดดูได้
$ arp -an
? (192.0.2.1) at 00:00:5e:00:53:01 on en0 ifscope [ethernet]
? (192.0.2.7) at 00:00:5e:00:53:07 on en0 ifscope [ethernet]
? (192.0.2.31) at 00:00:5e:00:53:11 on en0 permanent [ethernet]ทุกแถวคือคำตอบที่เคยถามไปแล้วครั้งหนึ่ง และเก็บไว้เพื่อไม่ต้องถามซ้ำ
คำว่า permanent แปลว่ารายการนั้นไม่หมดอายุ ซึ่งบนเครื่องส่วนใหญ่คือที่อยู่ของ ตัวเองกับที่อยู่พิเศษไม่กี่อัน ส่วนแถวที่ไม่มีคำนั้นจะหายไปเองเมื่อไม่ได้ใช้
คำถามที่ถามจริง ๆ ไม่ใช่คำถามที่คนคิด
นี่คือจุดที่เข้าใจผิดกันมากที่สุดในทั้งเรื่อง
คนมักคิดว่าเครื่องถามหา MAC ของปลายทางที่ต้องการติดต่อ ซึ่งจริงเฉพาะตอนที่ ปลายทางอยู่บนสายเส้นเดียวกัน
ก่อนจะถาม เครื่องต้องตัดสินใจข้อหนึ่งก่อน โดยเอาเลขที่อยู่ปลายทางมาผ่านมาสก์ของ ตัวเอง ซึ่งเป็นการคำนวณเดียวกับที่บทความ ซับเน็ต อธิบายไว้
ถ้าอยู่ในเครือข่ายเดียวกัน ถามหา MAC ของปลายทางนั้นตรง ๆ
ถ้าอยู่คนละเครือข่าย ไม่ถามหาปลายทางเลย แต่ถามหา MAC ของเกตเวย์แทน
เหตุผลตรงไปตรงมา เครื่องที่อยู่คนละเครือข่ายไม่ได้อยู่บนสายเส้นนี้ ต่อให้ถามไป ก็ไม่มีใครได้ยิน MAC ปลายทางในเฟรมจึงเป็นของเพื่อนบ้านเสมอ ในขณะที่เลขที่อยู่ ปลายทางในแพ็กเก็ตไม่เคยเปลี่ยน
ข้อนี้อธิบายอาการที่เจอบ่อย ตั้งมาสก์ผิดหนึ่งบิต เครื่องจะไปถามหาคนผิดทันที และไม่มีใครตอบ ทั้งที่ทุกอย่างอื่นถูกหมด
รูปร่างของแพ็กเก็ต
off field octets meaning
0 hrd 2 hardware type, 1 = ethernet
2 pro 2 protocol type, 0x0800 = IPv4
4 hln 1 hardware address length, 6
5 pln 1 protocol address length, 4
6 op 2 1 = request, 2 = reply
8 sha 6 sender hardware address
14 spa 4 sender protocol address
18 tha 6 target hardware address
24 tpa 4 target protocol address
---
28สังเกตว่าไม่มีที่ไหนเลยที่บอกว่าโพรโทคอลนี้ผูกกับอีเทอร์เน็ตหรือ IPv4 ฟิลด์ hrd กับ pro บอกว่ากำลังแปลระหว่างอะไรกับอะไร และ hln กับ pln บอกความยาว ของที่อยู่ทั้งสองแบบ
RFC 826 พูดถึงเรื่องนี้ไว้เองว่า "Generalizations have been made which allow the protocol to be used for non-10Mbit Ethernet hardware" ซึ่งเป็นการออกแบบที่ เผื่ออนาคตไว้ตั้งแต่ปี 1982 และในทางปฏิบัติแทบไม่มีใครใช้ค่าอื่นเลย
ARP ไม่ได้วิ่งบน IP
จุดนี้สำคัญกว่าที่ดู ARP มี EtherType ของตัวเองคือ 0x0806 ซึ่งแปลว่ามันไม่ได้ อยู่ข้างบน IP มันอยู่ข้าง ๆ IP
ผลตามมาสองข้อ
ข้อแรก มันข้ามเราเตอร์ไม่ได้ เพราะไม่ได้เป็นแพ็กเก็ต IP จึงไม่มีอะไรให้ เราเตอร์เราต์ ซึ่งจริง ๆ แล้วถูกต้องแล้ว เพราะคำถามว่าใครอยู่บนสายเส้นนี้ ไม่มีความหมายข้ามสาย
ข้อสอง มันไม่ได้อะไรจาก IP เลยสักอย่าง ไม่มี TTL ไม่มี checksum ไม่มีทาง เข้ารหัส และไม่มีทางยืนยันตัวตน ทุกอย่างที่ต้องการต้องสร้างเองใหม่ทั้งหมด และมัน ไม่ได้สร้างอะไรเลย
ข้อที่สองคือรากของหัวข้อเรื่องความปลอดภัยข้างล่าง
28 ไบต์ที่ต้องเติมช่องว่างอีก 18
เอาขนาดมาบวกกันแล้วเทียบกับเฟรมต่ำสุดที่บทความอีเทอร์เน็ตอธิบายที่มาไว้
ethernet header 14
ARP 28
--
42 on the wire
minimum frame 60 before FCS
padding needed 18ทุกแพ็กเก็ต ARP ที่วิ่งบนสายจึงเป็นช่องว่างเปล่า ๆ สิบแปดไบต์ คิดเป็นเกือบ หนึ่งในสามของเฟรม
ไบต์เปล่านั้นไม่ได้มาจากความไม่ประณีตของ ARP แต่มาจากเหตุผลเรื่อง slot time ของ CSMA/CD ที่บทความอีเทอร์เน็ตอธิบายไว้ ซึ่งเป็นข้อจำกัดจากยุคที่ยังใช้สายร่วมกัน และยังอยู่จนถึงวันนี้
ถามและตอบ
คำถามเป็น broadcast ปลายทางของเฟรมคือ ff:ff:ff:ff:ff:ff ทุกเครื่องบนสาย ต้องรับขึ้นไปอ่าน แล้วเกือบทุกเครื่องพบว่าไม่เกี่ยวกับตัวเอง
ในแพ็กเก็ตนั้น ช่อง tha เป็นศูนย์ทั้งหกไบต์ เพราะนั่นคือช่องที่กำลังถามหา
คำตอบเป็น unicast ส่งตรงกลับไปหาผู้ถามเท่านั้น ไม่ต้อง broadcast อีก
เหตุผลอยู่ในโครงของแพ็กเก็ต คำถามพก sha กับ spa ของผู้ถามมาด้วยเสมอ ผู้ตอบจึงรู้ทั้ง MAC และเลขที่อยู่ของผู้ถามตั้งแต่ก่อนจะตอบ
ผลข้างเคียงที่สวยงามคือหลังจบหนึ่งรอบ ทั้งสองฝั่งมีข้อมูลของกันและกันแล้ว ทั้งที่มีแค่ฝ่ายเดียวที่ถาม
แคช และกฎจากปี 1982 ที่ยังอยู่
คำตอบถูกเก็บไว้ในตาราง และนั่นคือสิ่งที่ arp -an แสดง
แต่กฎที่ว่าจะเก็บเมื่อไรนั้นกว้างกว่าที่คนคิดมาก RFC 826 เขียนอัลกอริทึมไว้ว่า
If the pair <protocol type, sender protocol address> is already in my translation table, update the sender hardware address field of the entry with the new information in the packet
และขั้นตอนนี้อยู่ก่อนการตรวจว่าแพ็กเก็ตส่งมาถึงเราหรือเปล่า
แปลว่าถ้าเครื่องเราเคยรู้จักเลขที่อยู่หนึ่งอยู่แล้ว แล้วมีแพ็กเก็ต ARP ใด ๆ ที่ อ้างว่ามาจากเลขนั้นวิ่งผ่านมา ไม่ว่าจะส่งมาถึงเราหรือไม่ ตารางของเราถูกเขียนทับ ทันที
เจตนาเดิมดีมาก มันทำให้ตารางสดอยู่เสมอโดยไม่ต้องถามซ้ำ เครื่องที่เปลี่ยนการ์ด เครือข่ายจะถูกจดจำใหม่เองภายในไม่กี่วินาที
เจตนานั้นตั้งอยู่บนสมมติฐานว่าทุกคนบนสายพูดความจริง ซึ่งในปี 1982 บนสาย ที่มีเครื่องไม่กี่เครื่องในตึกเดียวกัน เป็นสมมติฐานที่สมเหตุสมผล
ทำไมรายการถึงต้องหมดอายุ
ถ้าเก็บไว้ตลอดไป ตารางจะค้างอยู่กับความจริงที่หมดอายุแล้ว เครื่องที่ถูกถอดไป เครื่องที่เปลี่ยนการ์ด หรือเลขที่ถูกยกไปให้เครื่องอื่นจาก DHCP ล้วนทำให้รายการเดิมผิด
การหมดอายุจึงเป็นกลไกซ่อมตัวเอง ที่ยอมจ่ายด้วยการถามซ้ำเป็นระยะ
probe กับ announcement
ARP ยังถูกใช้ทำสองอย่างที่ไม่ใช่การถามหาใครเลย และ RFC 5227 ปี 2008 นิยามทั้งคู่ ไว้ชัดเจน
probe spa = 0.0.0.0 tpa = 192.0.2.10
announcement spa = 192.0.2.10 tpa = 192.0.2.10probe คือการถามว่าเลขนี้มีคนใช้อยู่หรือยัง ก่อนที่เครื่องจะเริ่มใช้เลขที่ ได้มา RFC ระบุว่าช่อง sender IP "MUST be set to all zeroes, to avoid polluting ARP caches"
เหตุผลของศูนย์นั้นอ่านเข้าใจได้ทันทีเมื่อรู้กฎการอัปเดตแคชข้างบน ถ้าใส่เลขลงไป แล้วปรากฏว่าเลขนั้นมีเจ้าของอยู่แล้ว เท่ากับไปทำตารางของทั้งสายเสียก่อนที่จะรู้ตัว
announcement คือการประกาศว่าเลขนี้เป็นของฉันแล้ว ใส่เลขเดียวกันทั้งสองช่อง ไม่ได้ถามใคร แค่ทำให้ทุกเครื่องบนสายอัปเดตตารางตามกฎข้างบน
ใช้ตอนไหน สองกรณีหลัก ตอนเพิ่งตั้งที่อยู่เสร็จ เพื่อให้คนอื่นรู้ทันที และ ตอนสลับเครื่องสำรอง เพราะเลขเดิมย้ายไปอยู่การ์ดใบใหม่ ต้องบอกทั้งสายให้เขียน ทับ ไม่อย่างนั้นทุกคนจะยังส่งไปหาเครื่องที่ตายแล้วจนกว่ารายการจะหมดอายุ
proxy ARP — ตอบแทนคนอื่น
RFC 1027 ปี 1987 อธิบายเทคนิคที่เราเตอร์ตอบ ARP แทนเครื่องที่อยู่คนละฝั่ง
The gateway can then respond for host B, saying that the network address for host B is that of the gateway itself
ผลคือเครื่องที่ถามคิดว่าปลายทางอยู่บนสายเดียวกัน แล้วส่งเฟรมไปให้เราเตอร์ ซึ่งเราต์ต่อให้ตามปกติ
ประโยชน์คือเครื่องที่ตั้งมาสก์ผิดหรือไม่มีเกตเวย์ก็ยังใช้งานได้ ซึ่งเป็น เหตุผลที่มันเกิดขึ้นในยุคที่การตั้งค่ายังทำด้วยมือทั้งหมด
และ RFC ฉบับเดียวกันก็เตือนไว้หนักมาก ห้ามตอบแทนเครื่องที่อยู่คนละเครือข่าย IP ห้ามตอบเมื่อผู้ถามกับเป้าหมายอยู่บนสายกายภาพเดียวกัน และห้ามตอบให้ที่อยู่ broadcast เด็ดขาด โดยระบุว่าการทำแบบนั้นอาจทำให้เกิดสิ่งที่มันเรียกว่า "Chernobyl effect" คือเครือข่ายละลายทั้งวง
ทุกวันนี้ proxy ARP ถือเป็นสิ่งที่ควรปิดมากกว่าเปิด เพราะมันซ่อนการตั้งค่าที่ผิด ไว้แทนที่จะทำให้เห็น
ทั้งชั้นวางอยู่บนความเชื่อใจ
รวมสามข้อที่อธิบายมาแล้วเข้าด้วยกัน
หนึ่ง ARP ไม่ได้อยู่บน IP จึงไม่มีกลไกความปลอดภัยอะไรมาให้ใช้เลย
สอง ตารางถูกเขียนทับได้จากแพ็กเก็ตที่ไม่ได้ส่งมาถึงเรา ตามกฎปี 1982
สาม announcement คือการประกาศที่ไม่มีใครถาม และทุกคนต้องเชื่อ
ผลคือใครก็ตามที่อยู่บนสายเดียวกันบอกได้ว่าเลขที่อยู่ใดเป็นของ MAC ใด และไม่มี อะไรในโพรโทคอลให้ตรวจสอบได้แม้แต่นิดเดียว
การโจมตีที่ตรงไปตรงมาที่สุดคือบอกเหยื่อว่าตัวเองคือเกตเวย์ และบอกเกตเวย์ว่าตัวเอง คือเหยื่อ ทราฟฟิกทั้งสองทางจึงวิ่งผ่านผู้บุกรุก โดยที่ทุกอย่างข้างบนยังทำงาน ปกติทุกประการ
สังเกตว่าอาการนี้ไม่มีอะไรผิดปกติให้เห็นเลย เว็บยังเปิดได้ ปิงยังผ่าน ความเร็ว แทบไม่ต่าง เพราะทุกอย่างยังถึงปลายทางจริง แค่แวะระหว่างทาง
ทางแก้ที่ไม่ได้อยู่ในโพรโทคอล
แก้ที่ ARP ไม่ได้ เพราะไม่มีที่ให้แก้ ทางแก้จึงอยู่ที่ชั้นล่างกับชั้นบน
ที่สวิตช์ ให้จำว่าเลขที่อยู่ไหนควรอยู่พอร์ตไหน โดยดูจากที่ DHCP แจกไป แล้วทิ้งแพ็กเก็ต ARP ที่ขัดกับที่จำไว้
ที่ชั้นบน ยอมรับว่าเส้นทางเชื่อไม่ได้ แล้วเข้ารหัสตั้งแต่ต้นทางถึงปลายทาง ผู้บุกรุกยังเห็นว่ามีทราฟฟิก แต่อ่านไม่ออกและแก้ไม่ได้
ข้อหลังคือเหตุผลที่การเข้ารหัสทุกอย่างกลายเป็นค่าตั้งต้นของยุคนี้ ไม่ใช่เพราะ เครือข่ายแย่ลง แต่เพราะเลิกสมมติว่ามันดี
ปัญหากลับด้าน — RARP และทายาทของมัน
ถ้า ARP ตอบคำถามว่าเลขที่อยู่นี้อยู่ที่ MAC ไหน คำถามกลับด้านคือ MAC ของฉันควร ได้เลขที่อยู่อะไร
RFC 903 ปี 1984 ตอบคำถามนั้นด้วย RARP ซึ่งใช้โครงแพ็กเก็ตเดียวกันเป๊ะ แต่ใช้ EtherType คนละอัน
เหตุผลที่ต้องแยกน่าสนใจกว่าตัวโพรโทคอล RFC เขียนว่า "RARP requires one or more server hosts to maintain a database of mappings from hardware address to protocol address"
นั่นคือความต่างที่แท้จริง ARP ทำงานได้เพราะทุกเครื่องรู้เลขที่อยู่ของตัวเอง จึงตอบเรื่องของตัวเองได้ ไม่ต้องมีใครเป็นศูนย์กลาง ส่วน RARP ต้องมีคนที่รู้แทน เครื่องอื่น ซึ่งแปลว่าต้องมีเซิร์ฟเวอร์
และเมื่อต้องมีเซิร์ฟเวอร์แล้ว การอยู่ที่ชั้นเดียวกับ ARP ก็เสียเปล่า เพราะข้าม เราเตอร์ไม่ได้ สายนั้นจึงพัฒนาต่อไปเป็น BOOTP แล้วเป็น DHCP ซึ่งย้ายขึ้นไปอยู่บน UDP และข้ามซับเน็ตได้ด้วย relay
ฝั่ง IPv6
บทความ IPv6 อธิบายไว้แล้วว่า ARP ถูกแทนที่ด้วย NDP ซึ่งเป็น ICMPv6 หน้านี้เติมมุมที่ขาดไป คือทำไมความต่างนั้นถึงสำคัญ
ARP EtherType 0x0806 broadcast ทั้งสาย
NDP ICMPv6 type 135 multicast เฉพาะกลุ่มความต่างทุกข้อสืบกลับไปที่ข้อเดียวได้หมด ARP อยู่ข้าง ๆ IP ส่วน NDP อยู่ บน IP
การอยู่บน IP ทำให้ NDP ได้ทุกอย่างที่ IPv6 มีมาฟรี ทั้งกลไกความปลอดภัย ทั้ง ความสามารถในการยืนยันตัวตน และทั้งเทคนิค hop limit 255 ที่บทความ IPv6 อธิบายไว้ ซึ่งพิสูจน์ได้ว่าผู้ส่งอยู่บนสายเดียวกันจริง
ARP ไม่มีสิ่งเหล่านั้นสักอย่าง ไม่ใช่เพราะออกแบบไม่ดี แต่เพราะอยู่ผิดที่
นี่คือบทเรียนที่ใช้ได้กว้างที่สุดของหน้านี้ โพรโทคอลที่วางตัวเองไว้ข้าง ๆ ชั้นอื่นแทนที่จะอยู่บนนั้น ต้องสร้างทุกอย่างเองใหม่ทั้งหมด และมักจะไม่ได้สร้าง
เมื่อมันโกหก
"เห็นใน arp -a แปลว่าเครื่องนั้นยังอยู่" ไม่ใช่ รายการอาจค้างมาจากเมื่อ สิบนาทีที่แล้ว เครื่องอาจถูกถอดไปแล้ว หรือเลขอาจถูกยกให้เครื่องอื่นไปแล้ว ตารางบอกแค่ว่าเคยได้ยินอะไรมา ไม่ได้บอกว่าตอนนี้ยังจริงอยู่
"ARP ทำงานที่ชั้นสอง" พูดแบบนี้ก็ไม่ผิดนัก แต่ทำให้พลาดประเด็น มันไม่ได้อยู่ ในชั้นสองหรือชั้นสาม มันคือรอยต่อระหว่างสองชั้น และการที่มันไม่ได้อยู่บน ชั้น ไหนเลยคือเหตุผลที่มันไม่มีอะไรเลย
"เครื่องถามหา MAC ของปลายทางที่จะติดต่อ" จริงเฉพาะเมื่อปลายทางอยู่บนสาย เดียวกัน นอกนั้นถามหาเกตเวย์
"ตั้งรายการเป็น static แล้วปลอดภัย" ช่วยได้จริงกับรายการนั้น แต่ทำกับทุกคู่ ในเครือข่ายไม่ไหว และเลิกใช้ไม่ได้ทันทีที่มีอะไรเปลี่ยน ทางแก้ที่ใช้ได้จริงต้องอยู่ ที่สวิตช์
"ปิด ARP ได้" ไม่ได้ ถ้าจะใช้ IPv4 บนอีเทอร์เน็ต ก็ต้องมี ARP ไม่มีทางเลือกอื่น เลย นั่นคือสิ่งที่ทำให้เรื่องนี้สำคัญ
ตัวอย่างจริงจากงานจริง
กรณีที่ 1 — เครื่องหลุด ๆ ติด ๆ แบบไม่มีรูปแบบ
ปิงบางทีผ่านบางทีไม่ผ่าน สลับไปมา และไม่ขึ้นกับเวลาหรือปริมาณงาน
อ่านอย่างไร อ่านตารางซ้ำ ๆ แล้วดูว่าค่าเปลี่ยนไหม
$ arp -an | grep 192.0.2.7
? (192.0.2.7) at 00:00:5e:00:53:07 on en0 ifscope [ethernet]
$ arp -an | grep 192.0.2.7
? (192.0.2.7) at 00:00:5e:00:53:aa on en0 ifscope [ethernet]MAC เปลี่ยนไปมาระหว่างสองค่า คือลายเซ็นของเลขที่อยู่ซ้ำ มีสองเครื่องอ้าง เลขเดียวกัน แล้วทั้งคู่ตอบ ARP ทำให้ตารางถูกเขียนทับสลับกันตามใครประกาศทีหลัง
สาเหตุที่พบบ่อยคือมีคนตั้งเลขเองด้วยมือทับเลขที่อยู่ในพูลของ DHCP
สิ่งที่ยังไม่ได้พิสูจน์ เรารู้ว่ามีสอง MAC อ้างเลขเดียวกัน แต่ยังไม่รู้ว่าตัว ไหนถูก ให้ดูจากสามไบต์แรกของแต่ละ MAC ว่าเป็นของผู้ผลิตรายไหน แล้วไล่หาจากตาราง MAC ของสวิตช์ว่าแต่ละอันเสียบพอร์ตไหน
กรณีที่ 2 — เปลี่ยนอุปกรณ์แล้วติดต่อไม่ได้อยู่พักหนึ่ง
เปลี่ยนเซิร์ฟเวอร์เป็นเครื่องใหม่โดยใช้เลขที่อยู่เดิม แล้วบางเครื่องยังติดต่อไม่ได้ อยู่หลายนาที ทั้งที่บางเครื่องใช้ได้ทันที
อ่านอย่างไร เครื่องที่ยังไม่ได้ก็คือเครื่องที่ยังมีรายการเก่าค้างอยู่
$ arp -an | grep 192.0.2.20
? (192.0.2.20) at 00:00:5e:00:53:20 on en0 ifscope [ethernet]ถ้า MAC ที่เห็นเป็นของเครื่องเก่า แปลว่ารายการยังไม่หมดอายุ เฟรมถูกส่งไปหา การ์ดใบที่ไม่มีอยู่แล้ว และหายไปเงียบ ๆ
ทางแก้ที่ถูกไม่ใช่รอ แต่คือให้เครื่องใหม่ส่ง announcement ออกไป เพื่อบอกทั้งสาย ให้เขียนทับทันที ซึ่งอุปกรณ์ที่ออกแบบมาสำหรับงานสำรองทำให้เองอยู่แล้ว
สิ่งที่ยังไม่ได้พิสูจน์ เราเห็นว่ารายการเก่าค้าง แต่ยังไม่รู้ว่าเครื่องใหม่ส่ง announcement ออกไปหรือไม่ ให้ดักทราฟฟิกตอนสลับเครื่องเพื่อยืนยัน
กรณีที่ 3 — เครื่องเดียวในห้องที่ออกเน็ตไม่ได้
ทุกเครื่องในห้องใช้ได้ปกติ มีเครื่องเดียวที่ปิงเกตเวย์ไม่เจอ ทั้งที่ได้เลขที่อยู่ ในช่วงเดียวกัน
อ่านอย่างไร ดูว่าเครื่องนั้นคิดว่าเกตเวย์อยู่บนสายเดียวกันหรือเปล่า
$ ifconfig en0 | grep 'inet '
inet 192.0.2.31 netmask 0xffffff00 broadcast 192.0.2.255
$ arp -an | grep 192.0.2.1
(ไม่มีอะไรกลับมา)ถ้ามาสก์ถูกแต่ไม่มีรายการของเกตเวย์เลย แปลว่าถามไปแล้วไม่มีใครตอบ
แต่ถ้ามาสก์ผิด เช่นเป็น 0xffffffc0 แทนที่จะเป็น 0xffffff00 เครื่องจะ คำนวณว่าเกตเวย์อยู่คนละเครือข่าย แล้วไปถามหาเกตเวย์ของเครือข่ายที่ไม่มีอยู่จริง ซึ่งไม่มีใครตอบเช่นกัน แต่คนละสาเหตุกันสิ้นเชิง
สิ่งที่ยังไม่ได้พิสูจน์ ตารางว่างบอกว่าไม่มีใครตอบ ไม่ได้บอกว่าคำถามออกไปถึง ไหน ให้ดักดูว่ามี ARP request ออกจากพอร์ตนั้นจริงหรือไม่
กรณีที่ 4 — ตรวจว่ามีใครปลอมเกตเวย์อยู่หรือเปล่า
ไม่มีอาการผิดปกติ แต่ต้องการยืนยันว่าทราฟฟิกไม่ได้ถูกดักกลางทาง
อ่านอย่างไร จดค่าที่ถูกต้องไว้ก่อน แล้วเทียบเป็นระยะ
$ arp -an | grep 192.0.2.1
? (192.0.2.1) at 00:00:5e:00:53:01 on en0 ifscope [ethernet]สามไบต์แรกของ MAC บอกผู้ผลิต ถ้าเกตเวย์เป็นอุปกรณ์เครือข่ายยี่ห้อหนึ่ง แต่ MAC กลับเป็นของผู้ผลิตโน้ตบุ๊ก นั่นคือสัญญาณที่ชัดมาก
อีกวิธีที่บอกได้เร็วคือดูว่ามี MAC ใดปรากฏคู่กับเลขที่อยู่มากกว่าหนึ่งเลขหรือไม่ ซึ่งเป็นลายเซ็นของการอ้างตัวแทนหลายเครื่องพร้อมกัน
สิ่งที่ยังไม่ได้พิสูจน์ MAC ที่ถูกต้องไม่ได้แปลว่าปลอดภัย เพราะ MAC ปลอมได้ เช่นกัน การตรวจนี้จับได้แค่คนที่ไม่ได้พยายามซ่อน ความมั่นใจจริงต้องมาจากการ เข้ารหัส ไม่ใช่จากการดูตาราง
อ้างอิง
ต้นฉบับ
- RFC 826 — An Ethernet Address Resolution Protocol David C. Plummer, พฤศจิกายน 1982 ที่มาของโครงแพ็กเก็ตทั้งใบ ค่า opcode และกฎการอัปเดตแคชที่ยังใช้อยู่จนวันนี้
- RFC 903 — A Reverse Address Resolution Protocol Finlayson, Mann, Mogul และ Theimer, มิถุนายน 1984 ปัญหากลับด้าน และเหตุผลที่ ต้องมีเซิร์ฟเวอร์ซึ่งพา RARP ไปสู่ BOOTP และ DHCP
ส่วนขยายและข้อควรระวัง
- RFC 5227 — IPv4 Address Conflict Detection Stuart Cheshire, กรกฎาคม 2008 นิยามของ probe กับ announcement และเหตุผลที่ sender IP ของ probe ต้องเป็นศูนย์
- RFC 1027 — Using ARP to Implement Transparent Subnet Gateways Carl-Mitchell และ Quarterman, ตุลาคม 1987 นิยามของ proxy ARP และคำเตือน เรื่องผลที่มันเรียกว่า Chernobyl effect
ของจริงบนเครื่อง
arp -anบน macOS ตารางแปลทั้งใบ พร้อมคำว่าpermanentที่บอกว่ารายการไหน ไม่หมดอายุifconfig en0 | grep 'inet 'มาสก์ที่เป็นตัวตัดสินว่าจะไปถามหาใคร
อ่านต่อในชุดนี้
- ซับเน็ต — การคำนวณที่ตัดสินว่าจะถามหาปลายทางหรือเกตเวย์
- MAC address — สิ่งที่ ARP หาคำตอบให้
- อีเทอร์เน็ต — ตาราง EtherType ที่หน้านี้มาอธิบายหนึ่งแถว และที่มาของเฟรมต่ำสุดที่ทำให้ต้องเติมช่องว่าง