AWS Client VPN เชื่อมต่อแล้วแต่อินเทอร์เน็ตใช้ไม่ได้: การตรวจเส้นทาง

เชื่อมต่อ AWS Client VPN ได้แต่เข้าเน็ตไม่ได้? ตรวจเส้นทางของไคลเอนต์ การอนุญาตของปลายทาง เส้นทางออกของซับเน็ต และ DNS ตามลำดับนั้น

คุณเชื่อมต่อกับปลายทาง AWS Client VPN ได้ ซับเน็ตส่วนตัวตอบสนอง แต่ทุกหน้าเว็บสาธารณะยังหมดเวลา สิ่งนี้จำกัดปัญหาไว้ที่หนึ่งในสามวัตถุฝั่งที่จัดการ ได้แก่ เส้นทางที่ไคลเอนต์ติดตั้ง เส้นทางของปลายทางพร้อมกฎการอนุญาต หรือฮอปถัดไปของซับเน็ตที่เชื่อมโยง ผมตรวจตามลำดับนั้นเพราะแต่ละความล้มเหลวดูต่างกันจากฝั่งไคลเอนต์ คู่มือนี้ครอบคลุมปลายทางแบบจัดการที่เชื่อมกับ VPC ไม่ใช่เซิร์ฟเวอร์ OpenVPN บนอินสแตนซ์ EC2 และไม่ใช่การเชื่อมต่อ Cloud WAN หรือ Transit Gateway

เริ่มจากสิ่งที่ไคลเอนต์ส่งเส้นทางจริง

สถานะเชื่อมต่อพิสูจน์เฉพาะเซสชัน TLS และการกำหนด CIDR ให้ไคลเอนต์ ไม่มากกว่านั้น. ถามระบบปฏิบัติการว่าที่อยู่สาธารณะจะไปทางไหนขณะอุโมงค์เปิดอยู่ บน Linux ip route get 1.1.1.1 ควรระบุอินเทอร์เฟซอุโมงค์ บน macOS netstat -rn -f inet | head -5 แสดงรายการเริ่มต้น บน Windows Find-NetRoute -RemoteIPAddress 1.1.1.1 พิมพ์อินเทอร์เฟซที่เลือกและฮอปถัดไป

จากนั้นอ่านแฟล็ก split-tunnel เพราะเป็นตัวตัดสินว่าเส้นทางที่ปลายทางประกาศเป็นจุดหมายเดียวที่ไคลเอนต์ส่งเข้าอุโมงค์หรือไม่:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

เมื่อ SplitTunnel เป็น true จุดหมายสาธารณะจะใช้อุโมงค์ก็ต่อเมื่อปลายทางประกาศเส้นทางที่ครอบคลุมมัน ดังนั้น 0.0.0.0/0 ที่หายไปจะทิ้งทราฟฟิกนั้นไว้บนอินเทอร์เฟซท้องถิ่น เมื่อเป็น false ไคลเอนต์ดักจับทราฟฟิก แต่ปลายทางยังต้องส่งเส้นทางและอนุญาต มิฉะนั้นแพ็กเก็ตจะเข้าอุโมงค์และหยุดอยู่ที่นั่น เชื่อมต่อไคลเอนต์ใหม่หลังเปลี่ยนการตั้งค่าใดค่าหนึ่ง เพราะเส้นทางและเซิร์ฟเวอร์ DNS ถูกส่งมาตอนเชื่อมต่อ และไคลเอนต์ที่ทำงานอยู่ถือชุดเดิมไว้ได้

อ่านเส้นทางของปลายทางและกฎการอนุญาตแยกกัน

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

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

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

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

กฎสำหรับ CIDR ของ VPC ไม่ได้บอกอะไรเกี่ยวกับ 0.0.0.0/0 การเพิ่มส่วนที่ขาดสำหรับอุโมงค์เต็มรูปแบบหมายถึงหนึ่งเส้นทางต่อซับเน็ตที่เชื่อมโยง บวกกฎการอนุญาตที่คุณตรวจสอบย้อนหลังได้:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all ให้จุดหมายแก่ไคลเอนต์ทุกตัวของปลายทาง จึงควรเก็บไว้เฉพาะช่วงที่อุโมงค์ต้องเป็นแบบเต็มรูปแบบ กฎที่ผูกกับกลุ่มไดเรกทอรีเหมาะกว่าเมื่อมีกลุ่มให้ผูก

ตามแพ็กเก็ตออกจากซับเน็ตที่เชื่อมโยง

เส้นทางของปลายทางตัดสินว่า AWS ส่งแพ็กเก็ตให้ซับเน็ตนั้น ไม่ได้ตัดสินฮอปถัดไปหลังจากนั้น ซึ่งอยู่ในตารางเส้นทาง VPC ของซับเน็ตเอง:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

เส้นทางเริ่มต้นที่ใช้งานได้ชี้ไปที่เกตเวย์อินเทอร์เน็ตสำหรับซับเน็ตสาธารณะ หรือเกตเวย์ NAT สำหรับซับเน็ตส่วนตัว และสถานะ blackhole หมายความว่าเป้าหมายถูกลบและเส้นทางตายอย่างเงียบ ๆ ตอนนี้ สิ่งเหล่านี้เป็นตารางคนละตารางกับรายการเส้นทางของปลายทาง และการซ่อมอย่างหนึ่งไม่ได้ซ่อมอีกอย่าง

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

เลือกชั้นแรกจากอาการแทนที่จะเปลี่ยนทั้งสามอย่างพร้อมกัน:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

แยกความล้มเหลวของ DNS ออกจากเส้นทางที่ตายแล้ว

การแปลงชื่อล้มเหลวต่างจากการส่งต่อ และอุโมงค์เต็มรูปแบบทำให้ความต่างนี้สำคัญเพราะตอนนี้เข้าถึงตัวแปลงที่ถูกดันผ่านอุโมงค์ หากปลายทางระบุเซิร์ฟเวอร์ DNS ของ VPC ที่อยู่ของเซิร์ฟเวอร์เหล่านั้นต้องมีการครอบคลุมด้วยเส้นทางและการอนุญาตเหมือนจุดหมายอื่น ๆ ถามตัวแปลงโดยตรงเพื่อดูว่าคุณมีความล้มเหลวแบบใด: dig +short example.com @10.0.0.2 หรือ nslookup example.com 10.0.0.2 บน Windows

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

เวลาช่วยได้ การเชื่อมต่อ TCP ที่ไม่ได้รับการตอบสนองภายในไม่กี่วินาทีชี้ไปที่การกำหนดเส้นทางหรือตัวกรอง ขณะที่คำขอที่ค้างอยู่ในการค้นหาชื่อชี้ไปที่ตัวแปลง การเปลี่ยนเส้นทางเริ่มต้นขณะตัวแปลงเข้าถึงไม่ได้มักเปลี่ยนความล้มเหลวหนึ่งเป็นสอง

ย้อนกลับอย่างสะอาดแล้วตรวจสอบเส้นทางออก

วัตถุทั้งสองเป็นการเพิ่ม ดังนั้นการย้อนกลับคือการลบ ไม่ใช่การซ่อม:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

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

จบด้วยรายการสั้น ๆ และถือรายการสุดท้ายเป็นส่วนหนึ่งของการเปลี่ยนแปลง ไม่ใช่เอกสาร:

  • สำหรับทุกซับเน็ตที่เชื่อมโยง ให้มี 0.0.0.0/0 หนึ่งเส้นทางของปลายทาง
  • กฎการอนุญาตที่ครอบคลุม 0.0.0.0/0 สำหรับไคลเอนต์ที่คุณต้องการให้บริการ
  • เส้นทางเริ่มต้นของ VPC ที่ไม่ใช่ blackhole บนทุกซับเน็ตที่เชื่อมโยง
  • ทราฟฟิกขาออกของกลุ่มความปลอดภัยของการเชื่อมโยง พร้อมทราฟฟิกย้อนกลับของ ACL
  • ที่อยู่ของตัวแปลงถูกกำหนดเส้นทางและอนุญาตแล้ว ตรวจสอบด้วยคำขอแบบมีชื่อ
  • การย้อนกลับที่บันทึกไว้สำหรับเส้นทางและกฎ

หมายเหตุขอบเขตหนึ่งข้อ: นี่คือเส้นทาง IPv4 ไคลเอนต์แบบ dual-stack เก็บการเชื่อมต่อ IPv6 ที่มีอยู่แล้วไว้ ดังนั้นเส้นทางเริ่มต้น IPv6 จึงเป็นการตัดสินใจแยกต่างหากที่มีการอนุญาตของตัวเอง ไม่ใช่ผลข้างเคียงของอันนี้

บทความที่เกี่ยวข้อง