แก้ไขข้อผิดพลาด “WebDAV Interface Is Broken” ใน ownCloud

หาก ownCloud โหลดในเบราว์เซอร์ได้ แต่หน้าผู้ดูแลระบบแจ้งว่า “อินเทอร์เฟซ WebDAV เสียหาย” การอัปโหลดไฟล์ การซิงค์เดสก์ท็อป และแอปไฟล์อาจล้มเหลวเช่นกัน คำเตือนนี้เป็นเพียงอาการ ไม่ใช่การวินิจฉัยปัญหา: ปลายทาง DAV อาจไม่สามารถเข้าถึงได้ เขียนทับไม่ถูกต้อง ถูกบล็อกโดยพร็อกซีหรือกฎความปลอดภัย หรือไม่สามารถเข้าถึงได้เมื่อ ownCloud เรียกใช้ URL สาธารณะของตนเอง

คู่มือนี้ใช้ได้กับการติดตั้ง ownCloud Classic Server เท่านั้น ownCloud Infinite Scale มีสถาปัตยกรรมและรูปแบบการใช้งานที่แตกต่างกัน ดังนั้นอย่าใช้การตั้งค่า Apache ของ Classic Server กับการใช้งาน Infinite Scale หน้าเว็บอย่างเป็นทางการที่ลิงก์ไว้ด้านล่างครอบคลุม ownCloud Server 10.15 และ 10.16 รวมถึง Classic Server 11.0 การตรวจสอบใช้เส้นทาง WebDAV และข้อกำหนดของ Apache ที่ระบุไว้ในเอกสาร ในขณะที่คำเตือนสำหรับผู้ดูแลระบบอาจแตกต่างกันไปตามเวอร์ชัน

หมายเหตุประกอบภาพ:ภาพอินเทอร์เฟซและเทอร์มินัลด้านล่างเป็นเพียงตัวอย่างแผนผังเท่านั้น ชื่อโฮสต์ บรรทัดสถานะ และค่าที่แสดงเป็นเพียงตัวอย่าง ไม่ใช่ภาพการติดตั้งจริง หรือการยืนยันว่ามีการทดสอบเกิดขึ้น

ข้อความเตือน WebDAV หมายความว่าอย่างไร?

WebDAV คืออินเทอร์เฟซแบบ HTTP ที่ ownCloud ใช้ในการแสดงรายการและจัดการไฟล์สำหรับไคลเอนต์การซิงค์และการดำเนินการไฟล์ที่เกี่ยวข้อง การเข้าสู่ระบบผ่านเบราว์เซอร์เป็นการยืนยันเพียงว่าอินเทอร์เฟซเว็บตอบสนองเท่านั้น ไม่ได้เป็นการยืนยันว่าคำขอ WebDAV ไปถึง ownCloud พร้อมด้วยเส้นทาง วิธีการ ส่วนหัวการตรวจสอบสิทธิ์ และการเชื่อมต่อ HTTPS อย่างสมบูรณ์

เริ่มต้นด้วยการตรวจสอบว่าความล้มเหลวเกิดจากปัจจัยภายนอกหรือเกิดจากการตรวจสอบตัวเองของ ownCloud เท่านั้น ข้อผิดพลาดของไคลเอ็นต์การซิงค์และการร้องขอ WebDAV ที่ไม่ได้รับการตรวจสอบสิทธิ์บ่งชี้ว่าปัญหาอาจอยู่ที่เส้นทาง DAV หรือการตรวจสอบสิทธิ์ หากไคลเอ็นต์ทำงานได้ แต่คำเตือนของผู้ดูแลระบบยังคงอยู่ ให้ทดสอบว่าเซิร์ฟเวอร์สามารถแก้ไขและเข้าถึงชื่อโฮสต์สาธารณะได้หรือไม่ รวมถึงใบรับรอง TLS ด้วย

ขั้นตอนที่ 1: บันทึก URL ที่ถูกต้องและทดสอบ WebDAV โดยตรง

ใช้ชื่อโฮสต์และเส้นทางการติดตั้งเดียวกันกับที่ผู้ใช้ป้อนในเบราว์เซอร์ สำหรับการติดตั้งบนโดเมนหลัก เส้นทาง DAV ของ Classic Server ในปัจจุบันมักใช้รูปแบบนี้:

https://cloud.example.com/remote.php/dav/files/USERNAME/

หากติดตั้ง ownCloud ไว้ในพาธที่กำหนด ให้ใส่พาธนั้นไว้ข้างหน้า/remote.phpเช่นhttps://example.com/owncloud/remote.php/dav/files/USERNAME/ใช้ชื่อบัญชีและ URL ของคุณเอง อย่าทดสอบชื่อโฮสต์ที่สร้างขึ้นเอง หรือสมมติว่าทุกการติดตั้งใช้ไดเร็กทอรีย่อยเดียวกัน

จากเครื่องไคลเอ็นต์ ส่งคำขอ PROPFIND ที่ได้รับการตรวจสอบสิทธิ์แล้ว หากใช้ cURL การส่งเฉพาะชื่อผู้ใช้จะทำให้ระบบขอรหัสผ่านแทนที่จะใส่รหัสผ่านไว้ในคำสั่ง:

curl -i --user USERNAME -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/remote.php/dav/files/USERNAME/'

การตอบสนอง WebDAV ที่ถูกต้องและมีการตรวจสอบสิทธิ์มักใช้ HTTP เครื่องหมาย * 207 Multi-Statusอาจ401หมายความว่าข้อมูลประจำตัวไม่ได้รับการยอมรับ เครื่องหมาย * 404มักชี้ไปยังเส้นทางที่ไม่ถูกต้องหรือการเขียนเส้นทางพร็อกซีใหม่ เครื่องหมาย * บ่ง 403ชี้ถึงกฎการเข้าถึง WAF หรือนโยบายเซิร์ฟเวอร์ และเครื่องหมาย * 301หรือ * 302อาจบ่งชี้ถึงการเปลี่ยนเส้นทางที่ไคลเอ็นต์หรือการตรวจสอบตนเองไม่ปฏิบัติตามอย่างที่คาดไว้ อ่านส่วนหัวการตอบสนองและบันทึกของเซิร์ฟเวอร์ก่อนเปลี่ยนแปลงการกำหนดค่า ลบชื่อผู้ใช้ คุกกี้ โทเค็น และ IP สาธารณะก่อนแชร์เอาต์พุตคำสั่ง

แผนผังแสดงภาพรวมการจัดการระบบแบบ ownCloud พร้อมคำเตือนเกี่ยวกับ WebDAV และการตรวจสอบการตั้งค่าอื่นๆ
ภาพรวมแผนผังการจัดการที่แสดงคำเตือน WebDAV โดยค่าสถานะที่แสดงเป็นเพียงตัวอย่าง
แผนภาพการตอบสนองของเทอร์มินัลต่อคำขอ PROPFIND โดยแสดง HTTP 207 Multi-Status และการตอบสนอง DAV XML
ตัวอย่างของข้อความตอบกลับแบบ Multi-Status 207 ที่การตรวจสอบ PROPFIND ที่ผ่านการตรวจสอบสิทธิ์อาจส่งคืน

ขั้นตอนที่ 2: ตรวจสอบว่าเซิร์ฟเวอร์สามารถเข้าถึง URL สาธารณะของตนเองได้หรือไม่

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

getent hosts cloud.example.com
curl -I https://cloud.example.com/status.php

ชื่อโฮสต์ควรสามารถระบุที่อยู่เว็บที่เข้าถึงได้จากเซิร์ฟเวอร์ และคำขอ HTTPS ควรเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาดเกี่ยวกับชื่อใบรับรอง ห่วงโซ่ความเชื่อถือ หรือการเชื่อมต่อ หาก DNS ชี้เซิร์ฟเวอร์กลับผ่านไฟร์วอลล์ที่ไม่รองรับ NAT reflection (หรือที่เรียกว่า hairpin NAT) ไคลเอนต์ภายนอกอาจทำงานได้ในขณะที่การตรวจสอบตัวเองภายในล้มเหลว การแยก DNS เส้นทางภายในไปยังพร็อกซีแบบย้อนกลับ หรือการปรับแต่งเครือข่ายฝั่งผู้ให้บริการอาจเหมาะสม ให้เลือกการเปลี่ยนแปลงที่แคบที่สุดเท่าที่จะเป็นไปได้เพื่อให้ตรงกับการออกแบบเครือข่ายของคุณ

รายการโดเมนที่เชื่อถือได้คือรายการอนุญาตโฮสต์สำหรับคำขอ ownCloud ที่เข้ามา เพิ่มเฉพาะชื่อโฮสต์ที่ผู้ใช้ใช้งานจริง โดยทำตามขั้นตอนการกำหนดค่าที่ระบุไว้ อย่าเพิ่มที่อยู่ภายในแบบสุ่มโดยเดาoverwrite.cli.urlการตั้งค่านี้ควบคุม URL ที่ใช้โดยบริบทบรรทัดคำสั่ง/พื้นหลังในการกำหนดค่าบางอย่าง ไม่ใช่สิ่งทดแทนการแก้ไข DNS การกำหนดเส้นทาง หรือ TLS ตรวจสอบให้แน่ใจว่าคำเตือนนั้นระบุอะไรก่อนที่จะเปลี่ยนแปลงการตั้งค่าใดๆ

แผนผังแสดงตัวแก้ไขการกำหนดค่า Apache พร้อมกฎไดเร็กทอรี ownCloud และ AllowOverride All
ตัวอย่างมุมมองการกำหนดค่า Apache ที่เน้นการตั้งค่าการแทนที่ไดเร็กทอรี ตรวจสอบเส้นทางและคำสั่งที่ถูกต้องสำหรับการติดตั้งของคุณ

ขั้นตอนที่ 3: ตรวจสอบการตั้งค่าการเขียนใหม่และการตั้งค่าไดเร็กทอรีของ Apache

สำหรับการติดตั้ง Apache คู่มือการกำหนดค่าด้วยตนเองของ ownCloud ระบุให้ใช้mod_rewriteสำหรับAllowOverride Allไดเร็กทอรี ownCloud เมื่อใช้ ที่มาพร้อมกับระบบ.htaccessและการตั้งค่า Apache ที่เกี่ยวข้องกับ DAV เพื่อป้องกันไม่ให้โมดูล DAV ของ Apache เข้ามาควบคุมเส้นทางแอปพลิเคชัน เปรียบเทียบโฮสต์เสมือนและบล็อกไดเร็กทอรีของคุณกับคู่มืออย่างเป็นทางการ แทนที่จะคัดลอกตัวอย่างทั้งหมดไปวางในเว็บไซต์ที่ปรับแต่งเอง

บน Debian หรือ Ubuntu ให้ตรวจสอบโมดูล rewrite ที่โหลดแล้วและไวยากรณ์การกำหนดค่า Apache:

sudo apachectl -M | grep rewrite
sudo apachectl -t

หากไม่มีการตั้งค่าการเขียนเส้นทางใหม่ ให้เปิดใช้งานด้วยคำสั่ง ` npm sudo a2enmod rewriterun config -g` จากนั้นตรวจสอบความถูกต้องของการกำหนดค่าอีกครั้ง และรีโหลด Apache เฉพาะหลังจากที่การตรวจสอบไวยากรณ์ผ่านแล้วเท่านั้น ตรวจสอบให้แน่ใจว่า<Directory>เส้นทางตรงกับรูทเว็บของ ownCloud จริง และไม่ได้ปิดใช้งานการแทนที่ในส่วนที่สูงกว่าของการกำหนดค่า หลีกเลี่ยงการแทนที่กฎการเขียนเส้นทางใหม่ที่ ownCloud สร้างขึ้น.htaccessด้วยกฎการเขียนเส้นทางใหม่ทั่วไปด้วยตนเอง เนื่องจากกฎที่กำหนดเองอาจทำให้เส้นทางของแอปพลิเคชันเสียหายหรือสูญหายระหว่างการอัปเกรด

ขั้นตอนที่ 4: ตรวจสอบพร็อกซีแบบย้อนกลับ กฎ WAF และส่วนหัวการตรวจสอบสิทธิ์

หากปลายทางทำงานได้เมื่อเรียกโดยตรงจากเว็บเซิร์ฟเวอร์ แต่ล้มเหลวเมื่อเรียกผ่าน URL สาธารณะ ให้ตรวจสอบพร็อกซีแบบย้อนกลับหรือตัวกระจายโหลด ตรวจสอบให้แน่ใจว่ามันรักษา/remote.php/dav/เส้นทางที่สมบูรณ์ ส่งต่อข้อมูล Host และ HTTPS ที่คาดหวัง และอนุญาตวิธีการ WebDAV เช่นPROPFIND, OPTIONS, PUT, และMOVEเมื่อจำเป็น พร็อกซีที่ตัดคำนำหน้าการติดตั้งหรือส่งคำขอ DAV ไปยังแบ็กเอนด์อื่นอาจทำให้ UI บนเว็บดูเหมือนทำงานได้ปกติในขณะที่การดำเนินการไฟล์ล้มเหลว

ตรวจสอบบันทึกพร็อกซี, Apache/Nginx และ ownCloud ในขณะที่คำขอไม่สำเร็จ ไฟร์วอลล์แอปพลิเคชันเว็บหรือกฎ ModSecurity อาจปฏิเสธวิธีการหรือเนื้อหาคำขอ ระบุรหัสกฎที่แน่นอนและสร้างข้อยกเว้นเฉพาะสำหรับเส้นทางหรือคำขอ ownCloud ที่ได้รับผลกระทบ จากนั้นทดสอบอีกครั้ง อย่าปิด WAF ทั่วโลกเพียงเพื่อล้างคำเตือน หากการตรวจสอบสิทธิ์ DAV ล้มเหลวเฉพาะเมื่ออยู่เบื้องหลังตัวจัดการ FastCGI/PHP ให้ตรวจสอบว่าส่วนหัวการอนุญาตถูกส่งไปยัง PHP หรือไม่ บันทึกการกำหนดค่า ownCloud ได้บันทึกปัญหาประเภทนี้ไว้

ขั้นตอนที่ 5: ตรวจสอบความถูกต้องของ TLS และการเปลี่ยนเส้นทาง

ไคลเอนต์ WebDAV อาศัย HTTPS ที่ถูกต้องเช่นเดียวกับเบราว์เซอร์ ตรวจสอบว่าใบรับรองนั้นถูกต้องสำหรับชื่อโฮสต์ มีใบรับรองระดับกลางที่จำเป็น และได้รับการเชื่อถือจากสภาพแวดล้อมเซิร์ฟเวอร์ที่เรียกใช้การตรวจสอบตนเองของ ownCloud เบราว์เซอร์อาจซ่อนหรือเชื่อถือปัญหาใบรับรองที่ cURL หรือ PHP รายงานแยกต่างหาก อย่าปิดใช้งานการตรวจสอบใบรับรองเพื่อแก้ไขปัญหา

ตรวจสอบการวนลูปการเปลี่ยนเส้นทาง การเปลี่ยนเส้นทาง HTTP เป็น HTTPS ที่ไม่คาดคิด หรือการเปลี่ยนเส้นทางจากเส้นทาง DAV ไปยังหน้าเข้าสู่ระบบหรือหน้าแรกทั่วไป การเปลี่ยนเส้นทางอาจเป็นเรื่องปกติสำหรับ URL พื้นฐานของเบราว์เซอร์ แต่คำขอ DAV ควรไปถึงปลายทางของแอปพลิเคชันโดยที่วิธีการและส่วนหัว Authorization ยังคงอยู่ หากพร็อกซีทำการยุติ TLS ให้ยืนยันว่า ownCloud ได้รับโปรโตคอลและโฮสต์ที่ส่งต่ออย่างถูกต้องตามการกำหนดค่าที่ระบุไว้ในเอกสารของพร็อกซี

ภาพแสดงผลลัพธ์จากเทอร์มินัลแบบแผนผัง แสดงการค้นหาชื่อโฮสต์และการตรวจสอบใบรับรอง TLS ที่สำเร็จ
ตัวอย่างการตรวจสอบ DNS และใบรับรองจากเซิร์ฟเวอร์ที่ต้องเชื่อมต่อกลับไปยังชื่อโฮสต์สาธารณะ

ตรวจสอบการแก้ไขจากทั้งสองฝั่ง

หลังจากทำการเปลี่ยนแปลงที่ต้องการแล้ว ให้ทำการตรวจสอบซ้ำอีกครั้ง แทนที่จะเปลี่ยนแปลงหลายเลเยอร์พร้อมกัน:

  • จากฝั่งไคลเอ็นต์ ให้ยืนยันตัวตนกับ URL ของ DAV ที่ระบุไว้ และตรวจสอบว่าการตอบกลับเป็นไปตามการตอบสนองของ WebDAV ที่คาดหวัง โดยทั่วไปจะเป็นการตอบสนอง207 Multi-Statusสำหรับ PROPFIND
  • จากโฮสต์ ownCloud ให้ตรวจสอบว่าชื่อโฮสต์สาธารณะสามารถแก้ไขได้ และ HTTPS เข้าถึงอินสแตนซ์ได้โดยไม่มีข้อผิดพลาดในการตรวจสอบ TLS
  • ตรวจสอบภาพรวมผู้ดูแลระบบ ownCloud อีกครั้ง และตรวจสอบบันทึกเพื่อหาข้อผิดพลาด DAV, พร็อกซี หรือการตรวจสอบสิทธิ์ใหม่
  • ทดสอบการอัปโหลด เปลี่ยนชื่อ และดาวน์โหลดไฟล์ขนาดเล็กผ่านทางเว็บอินเทอร์เฟซหรือโปรแกรมซิงค์ข้อมูลที่รองรับ

หากการร้องขอจากไคลเอ็นต์ทำงานได้ แต่คำเตือนยังคงอยู่ ให้มุ่งเน้นไปที่ DNS ของเซิร์ฟเวอร์เอง การกำหนดเส้นทาง ความน่าเชื่อถือของใบรับรอง และ URL สาธารณะที่กำหนดค่าไว้ หากทั้งการตรวจสอบตัวเองและไคลเอ็นต์ล้มเหลว ให้มุ่งเน้นไปที่เส้นทางปลายทาง กฎการเขียนใหม่ การกำหนดเส้นทางพร็อกซี วิธีการร้องขอ และการส่งต่อการตรวจสอบสิทธิ์ก่อน เมื่อเซิร์ฟเวอร์ได้รับการจัดการโดยผู้ให้บริการโฮสติ้ง ให้ส่งข้อมูลการประทับเวลา สถานะ HTTP ที่กรองแล้ว เส้นทางที่ร้องขอ และรายการบันทึกที่ตรงกันไปยังฝ่ายสนับสนุน อย่าส่งรหัสผ่านหรือการกำหนดค่าที่มีความลับ

สำหรับคำแนะนำเฉพาะเวอร์ชัน โปรดเปรียบเทียบการติดตั้งของคุณกับคู่มือการติดตั้ง Apache ของ ownCloud Server 10.15 , เอกสารประกอบการเข้าถึง WebDAV แบบคลาสสิกของ ownCloudและหมายเหตุการกำหนดค่า ownCloud เกี่ยวกับการตรวจสอบสิทธิ์ WebDAVปฏิบัติตามคู่มือสำหรับเวอร์ชันที่ติดตั้งและประเภทการติดตั้งของคุณ

ฝากความเห็น

10 เครื่องมือ Ping Sweep ที่ดีที่สุดสำหรับการค้นหาอุปกรณ์ในเครือข่ายของคุณ

10 เครื่องมือ Ping Sweep ที่ดีที่สุดสำหรับการค้นหาอุปกรณ์ในเครือข่ายของคุณ

เปรียบเทียบเครื่องมือสแกน Ping 10 ตัว สำหรับการค้นหาเครือข่าย LAN อย่างรวดเร็ว การสแกนข้ามแพลตฟอร์ม และการจัดการที่อยู่ IP เรียนรู้ว่าการสแกน Ping สามารถบอกอะไรคุณได้บ้าง และบอกอะไรไม่ได้บ้าง

6 เครื่องมือบริหารจัดการเครือข่ายที่ดีที่สุดสำหรับการติดตามประสิทธิภาพ

6 เครื่องมือบริหารจัดการเครือข่ายที่ดีที่สุดสำหรับการติดตามประสิทธิภาพ

เปรียบเทียบเครื่องมือบริหารจัดการเครือข่าย 6 ชนิดสำหรับการตรวจสอบประสิทธิภาพ รวมถึงการครอบคลุมของ SNMP, การทำแผนที่, การแจ้งเตือน, รูปแบบการใช้งาน และข้อดีข้อเสียด้านต้นทุน

โปรแกรมวิเคราะห์ Wi-Fi ที่ดีที่สุดสำหรับ Windows, iOS และ Android

โปรแกรมวิเคราะห์ Wi-Fi ที่ดีที่สุดสำหรับ Windows, iOS และ Android

เปรียบเทียบแอปวิเคราะห์ Wi-Fi สำหรับ Windows, iPhone และ Android ซึ่งรวมถึงเครื่องมือสำหรับตรวจสอบความแออัดของช่องสัญญาณ การครอบคลุมสัญญาณ แผนที่ความร้อน และการแก้ไขปัญหาเครือข่าย

Ping Monitor: 7 เครื่องมือโอเพนซอร์สฟรีสำหรับตรวจสอบความพร้อมใช้งานของเครือข่าย

Ping Monitor: 7 เครื่องมือโอเพนซอร์สฟรีสำหรับตรวจสอบความพร้อมใช้งานของเครือข่าย

เปรียบเทียบโปรแกรมตรวจสอบค่า Ping แบบโอเพนซอร์สฟรี 7 ตัว ตั้งแต่ชุดโปรแกรมเครือข่ายแบบครบวงจรไปจนถึงโปรแกรมตรวจสอบความหน่วงแฝงโดยเฉพาะ และเลือกโปรแกรมที่เหมาะสมที่สุดตามความพร้อมใช้งาน การสูญเสียแพ็กเก็ต และประวัติการใช้งาน

QoS ในระบบเครือข่าย: คุณภาพของบริการ (Quality of Service) ทำอะไร และทำงานอย่างไร

QoS ในระบบเครือข่าย: คุณภาพของบริการ (Quality of Service) ทำอะไร และทำงานอย่างไร

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

7 เครื่องมือจัดการที่อยู่ IP ที่ดีที่สุดสำหรับทีมเครือข่าย

7 เครื่องมือจัดการที่อยู่ IP ที่ดีที่สุดสำหรับทีมเครือข่าย

เปรียบเทียบเครื่องมือจัดการที่อยู่ IP เจ็ดแบบ สำหรับการค้นหาซับเน็ต การประสานงาน DNS และ DHCP การสำรวจเครือข่าย และ IPAM แบบโอเพนซอร์ส

แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบเครือข่าย: สิ่งที่ควรติดตามและเครื่องมือที่ควรใช้งาน

แนวทางปฏิบัติที่ดีที่สุดสำหรับการตรวจสอบเครือข่าย: สิ่งที่ควรติดตามและเครื่องมือที่ควรใช้งาน

สร้างระบบตรวจสอบเครือข่ายที่ใช้งานได้จริง พร้อมการครอบคลุมอุปกรณ์ที่ชัดเจน ตัวชี้วัดประสิทธิภาพที่เป็นประโยชน์ การแจ้งเตือนที่นำไปปฏิบัติได้จริง และการเปรียบเทียบระหว่าง SolarWinds NPM, PRTG และ OpManager

10 เครื่องมือสแกนเครือข่ายที่ดีที่สุดสำหรับการค้นหาอุปกรณ์และที่อยู่ IP

10 เครื่องมือสแกนเครือข่ายที่ดีที่สุดสำหรับการค้นหาอุปกรณ์และที่อยู่ IP

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

วิธีใช้ Nmap สำหรับ Traceroute และอ่านเส้นทางเครือข่าย

วิธีใช้ Nmap สำหรับ Traceroute และอ่านเส้นทางเครือข่าย

ใช้ตัวเลือก --traceroute ของ Nmap เพื่อแมปฮอปไปยังโฮสต์ที่ได้รับอนุญาต ทำความเข้าใจเอาต์พุตของฮอปและ RTT และแก้ไขปัญหาการตอบสนองที่หายไปโดยไม่ต้องสแกนมากเกินไป

10 เครื่องมือสแกนและวิเคราะห์ไร้สายที่ดีที่สุดสำหรับ Windows, iOS และ Android

10 เครื่องมือสแกนและวิเคราะห์ไร้สายที่ดีที่สุดสำหรับ Windows, iOS และ Android

เปรียบเทียบเครื่องมือสแกนและวิเคราะห์เครือข่ายไร้สาย 10 รายการสำหรับ Windows, iOS และ Android พร้อมคำอธิบายที่ชัดเจนเกี่ยวกับช่องสัญญาณ Wi-Fi แผนที่ครอบคลุม การตรวจสอบ LAN และข้อจำกัดของแต่ละแพลตฟอร์ม