Vì sao VM GCP của bạn không thể trả lời pool IPv6 của OpenVPN

Máy khách VPN IPv6 của bạn đến được khối lượng công việc, khối lượng công việc trả lời vào đường hầm, và câu trả lời không bao giờ đến. Phản xạ đầu tiên là đổ lỗi cho tường lửa hoặc đường hầm, và thường cả hai đều không có lỗi. Địa chỉ do OpenVPN cấp là một mạng bên trong chỉ tồn tại bên trong đường hầm; Google Cloud không hề biết rằng fd42:90::/64 phải nằm sau một VM cụ thể cho đến khi bạn nói với nó.

Hai hệ thống riêng biệt phải học được sự thật này, và chỉ một trong số đó là OpenVPN. VPC cần một tuyến trước khi có thể gửi bất cứ thứ gì trở lại, và VM phải được phép chuyển tiếp những gì đến. Sai ở bất kỳ nửa nào thì triệu chứng trông giống hệt nhau.

Pool là mạng bên trong, không phải subnet

OpenVPN có thể cấp địa chỉ IPv6 từ một dải bạn chọn, và dải đó là một điều hư cấu mà hai đầu đường hầm đồng ý với nhau. Nó không phải subnet của Google Cloud, không xuất hiện trong danh sách subnet của VPC, và giao diện mạng của VM không nhận được những địa chỉ đó. Vì vậy khối lượng công việc trả lời máy khách sẽ gửi gói tin đến một địa chỉ mà mạng coi là không thể định tuyến.

Giữ pool ngoài mọi dải mà VPC đã dùng. Cũng giữ nó ngoài các dải nằm sau những đường hầm khác của bạn. Sự chồng lấn biến một lỗi định tuyến sạch sẽ thành lỗi chập chờn chỉ xuất hiện khi có tải.

Địa chỉ cục bộ duy nhất như fd42:90::/64 là lựa chọn hợp lý cho mạng bên trong này. Tiền tố cũng nhắc rằng thiết kế này riêng tư ngay từ đầu. Không có gì trong một pool ULA khiến nó trở thành nguồn hợp pháp trên internet công cộng.

Cho VPC một đích đến và một bước nhảy tiếp theo

Câu trả lời cần một tuyến VPC có đích là pool và bước nhảy tiếp theo là VM VPN. Tài liệu tuyến tĩnh hiện tại bao gồm các dải đích IPv6 và liệt kê những loại bước nhảy tiếp theo nào là hợp lệ, nên hãy xác minh dạng được hỗ trợ cho cấu trúc liên kết của bạn thay vì sao chép một ví dụ IPv4 cũ.

Địa chỉ bước nhảy tiếp theo phải là địa chỉ thực sự được gán cho giao diện cloud của phiên bản. Địa chỉ đường hầm bên trong của VM không phải địa chỉ đó. Dù vậy vẫn dùng nó sẽ tạo ra một tuyến cài đặt sạch sẽ và không bao giờ khớp với gói tin nào. Hãy đọc danh sách giao diện trước khi viết tuyến.

Mức ưu tiên của tuyến quan trọng như chính bản ghi. Các tuyến subnet cụ thể hơn các tuyến tùy chỉnh bạn thêm vào, nên một pool cắt ra từ dải subnet hiện có sẽ thua tuyến subnet, bất kể tuyến tùy chỉnh được viết thế nào. Hãy chọn một pool riêng, rồi xác nhận rằng tuyến hiển thị phiên bản là bước nhảy tiếp theo và tiền tố đích đúng:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Chuyển tiếp phải được bật hai lần

Một tuyến đưa gói tin đến phiên bản. Nó không làm cho phiên bản sẵn sàng chuyển tiếp thứ không được gửi đến nó, và quyền đó tồn tại ở hai tầng.

Phía cloud cần bật khả năng chuyển tiếp của phiên bản; đây là thiết lập cho phép VM nhận lưu lượng cho những địa chỉ mà nó không sở hữu và chuyển tiếp đi. Phía khách cần khả năng chuyển tiếp IPv6 riêng, vì nhân hệ điều hành đưa ra quyết định riêng sau khi gói tin đến. Cả hai phải được bật trước khi một câu trả lời duy nhất đi qua đường hầm.

sysctl -w net.ipv6.conf.all.forwarding=1

Sau đó các quy tắc tường lửa phải cho phép dải nguồn bên trong theo cả hai chiều. Google Cloud đánh giá gói tin đã giải mã, nên một quy tắc chỉ bao phủ subnet của VPC sẽ bỏ lưu lượng của pool sau khi đường hầm đã thành công. Thêm pool làm dải nguồn trong quy tắc vào, và kiểm tra rằng không có chính sách ra tùy chỉnh nào chặn câu trả lời. Quy tắc cho phép ngầm bao phủ trường hợp mặc định, còn quy tắc ra viết tay thì không.

Nói cho OpenVPN biết ai sở hữu cái gì

OpenVPN chuyển tiếp tới một máy khách khi nó biết máy khách đó sở hữu đích. Địa chỉ máy khách từ pool do chỉ thị máy chủ định nghĩa pool quản lý, nhưng một subnet nằm sau máy khách là cách bố trí khác và cần một mục sở hữu rõ ràng cho máy khách đó.

Nhầm lẫn hai trường hợp này tạo ra một đường hầm nơi ping tới máy chủ hoạt động còn phía sau thì không. Hãy quyết định bạn đang xây dựng trường hợp nào, rồi viết mục tương ứng thay vì thêm dòng push thứ hai và hy vọng.

Giữ lối ra internet ngoài thiết kế này

Truy cập riêng tư và truy cập internet là hai kế hoạch riêng. Một pool ULA có thể đến được các khối lượng công việc của VPC qua đường hầm khi định tuyến và chuyển tiếp đồng ý, và chính pool đó không có đường tới internet công cộng qua VPC, vì cổng cloud sẽ không chấp nhận một nguồn đường hầm tùy tiện làm nguồn của mình.

Nếu máy khách cũng cần lối ra internet, hãy lập kế hoạch địa chỉ hóa và định tuyến được hỗ trợ cho việc đó, giữ nó độc lập với pool riêng, và kiểm thử hai đường đi riêng biệt. Một đường đi hoạt động không nói gì về đường còn lại, và một thiết kế trộn lẫn cả hai sẽ thất bại theo cách trông như một đường hầm hỏng.