VPN เชิงพาณิชย์บล็อกพอร์ต 5432 หรือไม่? เปรียบเทียบทางเลือกของคุณ

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

การทดสอบห้านาทีที่แยกการกรองออกจากทุกอย่างอื่น

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

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

ผลลัพธ์สี่แบบครอบคลุมเกือบทุกกรณี ถ้า 443 ใช้งานได้และ 5432 ล้มเหลวเฉพาะตอนเปิดอุโมงค์ คุณกำลังเห็นการกรองพอร์ตบนเส้นทางออก ถ้าทั้งคู่ล้มเหลวตอนเปิดอุโมงค์และทั้งคู่ใช้งานได้เมื่อปิด ปัญหาอยู่ที่การกำหนดเส้นทางหรือ DNS ไม่ใช่นโยบายพอร์ต ถ้าทั้งสองพอร์ตเชื่อมต่อได้แต่แอปพลิเคชันยังล้มเหลว ความผิดอยู่ที่การรับรองความถูกต้องหรือ TLS ไม่ใช่การเข้าถึง และถ้าล้มเหลวเพียงตำแหน่งเซิร์ฟเวอร์เดียวของผู้ให้บริการ นั่นคือนโยบายรายเซิร์ฟเวอร์ ดังนั้นลองตำแหน่งอื่นก่อนแตะการกำหนดค่าใด ๆ

ทางเลือกที่หนึ่ง: อุโมงค์แยกสำหรับซับเน็ตฐานข้อมูล

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

มันหยุดทำงานในทันทีที่ฐานข้อมูลอยู่ภายในเครือข่ายที่ VPN ควรเข้าถึง ดังนั้นตรวจสอบเรื่องนี้ก่อนตัดสินใจ

ทางเลือกที่สอง: ปลายทางของคุณเอง ทางออกของคุณเอง

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

เปรียบเทียบทั้งสองด้านความเสถียรของที่อยู่ต้นทาง ใครสามารถอ่านทราฟฟิกของคุณ และเกิดอะไรขึ้นในวันที่ผู้ให้บริการของปลายทางเปลี่ยนการกรองของตนเอง

ทางเลือกที่สาม: เอาแล็ปท็อปออกจากเส้นทาง

งาน CI คอนเทนเนอร์ที่ตั้งเวลาไว้ หรือโฮสต์ป้อมปราการภายในเครือข่ายที่ได้รับอนุญาตไม่ขึ้นกับสถานะอุโมงค์ของมนุษย์ เข้าถึงฐานข้อมูลผ่านอุโมงค์ SSH จากโฮสต์ที่ได้รับอนุญาตอยู่แล้ว และแล็ปท็อปจะไม่พูดคุยกับพอร์ตโดยตรงเลย นี่คือทางเลือกที่ขยายได้เมื่อหลายคนเจอข้อจำกัดเดียวกัน และยังเป็นทางเลือกที่กำจัดปัญหาแทนที่จะอ้อมมัน

ต้องทำงานล่วงหน้ามากกว่ากฎอุโมงค์แยก และไม่ช่วยคนเดียวที่ต้องการเซสชันโต้ตอบตอนนี้

ทำไมการใส่ที่อยู่ของผู้ให้บริการในรายการที่อนุญาตจึงเป็นการเปรียบเทียบที่ผิด

การเพิ่มที่อยู่ขาออกของผู้ให้บริการในรายการที่อนุญาตของฐานข้อมูลได้ผล และยังให้การเข้าถึงแก่สมาชิกรายอื่นทุกคนที่แชร์ที่อยู่นั้นในขณะนั้น สำหรับรีพลิกาอ่านอย่างเดียวหลังบัญชีแอปพลิเคชันที่ให้สิทธิ์อย่างแคบ การเปิดเผยอาจยอมรับได้หนึ่งวัน สำหรับสิ่งที่เขียนได้นั้นไม่ใช่ข้อแลกเปลี่ยนที่ควรค่าแก่การเอ่ยถึง และที่อยู่ขาออกที่หมุนเวียนทำให้แย่ลง: ทุกการเปลี่ยนเซิร์ฟเวอร์ทำให้กฎแตก และการบำรุงรักษาเชิญรายการ CIDR กว้าง ๆ ที่ทำลายวัตถุประสงค์ของรายการที่อนุญาต

ที่อยู่เฉพาะหรือแบบคงที่ ในที่ที่ผู้ให้บริการขายมัน คือรูปแบบเดียวของสิ่งนี้ที่ขยายได้ ผูกรายการที่อนุญาตกับที่อยู่ที่เป็นของคุณคนเดียว หรือไม่ผูกเลย

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