Kiểm tra nguồn/đích là một cổng, không phải toàn bộ đường VPN

VPN kết thúc trên một instance EC2, bạn có thể đến địa chỉ đường hầm của instance đó, và lưu lượng lẽ ra phải đi qua nó tới một máy chủ riêng khác lại biến mất. Đây là hai phép thử khác nhau, và trộn lẫn chúng sẽ mất hàng giờ. Phép thử thứ nhất hỏi liệu bạn có đến được instance; phép thử thứ hai yêu cầu nó chuyển tiếp lưu lượng cho một đích không phải của chính nó, việc này cần chuyển tiếp trên Linux, một chính sách tường lửa, một tuyến ở phía xa và một quyền ở cấp AWS không liên quan gì đến hệ điều hành khách. Không có gì trong bảng điều khiển thu hút sự chú ý vào sự khác biệt đó. Triệu chứng trông như lỗi định tuyến, và thường thì không phải.

Tách hai phép thử trước khi thay đổi bất cứ điều gì

Đến được cổng chứng minh đường hầm, tuyến tới địa chỉ của nó và nhóm bảo mật cho phép trao đổi. Chuyển tiếp cho một máy chủ khác không chứng minh điều nào trong số đó: nó dùng địa chỉ nguồn khác, đích khác và một instance trong vai trò mà nó không nhất thiết được tạo ra cho việc đó. Viết hai phép thử riêng ra và ghi lại phép nào thất bại, vì cách sửa của mỗi phép nằm ở một bảng điều khiển khác. Một instance cổng chỉ được tạo để kết thúc đường hầm không có lý do gì để chuyển tiếp cho bất cứ thứ gì khác, và các giá trị mặc định của nó phản ánh điều đó. Vì thế phép thử thứ hai cần thiết lập riêng chứ không phải một chỉnh nhỏ ở phép thứ nhất.

Một ping chạy được tới cổng và một ping thất bại tới máy chủ phía sau nó không phải là sự cố chập chờn. Đó là hành vi mong đợi của một instance chưa được nói rằng nó được phép chuyển tiếp.

Viết đường đi ra trước khi chạm vào một cài đặt

Ghi lại tiền tố của máy khách, instance hoặc giao diện mạng chuyển tiếp, mạng con đích và tuyến trả về. Một mục trong bảng tuyến của VPC trỏ tới một instance không cấu hình hệ điều hành của instance để chuyển tiếp, và một nhân khách có bật chuyển tiếp không tạo ra tuyến VPC. Cả hai đầu của mối quan hệ đó phải tồn tại, và chúng được sửa ở những nơi khác nhau bởi những người có quyền truy cập khác nhau.

Sau đó xem xét cài đặt kiểm tra nguồn/đích trên thành phần chuyển tiếp thực tế, không phải trên mọi instance trong VPC. AWS ghi lại vì sao một instance chuyển tiếp lưu lượng cho người khác phải tắt phép kiểm tra đó, và cả vì sao cài đặt này là quyết định cho từng instance chứ không phải giá trị mặc định cho toàn bộ VPC.

Bốn ranh giới, và phép kiểm tra chỉ là một trong số đó

Coi đường đi là bốn câu hỏi và trả lời theo thứ tự. Câu trả lời đầu tiên thất bại chính là nơi có công việc, và không câu nào khác bù đắp cho nó.

Thứ tự quan trọng vì việc kiểm tra rẻ: các tuyến hiện trên một trang, phép kiểm tra là một thuộc tính duy nhất, và ý kiến của đích thường là điều cuối cùng người ta hỏi.

Việc dịch thay đổi nguồn mà đích nhìn thấy

Một thiết kế định tuyến giữ địa chỉ nguồn của máy khách, nên đích cần một tuyến quay lại tiền tố của máy khách. Một thiết kế dịch địa chỉ thay vào đó trình ra địa chỉ của cổng, điều này loại bỏ yêu cầu ấy và thay bằng một bảng trạng thái trên cổng. Hãy quyết định theo kiến trúc bạn dự định, thay vì thêm việc dịch chỉ vì một ví dụ không liên quan đã dùng nó và có vẻ hiệu quả.

Nếu bạn dịch, hãy giới hạn quy tắc trong tiền tố máy khách và đích dự định. Nếu bạn giữ nguyên, hãy xác nhận phía xa thực sự biết tuyến chứ đừng cho rằng nó sẽ học được một tuyến.

Hãy thử từ máy khách gốc, rồi giữ lại thay đổi

Một yêu cầu tạo trên cổng có thể thành công trong khi yêu cầu được chuyển tiếp thất bại, vì đó là nguồn khác và trường hợp chuyển tiếp khác. Sau một bản sửa có mục tiêu, hãy lặp lại đúng phép thử từ máy khách tới tài nguyên đã thất bại, từ cùng máy khách đó, và xác nhận rằng câu trả lời quay về chứ không chỉ là yêu cầu đã tới.

Cuối cùng, đặt cài đặt vào cấu hình được quản lý của cổng để một instance thay thế nhận được nó. Một phép thử thành công phụ thuộc vào ngoại lệ thủ công là phép thử hết hạn ở lần dựng lại tiếp theo, và người đã phát hiện ra nó sẽ không ở đó để nhớ vì sao.