Ai thực sự trả lời trên địa chỉ chuyên dụng của VPN?

Một địa chỉ nằm không dùng trong phân bổ của tổ chức không phải là trình lắng nghe, và việc thêm nó vào tường lửa không tạo ra cái nào. Phải có thứ gì đó kết thúc IKE trên địa chỉ đó, và cơ chế khác nhau tùy thuộc việc cổng sở hữu địa chỉ hay một thiết bị phía trên dịch nó. Chính đường đi của gói tin phân biệt hai trường hợp, và nó cũng quyết định tính năng nền tảng nào bạn cần trước khi ai đó mở yêu cầu thay đổi. Hãy mô hình hóa đường đi trước, rồi chọn.

Đường đi của gói tin phía sau địa chỉ

Đối tác gửi IKE đến địa chỉ mà nó được cấp, trên UDP 500 hoặc trên UDP 4500 khi có xuyên NAT. Bất kỳ thiết bị nào giữ địa chỉ đó trên đường đi hoặc nhận datagram tại chỗ và trả lời, hoặc chuyển tiếp nó đi nơi khác. Đó là hai khả năng duy nhất, và mọi thứ còn lại trong bài viết này xuất phát từ việc khả năng nào đúng.

Nhận tại chỗ nghĩa là tồn tại một socket trên thiết bị đó, gắn với địa chỉ đó. Chuyển tiếp nghĩa là datagram được viết lại và gửi tiếp đến một điểm cuối khác, nơi khi đó có socket. Một quy tắc tường lửa cho phép UDP 500 không nói cho bạn biết điều nào trong hai đang diễn ra.

Hãy viết bản ghi trước khi chạm vào bất cứ thứ gì: địa chỉ mà các đối tác liên hệ, cách mạng phía trên chuyển giao nó, giao diện cục bộ hoặc điểm cuối logic nhận nó, và tiến trình trả lời IKE. Bốn dòng, và mỗi dòng đều kiểm tra được. Khi một trong số đó chưa biết, cái chưa biết đó chính là công việc thiết kế chứ không phải chi tiết triển khai sẽ giải quyết sau. Điền chúng sau khi yêu cầu thay đổi được phê duyệt chính là cách một quy tắc dịch đi vào thiết bị sai.

Mô hình A: cổng sở hữu địa chỉ

Trong mô hình đầu, cổng tự giữ địa chỉ, hoặc như địa chỉ thứ cấp trên một giao diện sẵn có, như địa chỉ trên một giao diện chuyên dụng, hoặc như loopback mà nền tảng hỗ trợ như điểm cuối đường hầm. Đó là ba tính năng khác nhau với ba đường cấu hình khác nhau, và một nền tảng hỗ trợ một cái có thể không hỗ trợ những cái còn lại.

Hãy xác nhận nền tảng và bản phát hành hỗ trợ chính xác cách bố trí này trước khi thiết kế quanh nó. Một khối được định tuyến, một địa chỉ bổ sung trên giao diện và một điểm cuối loopback không thể thay thế cho nhau, và tài liệu của một bản phát hành không hứa bản tiếp theo sẽ hành xử như vậy.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Socket đang lắng nghe chính là bằng chứng. Nếu không có gì gắn với địa chỉ, cổng không phải bên kết thúc dù bảng định tuyến nói gì, và bắt gói sẽ cho thấy các datagram đến mà không có gì trả lời chúng.

Đừng đặt giao diện thứ hai vào một mạng con đã tồn tại ở nơi khác trong sơ đồ, và đừng cho rằng nền tảng sẽ xử lý việc đó. Các mạng con giao diện chồng lấn tạo ra việc chọn nguồn không rõ ràng và, trên nhiều nền tảng, từ chối cấu hình hoàn toàn.

Mô hình B: một thiết bị phía trên dịch nó

Trong mô hình thứ hai, một tường lửa phía trên giữ địa chỉ chuyên dụng và chuyển tiếp lưu lượng đến một cổng VPN khác. Đó là dịch đích có đường về, và là một thiết kế hoàn toàn hợp lệ miễn là được ghi lại như vậy.

Điều nó không phải là bằng chứng rằng thiết bị phía trên đã có được socket VPN cục bộ. Việc dịch chuyển tiếp gói tin; nó không biến chiếc hộp phía trên thành bên trả lời IKE. Nếu quy tắc phía trên bị gỡ hoặc đường về của nó đứt, VPN dừng lại dù cổng vẫn khỏe và các trình lắng nghe của nó còn nguyên.

Hãy ghi cả hai địa chỉ: địa chỉ các đối tác liên hệ và địa chỉ cổng thực sự nhìn thấy. Sau đó ghi vận chuyển và đường về, vì một phép dịch hoạt động với UDP 500 nhưng không với ESP đóng gói sẽ kết nối rồi sau đó không thể mang lưu lượng, một lỗi khó hiểu khi gỡ lỗi về sau.

Danh tính không phải địa chỉ bên ngoài

IPsec tách điểm cuối đường hầm khỏi lưu lượng mà nó bảo vệ, và kiến trúc giữ những quyết định đó ở các nơi khác nhau. Thay đổi địa chỉ mà các đối tác liên hệ không tự động thay đổi tiền tố bên trong nào được phép, tuyến nào được cài đặt hay tài nguyên nào mà phiên có thể chạm tới.

Danh tính đã xác thực lại tách biệt. IKEv2 mang tải danh tính và trao đổi xác thực không cần khớp với địa chỉ gói bên ngoài, và chính vì thế một thiết kế đã dịch vẫn có thể xác thực đúng.

Sự độc lập đó hữu ích và đồng thời là một cái bẫy. Hai tên DNS phân giải về một trình lắng nghe thông thường không chọn các backend VPN khác nhau, và một chứng chỉ nêu một danh tính sẽ không làm hài lòng đối tác đang mong một danh tính khác. Hãy xác nhận đối tác kiểm chứng điều gì trước khi giả định rằng chỉ địa chỉ quyết định điều đó.

Chấp nhận thiết kế bằng cách quan sát một kết nối

Hãy xem một kết nối được cấp phép mới thực sự được giao ở đâu, danh tính nào trả lời và luồng riêng nào sau đó được cho phép. Ba quan sát, ba tầng khác nhau, và một lần tra cứu công khai thành công địa chỉ không kiểm tra cái nào trong số đó.

Hãy giữ cả trường hợp phủ định: một đối tác không nên được chấp nhận, hoặc một tiền tố bên trong không nên tiếp cận được, được kiểm chứng sau thay đổi. Bản ghi bạn viết lúc đầu chính là thứ khiến phép thử đó khả thi mà không phải dựng lại thiết kế từ ký ức.

Mục đích của tất cả những điều này là để chủ mạng chọn một phương thức phân bổ được hỗ trợ thay vì dựa vào một khẳng định chung về việc mỗi tường lửa có thể làm gì với một địa chỉ thêm. Chính khẳng định đó là nơi những thiết kế này sai, vì nó nghe có lý trên mọi nền tảng và nói chung không đúng trên nền tảng nào. Bản ghi bốn dòng giải quyết điều đó cho nền tảng của bạn trong mười phút.