Định tuyến theo nguồn cho hai nhóm VPN: điều quy tắc của bạn bỏ sót
Một quy tắc dạng from khớp với địa chỉ khách hàng trước khi SNAT viết lại nó, và bài kiểm tra từ cổng không khớp với cả hai. Hãy chạy tra cứu cho từng nhóm và đọc mức ưu tiên thay vào đó.
Hai nhóm khách hàng, một cổng và kế hoạch có vẻ đơn giản: một quy tắc đưa nhóm thứ nhất ra đường truyền nhanh, quy tắc khác đưa nhóm thứ hai qua đường hầm đối tác. Rồi quy tắc đã có mà nhóm thứ hai vẫn đi ra bằng tuyến mặc định. Quy tắc không hỏng. Nguồn của gói không phải là thứ tác giả chờ đợi tại thời điểm tra cứu, vì việc dịch và tra cứu diễn ra ở những điểm khác nhau trên hành trình của cùng một gói, và thứ tự ngược với sơ đồ trong đầu mà hầu hết mọi người vẽ.
Việc tra cứu diễn ra trước khi nguồn được viết lại
Với gói được chuyển tiếp từ một khách hàng VPN, nhân hệ điều hành chạy một trình tự cố định. Gói đến giao diện đường hầm, đi qua prerouting nơi conntrack và DNAT trú ngụ, sau đó quyết định định tuyến được đưa ra, sau đó chuyển tiếp, sau đó postrouting nơi SNAT được áp dụng cuối cùng. Quy tắc dạng from được xem xét trong lúc ra quyết định định tuyến đó, nghĩa là nó thấy địa chỉ gốc của khách hàng, không phải địa chỉ đã dịch.
Vì vậy thêm một quy tắc masquerade không thay đổi chính sách nào khớp với luồng đi ra. Cái thay đổi là đầu xa nhìn thấy gì, và do đó là đường quay về nào tồn tại. Đó là hai hệ quả khác nhau, và các buổi rà soát thay đổi liên tục nhầm lẫn chúng. Tách chúng ra và thiết kế thường trở nên rõ ràng trong vòng một phút.
Địa chỉ đã dịch xuất hiện trong quy tắc ở chiều phản hồi. Gói quay về cổng được gửi đến địa chỉ đã dịch, và nếu bạn có quy tắc chính sách dựa trên đích hoặc trên giao diện mà gói đi vào, đó chính là giá trị bạn sẽ so khớp. Cùng một kết nối, mỗi chiều lại có nguồn sự thật khác nhau.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Vậy hai nhóm có nguồn khác nhau thực sự cần bảng khác nhau, và thiết kế là đúng. Điều mà bảng ở trên loại trừ chính là lối tắt gỡ lỗi bằng cách xem đầu xa nhận được gì rồi suy ra quy tắc từ đó.
Kiểm tra từ cổng không phải kiểm tra nhóm
Lưu lượng do chính cổng tạo ra không bao giờ đi qua prerouting, vì nó không đến trên giao diện nào. Nó được định tuyến trong đường ra, với địa chỉ của chính cổng làm nguồn, và quy tắc from dựa trên dải khách hàng sẽ không khớp. Mọi phiếu trong lĩnh vực này nói rằng chạy được từ máy nhưng không từ khách hàng đều là sự lặp lại của chính sự thật đó.
Hãy mô phỏng khách hàng thay vì ước lượng. Có thể hỏi trực tiếp việc tra cứu định tuyến, khi cung cấp nguồn và giao diện vào:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201Chạy nó một lần cho mỗi nhóm. Nếu hai lệnh trả về cùng một giao diện thì các quy tắc không tách được hai nhóm, và nguyên nhân là thiếu một quy tắc hoặc có một quy tắc ưu tiên cao hơn khớp với cả hai. Nếu chúng trả về giao diện khác nhau nhưng khách hàng vẫn thất bại, lỗi nằm sau bước tra cứu và bạn có thể ngừng xem quy tắc.
Ưu tiên, không phải vị trí trong tệp
Các quy tắc được đánh giá theo thứ tự ưu tiên tăng dần, và con số mới là điều quan trọng, không phải thứ tự bạn gõ. Bảng local ở mức ưu tiên 0, bảng main ở 32766 và quy tắc mặc định ở 32767, vì thế một quy tắc được thêm với mức ưu tiên mặc định sẽ rơi gần cuối danh sách và thua gần như mọi thứ.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Một mức ưu tiên tường minh làm thứ tự mong muốn hiện rõ trong tệp và trong buổi rà soát. Nó cũng ngăn một bổ sung về sau âm thầm vượt lên trước một quy tắc đang có, đây là nguyên nhân phổ biến nhất khiến một chính sách đang chạy ngừng chạy sau một thay đổi không liên quan.
Một quy tắc khớp trỏ tới bảng không đầy đủ là cái bẫy còn lại. Nếu bảng 201 có tuyến mặc định nhưng không có tuyến tới đích, gói sẽ bị bỏ hoặc bị gửi sai chỗ, và quy tắc trông hoàn toàn đúng khi xét riêng. Hãy đọc bảng, không chỉ đọc quy tắc. Quy tắc là con trỏ, và một bảng rỗng là con trỏ vào hư không.
Đường quay về vẫn phải tồn tại
Chính sách nguồn chọn một lối ra. Nó không tạo ra đường quay về. Nếu nhóm thứ hai đi ra qua đường hầm đối tác, đối tác phải biết cách đến 172.31.8.0/24, hoặc bằng tuyến quay về cổng, hoặc bằng cách nhận những địa chỉ đã dịch mà họ đã biết.
Chọn giữa hai cách là một quyết định thiết kế với hệ quả nhìn thấy được. Định tuyến dải khách hàng quay về giữ nguyên danh tính từng khách hàng ở phía đối tác và đòi hỏi họ chấp nhận tiền tố của bạn. Việc dịch giấu nhóm sau một địa chỉ duy nhất và đòi hỏi đối tác chỉ chấp nhận địa chỉ đó, với cái giá là nhật ký của bạn và của họ không còn khớp nhau về việc ai đã kết nối.
Dù bạn chọn gì, hãy ghi nó bên cạnh định nghĩa nhóm. Một tuyến quay về chỉ tồn tại trong trí nhớ của ai đó chính là thứ tồn tại cho đến khi đối tác thay tường lửa, rồi mất một ngày để dựng lại.
Đừng bắt lấy đường hầm của chính cổng trong chính sách
Các quy tắc bạn viết cho khách hàng cũng áp dụng cho lưu lượng do cổng tạo ra, trừ khi bạn loại trừ nó. Một quy tắc rộng dựa trên dấu hoặc trên giao diện ra có thể bắt lấy kết nối của chính cổng tới đối tác, và khi đó đường hầm mang chính sách bị chính sách định tuyến. Điều đó tạo ra vòng lặp hoặc gián đoạn trông như lỗi của nhà cung cấp.
Giới hạn mỗi quy tắc hẹp nhất có thể theo thiết kế: tiền tố nguồn, giao diện vào và, nơi được hỗ trợ, một dấu chỉ các gói của khách hàng mang. Sau đó kiểm tra kết nối của chính cổng sau mỗi thay đổi quy tắc, vì lỗi tự tham chiếu và không xuất hiện trong bài kiểm tra từ khách hàng.
Trang hướng dẫn của ip-rule ghi lại ngữ nghĩa của bộ chọn và của mức ưu tiên. Kết hợp nó với bài kiểm tra tra cứu cho từng nhóm và thiết kế trở nên kiểm chứng được, đó là khác biệt giữa định tuyến theo chính sách tồn tại một năm và loại mà mọi người sợ chạm vào.