เมื่อผมไป http://sub.example.com ในเบราว์เซอร์ของฉัน ฉันได้รับ "การเชื่อมต่อถูกปฏิเสธ" ข้อความหรือ "ใบรับรองไม่ถูกต้อง" เกิดข้อผิดพลาด แต่ฉันไม่ต้องการเชื่อมต่อผ่าน https
เท่าที่ฉันรู้:
sub.example.comsub.example.com ชี้ไปที่ที่อยู่ IP ที่ถูกต้องของเว็บเซิร์ฟเวอร์ฉันจะดีบักได้อย่างไรและปัญหาคืออะไร
สิ่งแรกที่ควรทราบคือเว็บเบราว์เซอร์สมัยใหม่อาจไม่ใช่เครื่องมือที่ดีที่สุดสำหรับการดีบักปัญหาเช่นนี้ เบราว์เซอร์อาจเป็นสาเหตุของสิ่งเหล่านี้ เนื่องจากเซิร์ฟเวอร์สามารถกำหนดค่าได้อย่างถูกต้องอย่างสมบูรณ์ และปัญหาอาจเป็นฝั่งไคลเอ็นต์ 100%
เนื้อหา:
ขด และเบราว์เซอร์ที่ไม่ระบุตัวตน/ไม่ระบุตัวตน)ขด ทำได้ แต่หน้าต่างเบราว์เซอร์ส่วนตัวไม่แสดงเนื้อหาที่ถูกต้องพยายามอย่าทดสอบกับ FQDN เท่านั้น http://sub.example.com แต่ใช้ URL ที่สมบูรณ์กว่านี้ เช่น http://sub.example.com/some-page.html. เมื่อคุณรู้ว่าคุณอยู่เบื้องหลังพร็อกซี การเพิ่มพารามิเตอร์มักจะข้ามเนื้อหาที่แคชไว้ เช่น เพิ่มและเพิ่มจำนวนตัวนับ เช่น http://sub.example.com/some-page.html?test=3
ทดสอบจากหน้าต่างเบราว์เซอร์ "ส่วนตัว/ไม่ระบุตัวตน"
ซึ่งช่วยลดโอกาสที่จะได้ข้อสรุปที่ไม่ถูกต้องตามวัตถุที่แคชไว้
ทดสอบจากบรรทัดคำสั่ง (บนเซิร์ฟเวอร์ทดสอบ) ด้วยตัวอย่าง ขด -vv http://sub.example.com/some-page.html หรือใช้ เทลเน็ต และเลียนแบบคำขอเว็บด้วย
เทลเน็ต sub.example.com 80
รับ /some-page.html HTTP/1.1
โฮสต์: sub.example.com
สิ่งที่ต้องค้นหาใน ขด เอาต์พุต:
การตั้งค่าพร็อกซีเป็นสัญญาณอันตรายและเป็นอุปสรรคอย่างแท้จริงเมื่อทำการดีบั๊กปัญหาเซิร์ฟเวอร์ พร็อกซีเซิร์ฟเวอร์สามารถแคช (บันทึก DNS และเนื้อหาเว็บ) จำกัดการเข้าถึงของคุณและแม้แต่แทนที่ใบรับรอง TLS
ขด -vv http://sub.example.com/some-page.html
* ใช้ตัวแปรพร็อกซี env no_proxy == 'localhost,127.0.0.1,.corp.example.net'
* ใช้ตัวแปรพร็อกซี env http_proxy == 'http://[ผู้ใช้]:[pass]@proxy.corp.example.net:8080/'
* ลอง 10.2.0.80:8080...
^^^ อันตราย - พร็อกซีเซิร์ฟเวอร์
ทดสอบจาก (ทดสอบ) ระบบที่ไม่ใช้พร็อกซีเซิร์ฟเวอร์ หากคุณต้องการทดสอบการกำหนดค่าของเว็บเซิร์ฟเวอร์อินเทอร์เน็ตอย่างเหมาะสม ฉันมักจะไม่มีระบบทดสอบที่จะรองรับเบราว์เซอร์เต็มรูปแบบ แต่ฉันสามารถจัดการระบบที่จะเรียกใช้คำสั่ง curl จากบรรทัดคำสั่งได้
ขด -vv http://sub.example.com/some-page.html
* กำลังจะเชื่อมต่อ() กับพอร์ต sub.example.com 80 (#0)
* ลอง 192.168.2.119...
* เชื่อมต่อกับ sub.example.com (192.168.2.119) พอร์ต 80 (#0)
^^^ ตรวจสอบว่าที่อยู่ IP นี้ถูกต้องหรือไม่
ของเว็บเซิร์ฟเวอร์ของคุณ?
> รับ /some-page.html HTTP/1.1
> User-Agent: curl/7.29.0
> โฮสต์: sub.example.com
> ยอมรับ: */*
คุณสังเกตว่าการเชื่อมต่อได้รับการสร้างสำเร็จไปยังที่อยู่ IP และพอร์ตที่ถูกต้องของเว็บเซิร์ฟเวอร์ เดอะ > เครื่องหมายนำหน้าส่วนหัวคำขอที่สร้างโดย curl
ส่วนหัวการตอบสนองของเซิร์ฟเวอร์ถูกทำเครื่องหมายด้วย a < เครื่องหมาย และหลังจากบรรทัดว่าง เนื้อหาการตอบสนองจะถูกส่งโดยเซิร์ฟเวอร์:
< พบ HTTP/1.1 302
| ^^^ รหัสตอบกลับ HTTP STATUS ของเซิร์ฟเวอร์
`^^ เวอร์ชันโปรโตคอล HTTP
< วันที่: จันทร์ที่ 07 กุมภาพันธ์ 2022 13:58:11 GMT
< เซิร์ฟเวอร์: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< ที่ตั้ง: https://sub.example.com/some-page.html
< ความยาวเนื้อหา: 216
< ประเภทเนื้อหา: text/html; ชุดอักขระ=iso-8859-1
<
<!DOCTYPE HTML สาธารณะ "-//IETF//DTD HTML 2.0//EN">
...
หลังจากส่วนหัวของโปรโตคอลแรก HTTP/1.1 มา รหัสสถานะ HTTP เซิร์ฟเวอร์สร้างขึ้น มี ก 2xx การตอบสนองหมายถึงรูปแบบหนึ่งของความสำเร็จ 3xx คำตอบคือการเปลี่ยนเส้นทาง (ดูที่นี่) 4xx และ 5xx เป็นข้อผิดพลาด
ของส่วนหัวอื่น ๆ ที่เซิร์ฟเวอร์ส่ง ที่ตั้ง: ในตัวอย่างนี้ระบุเป้าหมายของการตอบสนองการเปลี่ยนเส้นทาง
บทสรุป: เว็บเซิร์ฟเวอร์ได้รับการกำหนดค่าอย่างถูกต้องและปัญหาเกี่ยวข้องกับเบราว์เซอร์
เป็นไปได้มากที่สุด สาเหตุ: อาจมีการกำหนดค่าการเปลี่ยนเส้นทางอย่างถาวรก่อนที่การกำหนดค่าเว็บเซิร์ฟเวอร์จะเปลี่ยนไป และ การเปลี่ยนเส้นทางถาวร (301) ถูกแคชโดยเบราว์เซอร์. ที่พบได้บ่อยคือแคชเปลี่ยนเส้นทางเสียหรือแคชเปลี่ยนเส้นทางไปยัง https และไม่มีใบรับรองและไซต์ https สำหรับ sub.example.com ได้รับการกำหนดค่ายัง
ความละเอียด 1: ล้างแคชของเบราว์เซอร์และไซต์ควรโหลดตามที่คาดไว้
ความละเอียด 2: รับใบรับรอง SSL สำหรับ sub.example.com และเปิดใช้งาน TLS
สาเหตุที่ 2: ไม่ใช่สาเหตุหลักเดียวกัน แต่สาเหตุและผลกระทบที่คล้ายกันมีผลกับการเปลี่ยนเส้นทางแคชไปยัง https, ก HTTP การรักษาความปลอดภัยการขนส่งที่เข้มงวด (HSTS) นโยบายที่กำหนดโดย ตัวอย่าง.คอม โดเมนยังใช้ได้กับโดเมนย่อย (ใหม่) ทั้งหมดของ example.com เบราว์เซอร์ที่ทันสมัยพอสมควรจะจัดเก็บและปฏิบัติตามนโยบาย HSTS และจะปฏิเสธการเชื่อมต่อผ่าน http ธรรมดาไปยังพอร์ต 80 และจะเขียนใหม่อย่างเงียบๆ http://sub.example.com URL ไปที่ https://sub.example.com และพยายามเชื่อมต่อกับพอร์ต 443 ด้วย TLS
ปณิธาน: รับใบรับรอง SSL สำหรับ sub.example.com และเปิดใช้งาน TLS
การล้างแคชของเบราว์เซอร์ HSTS สามารถทำงานได้ชั่วคราว แต่จะได้ผลก็ต่อเมื่อคุณลบนโยบาย HSTS ของโดเมนย่อยที่รวมออกจาก example.com ซึ่งไม่แนะนำ
ขด ทำได้ แต่หน้าต่างเบราว์เซอร์ส่วนตัวไม่แสดงเนื้อหาที่ถูกต้องบทสรุป: เว็บเซิร์ฟเวอร์มีการกำหนดค่าอย่างถูกต้อง และปัญหาเกี่ยวข้องกับเบราว์เซอร์หรือไคลเอนต์
สาเหตุที่ 1: ไม่ใช่สาเหตุเดียวกันทั้งหมด แต่มีเหตุและผลที่คล้ายกันอย่างมีประสิทธิภาพกับแคช HTTP การรักษาความปลอดภัยการขนส่งที่เข้มงวด (HSTS) นโยบายคือ โดเมนในรายการโหลดล่วงหน้า HSTS แต่ในกรณีที่ไม่ควรปฏิบัติตามนโยบาย HSTS ที่แคชไว้ในหน้าต่าง "ส่วนตัว/ไม่ระบุตัวตน" ควรใช้รายการโหลดล่วงหน้า HSTS เสมอ แม้ในหน้าต่างส่วนตัว/ไม่ระบุตัวตน
ดูคำถาม & คำตอบนี้สำหรับภาพรวมเกี่ยวกับวิธีการตรวจสอบว่าโดเมนหรือ TLD ของคุณอยู่ในรายการโหลดล่วงหน้าของ HSTS หรือไม่:
รายการโดเมนระดับบนสุด (TLD) ที่ต้องใช้การเชื่อมต่อ HTTPS เช่น .dev
ปณิธาน: รับใบรับรอง SSL สำหรับ sub.example.com และเปิดใช้งาน TLS
สาเหตุที่ 2: แม้ว่าระเบียน DNS จะได้รับการกำหนดค่าอย่างถูกต้อง แต่ตัวแก้ไขไคลเอ็นต์ ซึ่งเป็นเดสก์ท็อปที่เบราว์เซอร์ของคุณเรียกใช้ อาจชี้ไปที่ที่อยู่ IP อื่น ตรวจสอบกับตัวอย่าง nslookup และ ขุด ไคลเอนต์เนมเซิร์ฟเวอร์แก้ไขอะไรและอย่าลืมว่า ไฟล์โฮสต์ รายการสำหรับ sub.example.com จะแทนที่ DNS
ปณิธาน: ลบ ไฟล์โฮสต์ รายการสำหรับ sub.example.com หรือตรวจสอบความคลาดเคลื่อนของ DNS เพิ่มเติม
บทสรุป: ปัญหาคือฝั่งเซิร์ฟเวอร์ ไม่ใช่ฝั่งไคลเอ็นต์
ไม่มีการตอบสนอง
อ้างถึง ข้อความ 'การเชื่อมต่อถูกปฏิเสธ' เกิดจากอะไร เมื่อปรากฏว่าเว็บเซิร์ฟเวอร์ไม่ตอบสนองเลยที่พอร์ต 80
การตอบสนองการเปลี่ยนเส้นทาง
เมื่อเว็บเซิร์ฟเวอร์ตอบสนอง ให้ดูการตอบสนองนั้นอย่างใกล้ชิด:
< พบ HTTP/1.1 302
< วันที่: จันทร์ที่ 07 กุมภาพันธ์ 2022 13:58:11 GMT
< เซิร์ฟเวอร์: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< ที่ตั้ง: https://sub.example.com/some-page.html
< ความยาวเนื้อหา: 216
< ประเภทเนื้อหา: text/html; ชุดอักขระ=iso-8859-1
<
<!DOCTYPE HTML สาธารณะ "-//IETF//DTD HTML 2.0//EN">
...
นี่เป็นการตอบสนองที่ค่อนข้างปกติสำหรับเว็บเซิร์ฟเวอร์ที่กำหนดค่าให้เปลี่ยนเส้นทาง HTTP ธรรมดาเป็น HTTPS
เดอะ 302 พบ รหัสสถานะในส่วนหัวแรกบ่งบอกถึงการเปลี่ยนเส้นทางชั่วคราว สำหรับการเปลี่ยนเส้นทางถาวรที่จะเป็น 301 ย้ายอย่างถาวร ส่วนหัวสถานะ http
เดอะ ที่ตั้ง: ส่วนหัวแสดงตำแหน่งที่ไคลเอนต์ถูกเปลี่ยนเส้นทางไป
สาเหตุ: เมื่อไม่ได้กำหนดไว้ในการกำหนดค่าเว็บเซิร์ฟเวอร์ เป็นเรื่องปกติมากสำหรับเว็บแอปพลิเคชันในการสร้างการเปลี่ยนเส้นทาง เป็น https หรือโดเมนอื่นทั้งหมด
บนเว็บเซิร์ฟเวอร์ Apache (ที่อนุญาต) .htaccess ไฟล์ยังสามารถเป็นแหล่งที่มาของการเปลี่ยนเส้นทาง
ปณิธาน: ปรับหรือลบการเปลี่ยนเส้นทาง หรือตรวจสอบให้แน่ใจว่าการเปลี่ยนเส้นทางนั้นถูกต้องและมีบางอย่างตอบสนองที่เป้าหมายของการเปลี่ยนเส้นทาง
บ่อยครั้ง: รับใบรับรอง SSL และเปิดใช้งาน TLS!
สาเหตุ: บ่อยครั้งที่เป้าหมายของการเปลี่ยนเส้นทางเสีย ตรวจดูว่ามีการพิมพ์ผิดเล็กน้อยหรือไม่ ฉันเห็นว่าหายไป /' เพื่อเปลี่ยนเส้นทางไปยัง sub.example.comsome-page.html และพารามิเตอร์ที่ใช้อย่างไม่ถูกต้องเปลี่ยนเส้นทางไปที่ http://some-page.html, หรือ http://www.example.com/http://sub.example.com/some-page.html และคล้ายกัน
ทดสอบลูปด้วยการร้องขอไปยัง ที่ตั้ง: การเปลี่ยนเส้นทางหลายระดับมักระบุถึงการกำหนดค่าที่เสียหายและลบการวนซ้ำ
เนื้อหาจากไซต์อื่น
เมื่อคุณเห็นเนื้อหาจากไซต์อื่นที่คุณโฮสต์และไม่ใช่เนื้อหานั้น sub.example.com โปรดทราบว่าเว็บเซิร์ฟเวอร์ส่วนใหญ่จะแสดงเนื้อหาจากไซต์เริ่มต้นเมื่อไม่สามารถจับคู่ชื่อโฮสต์กับไซต์เฉพาะได้
ปณิธาน: ตรวจสอบการกำหนดค่าของคุณอีกครั้งว่าพิมพ์ผิดหรือไม่ และยืนยันว่าเว็บเซิร์ฟเวอร์ได้เริ่มต้นใหม่ด้วยการกำหนดค่าที่อัปเดตแล้ว
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
