ACL อาจเขียนถูกครบทุกบรรทัด แต่หากนำไปใช้กับ Interface หรือ Direction ที่ไม่ตรงกับ Traffic Flow ผลลัพธ์ก็อาจกระทบระบบอื่นได้

Access Control List หรือ ACL คือชุดเงื่อนไขที่อุปกรณ์ Network ใช้ตรวจสอบและจำแนก Traffic

เมื่อนำ ACL ไปผูกกับ Interface อุปกรณ์จะใช้กฎเหล่านี้ตัดสินใจว่าจะ Permit หรืออนุญาต และ Deny หรือปฏิเสธ Packet ที่วิ่งผ่าน

ในงานบางประเภท เช่น NAT ACL จะถูกใช้เพื่อเลือกว่ากลุ่ม Address ใดต้องเข้าสู่กระบวนการแปลงค่า โดยไม่ได้ทำหน้าที่ Block Traffic แบบ ACL ที่ใช้กรองบน Interface

การทำงานกับ ACL จึงมีมากกว่าการเขียน Command ให้ถูกต้อง

คนทำงานด้าน Network จึงต้องพิจารณาต่อว่า

• — ควรใช้ ACL ประเภทใด
• — ผูกกับ Interface ไหน
• — ตรวจสอบ Traffic แบบ Inbound หรือ Outbound
• — และวางไว้ตรงไหนจึงจะควบคุมการเชื่อมต่อได้โดยไม่กระทบระบบอื่น

เริ่มจากความแตกต่างพื้นฐานระหว่าง ACL สองประเภท

Standard IPv4 ACL ใช้ Source IP Address เป็นเงื่อนไขในการจำแนก Packet จึงเหมาะกับ Policy ที่ต้องการควบคุม Traffic จากต้นทางในภาพรวม โดยไม่แยก Destination, Protocol หรือ Port

Extended ACL ระบุเงื่อนไขได้ละเอียดกว่า ทั้ง Source IP, Destination IP, Protocol และหมายเลข Port ใน Layer 4 จึงเหมาะกับ Policy ที่ต้องการกำหนดว่า Source ใดเข้าถึง Destination หรือ Service ใดได้บ้าง

ตัวอย่างเช่น

access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 80

คำสั่งนี้อนุญาตให้อุปกรณ์จาก Network 192.168.10.0/24 เชื่อมต่อไปยังปลายทางใดก็ได้ ผ่าน TCP Destination Port 80

Wildcard Mask 0.0.0.255 กำหนดให้ Router ตรวจสอบสาม Octet แรกว่าต้องตรงกับ 192.168.10 ส่วน Octet สุดท้ายไม่ถูกนำมาเปรียบเทียบ จึงครอบคลุม Address ตั้งแต่ 192.168.10.0 ถึง 192.168.10.255

นอกจากเงื่อนไขในแต่ละบรรทัดแล้ว ลำดับของ Statement ก็มีผลโดยตรงต่อผลลัพธ์

Router ตรวจสอบ ACL จากบนลงล่าง และหยุดทันทีเมื่อพบ Statement แรกที่ตรงกับ Packet

หากกฎที่มีเงื่อนไขกว้างอยู่เหนือกฎเฉพาะ Router อาจ Match ตั้งแต่บรรทัดแรก ทำให้กฎด้านล่างไม่ถูกนำมาใช้

ถัดมาคือ Placement หรือตำแหน่งที่นำ ACL ไปใช้งาน

Standard ACL ตรวจสอบเฉพาะ Source IP หากเริ่มกรองตั้งแต่ Interface ฝั่งต้นทาง Traffic จาก Source เดียวกันที่ต้องเดินทางไปยังระบบอื่นอาจถูกปฏิเสธไปพร้อมกัน

จึงมักกำหนดให้ Standard ACL ทำงานทางฝั่งปลายทาง เพื่อจำกัดผลกระทบให้อยู่เฉพาะเส้นทางหรือระบบที่ต้องการควบคุม

ส่วน Extended ACL สามารถระบุ Source, Destination, Protocol และ Port ได้ละเอียดกว่า จึงเริ่มกรอง Traffic ตั้งแต่ Interface ฝั่งต้นทางได้ ช่วยหยุด Packet ที่ไม่ตรงกับ Policy ก่อนเดินทางผ่าน Network ส่วนอื่นโดยไม่จำเป็น

อย่างไรก็ตาม หลักนี้เป็น Best Practice เบื้องต้น ไม่ใช่สูตรสำเร็จสำหรับทุก Topology

ตำแหน่งจริงยังต้องพิจารณา Routing Path, Interface, Existing Policy และผลกระทบต่อ Traffic อื่นร่วมกัน

ก่อน Apply ACL ในระบบจริง ควรตรวจสอบอย่างน้อย 4 จุด

• 1. Traffic เริ่มจาก Network ใดและมุ่งหน้าไปที่ใด
• 2. ACL ถูกผูกกับ Interface ที่ถูกต้องหรือไม่
• 3. ควรตรวจสอบ Packet ในทิศทาง Inbound หรือ Outbound
• 4. มี Traffic สำคัญใดที่ยังไม่ได้เขียน Permit ไว้หรือไม่

ข้อสุดท้ายต้องระวังเป็นพิเศษ

สำหรับ ACL ที่ใช้กรอง Traffic ท้ายรายการจะมี Implicit Deny หรือเงื่อนไขปฏิเสธที่ระบบกำหนดไว้โดยอัตโนมัติ

Packet ที่ไม่ตรงกับ Permit Statement ใดเลยจึงถูกปฏิเสธ แม้ใน Configuration จะไม่มีคำสั่ง Deny เขียนไว้โดยตรง

หลัง Apply ACL ควรสร้าง Traffic ทดสอบ แล้วตรวจสอบทั้ง Running Configuration, Hit Count และสถานะบน Interface เพื่อยืนยันว่า ACL ทำงานตรงตามที่ออกแบบไว้

show access-lists

ใช้ตรวจสอบ Statement และจำนวน Packet ที่ Match แต่ละเงื่อนไข

show ip interface

ใช้ดูว่า Interface ผูกกับ ACL ใด และทำงานในทิศทาง Inbound หรือ Outbound

show running-config interface

ใช้ยืนยัน Configuration ที่อยู่บน Interface นั้น

เมื่อข้อมูลทั้งสามส่วนสอดคล้องกัน ทีมจะเริ่มแยกได้ว่า ปัญหาเกิดจาก Logic ของ ACL ตำแหน่ง Apply หรือ Traffic ไม่ได้วิ่งผ่านเส้นทางที่คาดไว้

ความเข้าใจ ACL ยังต่อยอดไปไกลกว่าการ Permit หรือ Deny Traffic

ACL สามารถใช้จำแนกกลุ่ม Network เพื่อนำไปทำงานร่วมกับฟังก์ชันอื่นของ Router ได้ด้วย

หนึ่งในตัวอย่างที่พบได้บ่อยคือการใช้ ACL เลือก Source Network ที่ต้องเข้าสู่กระบวนการ NAT ก่อนส่ง Traffic ออกสู่เครือข่ายภายนอก

แล้ว Router รู้ได้อย่างไรว่า Connection หลายร้อยรายการกำลังใช้ Public IP หมายเลขเดียวกันอยู่ โดยข้อมูลขากลับยังเดินทางถึงเครื่องต้นทางได้ถูกต้อง?

ตอนที่ 2 เราจะเปิดดูเบื้องหลัง NAT Overload หรือ PAT ตั้งแต่ ACL ที่ใช้เลือก Traffic ไปจนถึง Translation Table ที่ Router ใช้ติดตามแต่ละ Flow

ทักษะเหล่านี้เป็นส่วนหนึ่งของพื้นฐานที่ผู้ดูแลระบบใช้ในการ Configure, Verify และ Troubleshoot เครือข่าย

หลักสูตร Implementing and Administering Cisco Solutions (CCNA) ช่วยจัดระบบความเข้าใจตั้งแต่ Network Fundamentals, Routing, Switching และ IP Services ไปจนถึง Security Fundamentals และแนวคิดด้าน Network Automation

ผู้เรียนจึงได้เห็นว่าแต่ละ Configuration เชื่อมโยงกับ Traffic Flow อย่างไร แทนการจดจำ Command แยกออกจากพฤติกรรมของระบบ

คอมพิวเตอร์หลายร้อยเครื่องใช้ Public IP เดียวกันได้อย่างไร และ Router รู้ได้อย่างไรว่าข้อมูลขากลับต้องส่งไปที่เครื่องไหน?

เบื้องหลังการแยก Traffic เหล่านี้อยู่ใน Translation Table ที่ Router สร้างขึ้นสำหรับแต่ละ Flow

จากตอนที่ 1 เราได้เห็นว่า ACL ใช้ตรวจสอบและจำแนก Traffic รวมถึงหลักเลือก Interface และ Direction ให้ตรงกับ Traffic Flow

ในตอนนี้ ACL จะถูกนำมาใช้ในอีกบริบทหนึ่ง คือเลือก Source Network ที่ต้องเข้าสู่กระบวนการแปลง Address ก่อนส่ง Traffic ออกสู่อินเทอร์เน็ต

ภายในองค์กร อุปกรณ์จำนวนมากใช้งาน Private IP เช่น

• — 192.168.10.5
• — 192.168.10.6
• — 192.168.10.7

Address ในช่วง Private IP สามารถนำไปใช้ซ้ำในเครือข่ายภายในของหลายองค์กร และโดยปกติจะไม่ถูกส่งต่อบน Public Internet

เมื่อต้องเชื่อมต่อออกสู่อินเทอร์เน็ต Router จึงแปลง Source Address ผ่านกระบวนการ Network Address Translation หรือ NAT

NAT มีหลายรูปแบบ โดยสองแนวคิดที่ควรแยกให้ออกคือ Dynamic NAT และ PAT

Dynamic NAT จับคู่ Inside Local Address กับ Address จาก NAT Pool แบบหนึ่งต่อหนึ่งในช่วงที่ Translation ทำงานอยู่

หาก Address ใน Pool ถูกใช้งานครบ อุปกรณ์ภายในรายใหม่ต้องรอจนกว่าจะมี Address ว่าง

ส่วน PAT หรือ NAT Overload เปิดให้อุปกรณ์หลายเครื่องแชร์ Global Address เดียวกัน

สำหรับ TCP และ UDP Router จะใช้หมายเลข Port ร่วมกับ Address และ Protocol เพื่อแยกแต่ละ Flow ส่วน Traffic อย่าง ICMP จะใช้ Identifier ที่เกี่ยวข้องแทน Port

ตัวอย่าง Configuration เริ่มจาก ACL ที่ระบุกลุ่ม Private IP

access-list 10 permit 192.168.10.0 0.0.0.255

จากนั้นนำ ACL ไปอ้างอิงในคำสั่ง NAT

ip nat inside source list 10 interface GigabitEthernet0/0 overload

คำสั่งนี้กำหนดให้ Router นำ Inside Source Address ที่ตรงกับ ACL 10 ไปแปลงเป็น IP Address ของ Interface GigabitEthernet0/0 ระหว่างส่ง Traffic จากฝั่ง Inside ไปยังฝั่ง Outside

Keyword overload เปิดให้หลาย Inside Local Address ใช้ Inside Global Address เดียวกัน โดย Router แยกแต่ละ Flow ผ่านหมายเลข Port หรือ Identifier ที่เกี่ยวข้อง

เพื่อให้ NAT ทำงานตรงตามเส้นทาง Interface แต่ละฝั่งต้องได้รับบทบาทที่ถูกต้อง

Interface ทางเครือข่ายภายในกำหนดเป็น

ip nat inside

Interface ที่เชื่อมต่อออกสู่เครือข่ายภายนอกกำหนดเป็น

ip nat outside

เมื่อเครื่อง 192.168.10.5 เปิด Connection ออกสู่อินเทอร์เน็ต Router จะสร้าง Translation Entry เชื่อมโยง Address และ Port ฝั่ง Inside เข้ากับค่าที่ใช้บนฝั่ง Outside

เราสามารถเปิดดู Translation Table ที่ Router ใช้บันทึกและติดตามแต่ละ Flow ได้ด้วยคำสั่ง

show ip nat translations

ภายในตารางจะพบ Address สำคัญ 4 รูปแบบ

• Inside Local
  IP Address จริงของอุปกรณ์ภายใน ตามที่ใช้งานอยู่ใน Local Network
• Inside Global
  IP Address ที่ Router ใช้แทนอุปกรณ์ภายใน เมื่อ Traffic ออกไปปรากฏบนเครือข่ายภายนอก
• Outside Global
  IP Address ของอุปกรณ์ปลายทาง ตามที่ปรากฏอยู่บนเครือข่ายภายนอก
• Outside Local
  IP Address ของอุปกรณ์ปลายทาง ตามที่อุปกรณ์ภายในมองเห็น

ในระบบที่ไม่มีการแปลง Address ของฝั่ง Outside ค่า Outside Local และ Outside Global มักเป็น Address เดียวกัน

สำหรับ PAT Router จะติดตามทั้ง Address, Protocol และ Identifier ของแต่ละ Flow

Router อาจคง Source Port เดิมไว้หากยังไม่เกิดความซ้ำกัน หรือเลือกหมายเลขอื่นเพื่อให้ Translation แต่ละรายการแยกจากกันได้

เมื่อ Response Packet เดินทางกลับมา Router จะค้นหา Translation Entry ที่ตรงกัน ก่อนแปลง Address กลับและส่งต่อไปยัง Inside Local Address ของเครื่องต้นทาง

PAT จึงรองรับหลาย Flow ผ่าน Public IP เดียวได้ ภายใต้ทรัพยากรและ State ที่ Router ต้องติดตามอย่างต่อเนื่อง

หาก Translation Table หรือหมายเลข Port ที่ใช้งานได้เริ่มไม่เพียงพอ รวมถึงกรณี Routing, Return Path หรือบทบาท Inside/Outside ถูกกำหนดคลาดเคลื่อน การเชื่อมต่อก็อาจสะดุดได้

เมื่อ NAT มีปัญหา ลำดับการตรวจสอบต่อไปนี้ช่วยให้ทีมไล่หาสาเหตุได้เป็นขั้นตอน

• 1. ระบุ Expected Flow ให้ชัด ทั้ง Source, Destination, Protocol และ Port
• 2. ตรวจสอบ Routing และ Default Route ว่า Traffic ออกผ่าน Interface ที่คาดไว้
• 3. ยืนยันบทบาท ip nat inside และ ip nat outside ของแต่ละ Interface
• 4. ตรวจสอบว่า ACL Match กับ Source Network ที่ต้องการแปลง
• 5. ตรวจสอบคำสั่ง NAT รวมถึง Address หรือ Interface ที่ใช้เป็น Inside Global
• 6. สร้าง Traffic ทดสอบ แล้วดู Translation Table และ NAT Statistics
• 7. หากเกิด Translation แล้ว ให้ตรวจสอบ Return Path, ACL, Firewall และ Policy ที่เกี่ยวข้อง

คำสั่งหลักที่ใช้ตรวจสอบ ได้แก่

• — show ip nat translations
• — show ip nat statistics
• — show access-lists
• — show ip route

หากยังไม่มี Translation Entry เกิดขึ้น จุดที่ต้องไล่ดูก่อนคือ ACL Match กับ Source Network หรือไม่ Traffic วิ่งผ่าน Router ตัวนั้นหรือเปล่า และ Interface ถูกกำหนดเป็น NAT Inside/Outside ตรงฝั่งยัง

หาก Translation เกิดขึ้นแล้ว แต่ปลายทางยังสื่อสารกลับมาไม่ได้ ให้ตรวจสอบ Routing, Return Path, Default Route และ Security Policy ตามเส้นทางต่อ

Command ช่วยยืนยันว่าอุปกรณ์ถูกกำหนดให้ทำอะไร ส่วนการ Troubleshoot ต้องติดตามต่อว่า Packet เริ่มจากจุดใด ผ่าน Interface ไหน ถูกแปลง Address ช่วงใด และผลลัพธ์เริ่มคลาดจากที่คาดตรงไหน

คนดูแลระบบจึงต้องเชื่อมข้อมูลจาก Routing Table, ACL, Interface Configuration และ Translation Table เข้าด้วยกัน เพื่อมองเห็นพฤติกรรมของ Traffic เป็นลำดับ แทนการตรวจสอบ Command แยกทีละส่วน

เพราะในระบบจริง NAT ไม่ได้ทำงานแยกจาก Routing, Switching หรือ Security Policy

• — ACL อาจ Match ถูกต้อง แต่ Traffic วิ่งออกผิด Interface
• — NAT อาจสร้าง Translation Entry แล้ว แต่ Return Path กลับมาไม่ถึง
• — หรือ Configuration ทุกบรรทัดดูปกติ ขณะที่ Packet ไม่ได้ผ่านอุปกรณ์ตัวที่ทีมกำลังตรวจสอบ

การแก้ปัญหา Network จึงต้องอาศัยทั้งความเข้าใจพื้นฐานและวิธีตรวจสอบหลักฐานจากอุปกรณ์ เพื่อค่อยๆ จำกัดขอบเขตของสาเหตุให้แคบลง

สองตอนนี้ชวนให้เห็นว่า ACL และ NAT ไม่ได้ทำงานแยกจากกัน แต่เชื่อมอยู่ใน Traffic Flow เดียวกัน ตั้งแต่การเลือก Packet ที่ต้องตรวจสอบ ไปจนถึงการแปลง Address และส่งข้อมูลกลับถึงเครื่องต้นทาง

เมื่อเข้าใจความเชื่อมโยงเหล่านี้ การตรวจสอบปัญหาจะไม่หยุดอยู่ที่การจำ Command แต่เริ่มไล่หาสาเหตุจากเส้นทางและพฤติกรรมของ Traffic ได้เป็นขั้นตอน

พื้นฐานลักษณะนี้เป็นส่วนหนึ่งของหลักสูตร Implementing and Administering Cisco Solutions (CCNA) ซึ่งช่วยจัดระบบความเข้าใจตั้งแต่ Network Fundamentals, Switching, Routing และ IP Services ไปจนถึง Security Fundamentals และ Network Automation

ผู้เรียนจะได้เชื่อมโยง Command เข้ากับ Traffic Flow ผ่านการฝึกปฏิบัติ ตั้งแต่การกำหนดค่า ตรวจสอบผลลัพธ์ ไปจนถึงการวิเคราะห์ปัญหาจากข้อมูลที่อุปกรณ์แสดงออกมา