Bể địa chỉ VPN hai chồng giao thức: định địa chỉ cho cả hai họ trong strongSwan

Các bể IPv4 và IPv6 bên trong, tiền tố được bảo vệ và họ của đường hầm bên ngoài là ba quyết định riêng. Hãy hoạch định từng thứ trước khi gọi nó là hai chồng.

Một cổng vào có thể cấp cho người dùng di động cả địa chỉ ảo IPv4 lẫn IPv6 trong khi đường hầm bên ngoài vẫn đi qua IPv4. Đây là những quyết định độc lập, và việc coi chúng là một chính là chỗ mà các kế hoạch hai chồng thường sụp đổ. Các họ bên trong của máy khách, các tiền tố được bảo vệ mà nó có thể chạm tới, và phương thức vận chuyển mang phần đóng gói là ba lựa chọn riêng biệt.

Phần lớn sự nhầm lẫn đến từ việc áp dụng từ hai chồng cho một thiết kế chỉ hai chồng ở một chỗ. Một dịch vụ có thể hai chồng bên trong, một chồng trên địa chỉ bên ngoài, và vẫn hoạt động hoàn hảo cho máy khách. Điều nó không thể làm là hoạt động một cách tình cờ.

Hai họ bên trong, một đường ra ngoài

Kết nối bên ngoài là IKE trên UDP, và nó cần một họ địa chỉ có thể tiếp cận từ bất cứ nơi nào máy khách ở. Một địa chỉ IPv6 bên trong không đòi hỏi nhà cung cấp có IPv6, vì gói bên trong là tải trọng nằm trong gói bên ngoài. Nhiều triển khai đang chạy vẫn chuyển tiền tố IPv6 qua một liên kết lên chỉ có IPv4.

Điều mà đường ra bên ngoài thực sự giới hạn là khả năng tiếp cận và việc đi qua NAT. Nếu cổng vào chỉ quảng bá một địa chỉ IPv4, máy khách trên mạng chỉ có IPv6 không thể kết nối được chút nào, dù bạn đã cấu hình bao nhiêu bể. Hãy quyết định họ bên ngoài dựa trên tập người dùng của bạn, không dựa trên kế hoạch địa chỉ bên trong.

Cấp cho máy khách một địa chỉ trong mỗi họ

Yêu cầu cả hai họ là một dòng ở phía máy khách, miễn là cổng vào có thứ để chia. Các bể có tên giữ nguồn tách biệt khỏi các mạng dịch vụ, và chính thuộc tính này khiến các quy tắc tường lửa vẫn đọc được sau sáu tháng.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Giá trị vips yêu cầu một địa chỉ từ mỗi họ, và danh sách bể quyết định những địa chỉ đó đến từ đâu. Tài liệu của strongSwan về IP ảo bao gồm nhiều yêu cầu và việc cấp phát bể, kể cả điểm rằng máy khách yêu cầu một địa chỉ cụ thể chỉ đưa ra một tùy chọn mà bên trả lời có thể ghi đè. Đừng xây dựng quy tắc truy cập giả định máy khách luôn nhận cùng một giá trị.

Hãy tạo tiền tố cục bộ duy nhất của riêng bạn thay vì sao chép ví dụ. Hai tổ chức mà cả hai fd42::/16 triển khai nó sẽ phát hiện xung đột lần đầu tiên họ kết nối với nhau, và việc chẩn đoán điều đó không dễ chịu.

Bộ chọn mô tả đích đến, không phải nguồn

Các bộ chọn lưu lượng cục bộ của SA con cho biết mạng được bảo vệ nào nằm sau cổng vào, và các bộ chọn từ xa mô tả thứ máy khách được dùng làm nguồn. Địa chỉ bể ảo thuộc về phía nguồn của chính sách đó; đặt nó vào danh sách đích là một cách đọc sai cấu hình phổ biến.

Cả hai họ đều cần tuyến quay về và chuyển tiếp được phép trên cổng vào. Thêm một tiền tố vào bộ chọn mà không có tuyến quay lại bể sẽ tạo ra một đường hầm được thiết lập, cho một chiều lưu lượng đi qua và âm thầm bỏ phản hồi. Bộ chọn là chính sách, không phải định tuyến.

Giữ các bể và tiền tố dịch vụ trong các khối riêng của kế hoạch địa chỉ. Khi chúng chồng lên nhau, một tuyến đáng lẽ phải tới máy chủ được bảo vệ có thể khớp với địa chỉ bể và biến mất vào đường hầm.

DNS và đường phản hồi quyết định việc đó có cảm giác hoàn tất hay không

Câu trả lời của bộ phân giải độc lập với phương thức vận chuyển dùng để tới bộ phân giải. Một tên có thể trả về bản ghi A, bản ghi AAAA hoặc cả hai, và máy khách chọn theo các quy tắc ưu tiên của riêng nó. Nếu một dịch vụ bên trong công bố bản ghi AAAA nhưng không có gì định tuyến tiền tố đó, máy khách trên mạng hai chồng sẽ thử đường IPv6 trước và ngồi đó cho tới khi nó thất bại. Không có gì trong cấu hình đường hầm trông sai trong lúc đó.

Vì vậy hãy quyết định theo từng tên những họ nào nên dùng được, rồi kiểm tra rằng tiền tố tương ứng có trong bộ chọn và có tuyến quay về. Đó là quyết định cho từng dịch vụ. Việc công bố cả hai loại bản ghi không phân biệt chính là cách một dịch vụ đang chạy chỉ với IPv4 bắt đầu hết thời gian chờ với một nửa người dùng.

Hãy xác minh cả hai họ trước khi nói là xong

Cấu hình nạp được không phải là cấu hình chạy được. Hãy đọc trạng thái mà daemon báo cáo, xác nhận việc cấp phát bể, rồi xem các tuyến mà máy khách thực sự đã cài.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Hai lệnh đầu cho thấy các SA con đã thiết lập và bể nào còn địa chỉ trống, nhờ đó một kế hoạch chạy được với máy khách đầu tiên mà hỏng ở máy thứ mười trở nên hữu hình. Hai lệnh cuối cho thấy máy khách có nhận được địa chỉ IPv6 toàn cầu từ bể hay không và lưu lượng tới một tiền tố được bảo vệ thực sự sẽ đi đâu. Hãy so địa chỉ được cấp với bể bạn đã cấu hình, không so với địa chỉ bạn hy vọng. Nếu bên trả lời chọn một giá trị khác theo chính sách của nó, các tuyến và quy tắc tường lửa vẫn phải khớp với lựa chọn đó.

Sau đó hãy thử một máy chủ được bảo vệ cho mỗi họ, và thử một tên phân giải ra cả hai. Một bài thử chỉ một họ không nói gì về nửa còn lại của kế hoạch mà bạn chưa thực hành, và nửa đó thường là nơi chứa tuyến bị thiếu.

Bài viết liên quan