ทำไมที่อยู่ทันเนล VPN ของคุณจึงไม่เปิดพอร์ตขาเข้า
ที่อยู่ทันเนลระบุตัวไคลเอนต์ของคุณต่อเพียร์ที่สามารถกำหนดเส้นทางมาถึงได้ และไม่เคยสร้างตัวรับฟัง ตรวจสอบการผูก ที่อยู่ย้อนกลับ แล้วจึงตรวจสอบนโยบาย
เชื่อมต่อกับ VPN ของสำนักงาน เริ่มบริการเล็กๆ บนพอร์ต 8443 ส่งที่อยู่ทันเนลให้เพื่อนร่วมงาน และดูการเชื่อมต่อล้มเหลวในขณะที่ไคลเอนต์ยังรายงานว่าเชื่อมต่ออยู่ ไม่มีอะไรเสียหายในทันเนล ที่อยู่ถูกแจกจ่าย เซสชันทำงานอยู่ และแพ็กเก็ตที่จะนำคำตอบกลับไปก็ไม่เคยถูกอนุญาตให้ผ่าน ทำการตรวจสอบสามข้อด้านล่างตามลำดับและหยุดที่ข้อที่ล้มเหลว เพราะแต่ละข้อมีวิธีแก้ต่างกันและมีเพียงข้อเดียวที่เกี่ยวกับ VPN
เริ่มจากตำแหน่งที่ซ็อกเก็ตผูกอยู่จริง
ก่อนที่สิ่งใดจะถูกกำหนดเส้นทาง ต้องมีบางอย่างรับฟังอยู่บนที่อยู่ที่ผู้เรียกเข้าถึงได้ เซิร์ฟเวอร์สำหรับพัฒนามักเป็นผู้กระทำผิดประจำ เพราะหลายตัวผูกกับ loopback โดยค่าเริ่มต้นและรับเฉพาะการเชื่อมต่อที่มาจากเครื่องเดียวกัน ที่อยู่ทันเนลไม่ได้เปลี่ยนการผูกนั้น และระบบปฏิบัติการจะปฏิเสธการเชื่อมต่อก่อนที่ VPN จะเข้ามาเกี่ยวข้องมากนัก
ss -ltnp | grep 8443
netstat -ano | findstr 8443อ่านคอลัมน์ที่อยู่ภายในแทนสถานะ 127.0.0.1:8443 หมายถึง loopback เท่านั้น และวิธีแก้คือผูกกับ 0.0.0.0 หรือกับที่อยู่ของทันเนลเอง 0.0.0.0:8443 รับบนทุกอินเทอร์เฟซ ซึ่งกว้างกว่าที่คนส่วนใหญ่ตั้งใจเมื่อเครื่องมีที่อยู่สาธารณะด้วย ส่วน 10.64.7.15:8443 คือเวอร์ชันแคบที่รับฟังเฉพาะที่ที่เพื่อนร่วมงานเข้าถึงได้ สังเกตชื่อโปรเซสในผลลัพธ์เดียวกันด้วย เพราะอินสแตนซ์ที่ตกค้างจากการทดสอบครั้งก่อนเป็นสาเหตุปกติที่พอร์ตดูเหมือนเปิดอยู่และตอบกลับด้วยเนื้อหาผิด
จากนั้นถามว่ามีอะไรกำหนดเส้นทางไปยังที่อยู่นั้นได้หรือไม่
ที่อยู่ทันเนลมีความหมายเฉพาะกับเพียร์ที่ตั้งค่าให้ส่งคำนำหน้านั้นเข้าไปในทันเนล เครื่องของเพื่อนร่วมงานมีตารางของตัวเอง และถ้าไม่มีเส้นทางไปยังซับเน็ตของทันเนล แพ็กเก็ตจะไปที่เกตเวย์เริ่มต้นและตายในที่ที่ไม่มีใครรู้ว่าที่อยู่นั้นมีอยู่ นี่เป็นคำถามเรื่องการกำหนดเส้นทางฝั่งผู้เรียก ไม่ใช่สิทธิ์ฝั่งคุณ
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
เซิร์ฟเวอร์ระหว่างไคลเอนต์สองตัวก็สำคัญพอๆ กัน ในการออกแบบการเข้าถึงระยะไกลทั่วไป ไคลเอนต์แต่ละตัวเปิดการเชื่อมต่อขาออกไปยังเกตเวย์ และเกตเวย์เก็บสถานะของโฟลว์เหล่านั้นไว้ คำตอบจึงกลับมาทางเส้นทางที่มันรู้อยู่แล้ว การเชื่อมต่อจากไคลเอนต์หนึ่งไปยังอีกตัวหนึ่งเป็นโฟลว์ใหม่ที่เกตเวย์ต้องยอมรับและส่งต่อ และการติดตั้งจำนวนมากปิดสิ่งนั้นโดยเจตนาเพื่อแยกไคลเอนต์ออกจากกัน บริการ VPN สำหรับผู้บริโภคมักแยกโดยค่าเริ่มต้น ส่วนเกตเวย์องค์กรบางครั้งอนุญาตตามกลุ่ม
ตรวจทิศทางก่อนเปลี่ยนแปลงสิ่งใดบนโฮสต์ ถ้าที่อยู่ทันเนลตอบจากเกตเวย์เองแต่ไม่ตอบจากเพียร์ ความต่างคือการตั้งค่าไคลเอนต์ถึงไคลเอนต์ของเกตเวย์ และการแก้ไฟร์วอลล์ภายในไม่สามารถแทนที่ได้
สุดท้าย หานโยบายที่อนุญาตโฟลว์
มีนโยบายสามชั้นอยู่ระหว่างแพ็กเก็ตที่ถูกกำหนดเส้นทางกับบริการที่ตอบกลับ ได้แก่ การตัดสินใจส่งต่อของเซิร์ฟเวอร์ VPN ไฟร์วอลล์ของโฮสต์ และกลุ่มความปลอดภัยบนคลาวด์ใดๆ ที่อยู่หน้าเครื่อง ทั้งสามต้องสอดคล้องกัน และล้มเหลวคนละแบบ ด้วยเหตุนี้อาการในตารางด้านบนจึงมีประโยชน์กว่าข้อความข้อผิดพลาดในเบราว์เซอร์
ไฟร์วอลล์ของโฮสต์คือชั้นที่คนลืมหลังการผูกสำเร็จ เพราะกฎที่อนุญาตพอร์ตบนอินเทอร์เฟซ LAN ไม่ได้อนุญาตบนอินเทอร์เฟซของทันเนลโดยอัตโนมัติ กฎที่จำกัดตามอินเทอร์เฟซเป็นการออกแบบที่ถูกต้องและเป็นสาเหตุปกติของบริการที่ทำงานจากสำนักงานแต่ไม่ทำงานจากบ้าน อ่านขอบเขตของกฎ ไม่ใช่หมายเลขพอร์ต
การกรองตามสถานะอธิบายกรณีตรงกันข้าม การเชื่อมต่อขาออกจากแล็ปท็อปของคุณสร้างสถานะ และคำตอบจะถูกอนุญาตโดยไม่ต้องมีกฎขาเข้า การเชื่อมต่อของเพื่อนร่วมงานเป็นโฟลว์ใหม่ทั้งหมดที่ไม่มีสถานะรองรับ จึงต้องมีสิทธิ์อย่างชัดเจน ความไม่สมดุลนี้คือเหตุผลทั้งหมดที่เซสชันเบราว์เซอร์ซึ่งทำงานบนเครื่องของคุณเองไม่บอกอะไรเลยว่าบริการเข้าถึงได้จากภายนอกหรือไม่
เมื่อการตรวจสอบข้อหนึ่งล้มเหลว ให้เปลี่ยนการออกแบบไม่ใช่ทันเนล
หากข้อกำหนดคือให้เพื่อนร่วมงานเปิดบริการภายในของคุณ คำตอบที่ซื่อตรงมักเป็นกลไกที่สร้างมาเพื่อการเข้าถึงขาเข้า ทันเนล SSH แบบย้อนกลับ เป็นสิ่งที่เล็กที่สุด เครื่องของคุณเชื่อมต่อขาออกไปยังโฮสต์ที่เพื่อนร่วมงานเข้าถึงได้อยู่แล้ว และตัวรับฟังอยู่บนโฮสต์นั้น
ssh -N -R 8443:127.0.0.1:8443 [email protected]รีเลย์ต้องมี GatewayPorts clientspecified ในการตั้งค่าเซิร์ฟเวอร์ SSH มิฉะนั้นตัวรับฟังที่ส่งต่อจะผูกกับ loopback บนรีเลย์และเพื่อนร่วมงานจะพบการปฏิเสธแบบเดิม สำหรับสิ่งใดที่อยู่ได้นานกว่าหนึ่งบ่าย ตัวกระจายโหลดหรือ ingress ที่มีการตรวจสุขภาพและใบรับรองสำหรับชื่อที่เผยแพร่เป็นเครื่องมือที่ดีกว่า และทันเนลระหว่างไซต์ที่มีเส้นทางสำหรับทั้งสองซับเน็ตคือคำตอบที่ถูกต้องเมื่อสองเครือข่ายจำเป็นต้องคุยกันจริงๆ
การออกแบบแต่ละแบบทำให้การเปิดเผยชัดเจน และนั่นคือประเด็น VPN เคลื่อนย้ายแพ็กเก็ตระหว่างเครือข่ายที่คุณได้รับอนุญาตให้ใช้อยู่แล้ว มันไม่ได้เผยแพร่บริการและไม่ได้เปลี่ยนแล็ปท็อปให้เป็นโฮสต์ที่หันสู่อินเทอร์เน็ต ภารกิจคือตัดสินใจว่าจะเปลี่ยนชั้นใดในสามชั้น และทันเนลแทบไม่เคยเป็นหนึ่งในนั้น