ทำไมผลการสแกนพอร์ตจึงเปลี่ยนไปเมื่ออยู่หลังทางออก VPN?
เปลี่ยนทางออกและพอร์ตอาจตอบต่างออกไปโดยที่บริการไม่ได้ย้ายที่ แยกการสังเกตเส้นทางออกจากบัญชีที่คุณต้องการจริง ๆ
รันการตรวจพอร์ตเดียวกันจากสายสำนักงานและจากทางออก VPN และคำตอบทั้งสองอาจไม่ตรงกันเกี่ยวกับที่อยู่ที่ไม่มีใครเปลี่ยน ช่องว่างนั้นมาจากเส้นทางและจากโฮสต์ที่ตอบ ไม่ใช่ว่าบริการทำงานหรือล่ม สามคำถามแยกคำอธิบายเหล่านั้น: การตรวจถามอะไรจริง ๆ โฮสต์ใดตอบ และเซิร์ฟเวอร์ของคุณเองบันทึกอะไรไว้ ลองไล่ตามลำดับนั้นและเขียนคำตอบแต่ละข้อก่อนไปข้อถัดไป
ซ่อมการตรวจก่อนเปรียบเทียบสองรอบ
คำสถานะจะเทียบกับคำสถานะอื่นได้ก็ต่อเมื่อทั้งสองมาจากการทดลองเดียวกัน ห้าฟิลด์กำหนดสิ่งนั้น: ที่อยู่ต้นทางที่ฝั่งไกลเห็น ปลายทางที่แก้แล้ว พอร์ต ชนิดการสแกน และเวลา เปลี่ยนข้อใดข้อหนึ่งแล้วคุณก็ทำการทดลองที่สองแทนที่จะวัดครั้งแรกสองครั้ง
ตรวจต้นทางก่อนสิ่งอื่น เพราะไคลเอนต์ VPN อาจทำงานอยู่ขณะที่ทราฟฟิกยังออกผ่านอินเทอร์เฟซทางกายภาพ ถามฝั่งไกลว่าเห็นอะไร แล้วถามเคอร์เนลว่าเลือกอินเทอร์เฟซใด:
curl -s https://ifconfig.me
ip route get 203.0.113.20สองที่อยู่บนเครือข่ายต่างกันหมายความว่าคำอธิบายอยู่ในมือแล้ว และการตรวจที่เหลือจะยืนยันเท่านั้น เมื่อทั้งสองตรงกัน ให้บันทึกการตรวจโดยเปิดแฟล็กเหตุผลไว้ เพื่อให้สถานะกลับมาพร้อมคำอธิบายแทนที่จะยืนอยู่ลำพังเป็นคำเปล่า ชนิดการสแกนก็เป็นของบันทึกนั้นด้วย เพราะมันบรรยายสิ่งที่ถาม ไม่ใช่สิ่งที่กลับมา สถานะที่ไม่มีต้นทาง ไม่มีวิธี และไม่มีเวลาไม่สามารถเทียบกับอะไรได้:
nmap -sT -p 443,8443 --reason 203.0.113.20เก็บเอาต์พุตนั้นไว้ข้างบันทึก ไม่ใช่ในบัฟเฟอร์เลื่อนที่คนถัดไปมองไม่เห็น การสแกนที่ซื่อสัตย์สองครั้งที่ขัดกันจะเป็นข้อโต้แย้งก็ต่อเมื่อไม่มีใครเขียนเงื่อนไขไว้ เมื่อกำหนดเงื่อนไขแล้ว ไม่ผลก็ตรงกันและคำถามจบลง หรือไม่ก็ต่างกันและความต่างนั้นเป็นข้อเท็จจริงเกี่ยวกับเส้นทาง
หาให้ได้ว่าโฮสต์ใดเป็นผู้จบการจับมือ
การจับมือที่สมบูรณ์พิสูจน์ว่ามีโฮสต์หนึ่งจบมัน และโฮสต์นั้นไม่จำเป็นต้องเป็นโปรเซสที่คุณนึกถึง ตัวกระจายโหลด พร็อกซีย้อนกลับ หรือพร็อกซี SYN อาจตอบก่อนเซิร์ฟเวอร์จริงจะเข้ามาเกี่ยวข้อง ซึ่งเป็นการออกแบบปกติ ไม่ใช่อาการ ใบรับรองที่ใช้ได้สำหรับชื่อที่คาดไว้ก็ไม่ได้จำกัดสิ่งนี้ เพราะใบรับรองบรรยายความสัมพันธ์ของบริการและไม่บอกอะไรเกี่ยวกับเครื่องที่จบการเชื่อมต่อ
เอกสารอ้างอิงสถานะพอร์ตของ Nmap ถือว่านี่เป็นพื้นฐาน: สถานะบันทึกสิ่งที่การตรวจสังเกตได้จากจุดที่ส่ง ไม่ใช่คุณสมบัติของพอร์ต อ่านคำสถานะแบบนั้นแล้วสองรอบที่ขัดกันจะเริ่มดูสอดคล้องกันแทนที่จะขัดแย้ง ขณะที่คำถามย้ายจากพอร์ตเปิดหรือไม่ไปเป็นใครยืนอยู่ข้างหน้า
ตอบคำถามที่สองที่แบ็กเอนด์ ไม่ใช่จากข้างนอก ฟรอนต์เอนด์ที่รับการเชื่อมต่อแล้วไปไม่ถึงอัปสตรีมของตนให้ภาพภายนอกที่เหมือนบริการสุขภาพดีแต่แอปพลิเคชันช้า บันทึกของอัปสตรีมเองเท่านั้นที่แยกสองกรณีนี้:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'บรรทัดล็อกแสดงที่อยู่ไคลเอนต์ที่แอปพลิเคชันเห็นจริง และคำสั่งที่สองแสดงว่าโปรเซสที่ถือพอร์ต 443 เป็นแอปพลิเคชันของคุณหรืออะไรบางอย่างข้างหน้า ถ้าทั้งสองไม่ตรงกันว่าที่อยู่ใดเชื่อมต่อ คุณกำลังดูขาสองข้างของคำขอเดียว และตั๋วควรบอกเช่นนั้น
ตรวจกฎของคุณเองก่อนโทษอุโมงค์
นโยบายที่ตั้งใจไว้เป็นสาเหตุที่พบบ่อยที่สุดที่พอร์ตตอบในเครือข่ายหนึ่งแต่ไม่อีกเครือข่ายหนึ่ง และเป็นคำอธิบายที่น่าสนใจน้อยที่สุดเท่าที่มี กฎการเข้าถึงมีไว้เพื่ออนุญาตต้นทางหนึ่งและทิ้งที่เหลือ ดังนั้นการเปลี่ยนทางออกจึงเป็นเหตุการณ์ที่กฎเหล่านั้นถูกเขียนขึ้นมาเพื่อรองรับพอดี ดังนั้นสถานะที่ต่างออกไปผ่าน VPN จึงไม่ได้แสดงว่าผู้ให้บริการตรวจสอบทราฟฟิก มันแสดงว่าที่อยู่ต้นทางของคุณตอนนี้ต่างออกไป ซึ่งเป็นการอ้างที่เล็กกว่ามาก
กฎเหล่านั้นอ่านได้บนเซิร์ฟเวอร์ ดังนั้นอ่านมันแทนการคาดเดาเกี่ยวกับกลางเครือข่าย แสดงรายการกฎตัวกรองที่กล่าวถึงช่วงที่อยู่ใดช่วงหนึ่งจากสองช่วง แล้วตรวจว่าการเชื่อมต่อไปถึงเดมอนหรือไม่:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113ผลที่สองว่างเปล่าให้ข้อมูล เพราะไม่มีอะไรไปถึงเดมอนและคำถามเป็นของตัวกรอง กลุ่มความปลอดภัย หรือเส้นทางเอง การโดนหมายความว่าบริการเห็นต้นทางของคุณและเลือกคำตอบของมัน และการตัดสินใจนั้นมักเขียนไว้ในกฎที่คุณอ่านได้ ไม่มีผลใดสนับสนุนเรื่องเล่าเกี่ยวกับผู้ให้บริการ และทั้งสองถูกกว่าการดักจับแพ็กเก็ต
อ่านการขนส่ง ใบรับรอง และการตอบสนองแยกกัน
สามชั้นให้การสังเกตสามอย่าง และการตรวจที่ทดสอบอย่างหนึ่งไม่อาจรายงานอีกสองอย่างได้ เก็บไว้เป็นบรรทัดแยกในบันทึกแทนที่จะพับรวมเป็นการตัดสินเดียว เพราะแต่ละบรรทัดล้มเหลวในแบบของมัน และโหมดล้มเหลวบอกว่าควรมองที่ไหนต่อไป
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
คำสั่งเดียวสร้างสามบรรทัดแรกกับบริการที่คุณควบคุม ใส่เอาต์พุตไว้ในบันทึกข้างการสแกน ไม่ใช่ในข้อความแชต:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/อ่านเอาต์พุตตามลำดับ: การจับมือตอบคำถามการขนส่ง หัวข้อใบรับรองตอบคำถามชื่อ และเนื้อหาการตอบสนองตอบคำถามแอปพลิเคชัน เมื่อบรรทัดการจับมือสำเร็จแต่บรรทัดการตอบสนองไม่สำเร็จ คุณมีฟรอนต์เอนด์ที่อัปสตรีมเสีย ไม่ใช่พอร์ตที่ถูกบล็อก นั่นเป็นตั๋วคนละใบกับที่คุณเปิด และควรพูดให้ชัด
จบด้วยการเขียนข้อเท็จจริงสี่ข้อลงในตั๋ว: ที่อยู่ต้นทาง ชนิดการสแกน โฮสต์ที่ตอบ และเวลา ทุกอย่างที่การเปรียบเทียบภายหลังต้องการอยู่ในสี่ข้อนั้น และคนที่รับเรื่องต่อไปจะไม่มีประวัติเทอร์มินัลของคุณ หากคุณเติมทั้งสี่ไม่ได้ การรันก็ยังไม่จบ