Giao thức 47 so với cổng TCP 47: hai tiêu đề, hai quy tắc
Số giao thức và cổng sống trong các tiêu đề khác nhau, nên một quy tắc không thể thay thế quy tắc kia. PPTP tách hai thứ đó, và ô cổng không thể diễn đạt GRE.
Mạng khách sạn và tường lửa hội nghị thường hiển thị một ô cho phép tùy chỉnh, và ai đó gõ 47 vào đó với hy vọng PPTP sẽ hoạt động. Quy tắc được tạo, đường hầm vẫn thất bại, và lần thử tiếp theo dùng một con số khác. Lỗi nằm trong chính gói tin: IPv4 có trường giao thức đặt tên cho thứ theo sau tiêu đề IP, trong khi TCP và UDP có trường cổng chỉ tồn tại khi bạn ở bên trong một trong các tiêu đề đó. Đây không phải hai cách viết của cùng một sự cho phép.
Tiêu đề IPv4 đặt tên cho giao thức tiếp theo
Trường giao thức là một byte trong tiêu đề IPv4, và nó giữ một con số mô tả tải trọng: 6 cho TCP, 17 cho UDP, 47 cho GRE, 50 cho ESP. Mọi thứ lọc gói tin đều đọc giá trị đó trước khi nhìn sâu hơn, vì tiêu đề sâu hơn chỉ có nghĩa sau khi đã biết loại. Thay đổi một cổng về sau trong cuộc trò chuyện, và trường này không hề nhúc nhích.
Vì vậy một quy tắc viết theo giao thức 47 mô tả lớp IP. Không có cổng nào tham gia vào quyết định.
Cổng tồn tại bên trong TCP và UDP, không ở nơi nào khác
Cổng là các định danh mười sáu bit bên trong tiêu đề TCP và UDP, và nhiệm vụ của chúng là tách các cuộc trò chuyện dùng chung một địa chỉ. Tiêu đề GRE mang một giá trị loại giao thức, thường là EtherType, cộng với các khóa tùy chọn cho việc ghép kênh. Do đó cụm từ cổng 47 không đặt tên cho bất cứ thứ gì mà một gói GRE có thể khớp.
Các giao diện tường lửa khác nhau ở mức độ hiển thị những điều này. Một số nhận số giao thức, một số cung cấp danh sách có tên, và vài loại chỉ nhận TCP hoặc UDP kèm cổng.
PPTP dùng cả hai lớp cùng lúc
PPTP là ví dụ rõ nhất vì nó cố ý chia công việc của mình cho hai lớp. Kết nối điều khiển là một phiên TCP đến cổng 1723, và đường dữ liệu là GRE, giao thức 47, không có cổng nào tham gia. Một tường lửa chỉ cho phép 1723 và không gì khác sẽ để cuộc thương lượng bắt đầu rồi vứt bỏ tải trọng. Đường hầm trông như bị treo sau khi xác thực thay vì không kết nối được, và đó là lý do triệu chứng thường được báo cáo như vấn đề mật khẩu.
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
Đọc riêng hai dòng khi viết quy tắc, và kiểm tra từng dòng theo cú pháp của nhà cung cấp. Một dòng cần cổng, dòng kia cần số giao thức, và không có mục nào bao quát cả hai.
Vì sao trang chuyển tiếp cổng không thể diễn đạt GRE
Một biểu mẫu chuyển tiếp chỉ nhận TCP và UDP không thể mô tả GRE, bất kể biểu mẫu tên gì. Việc dịch địa chỉ thêm một khó khăn thứ hai, vì GRE không có cổng và bộ dịch phải theo dõi định danh cuộc gọi thay vào đó. Một số router tiêu dùng có sẵn trợ thủ xử lý việc này; nhiều loại không có, và không mục cho phép TCP bổ sung nào tạo ra hành vi đó.
Khi yêu cầu thực sự là một đường hầm hiện đại, hãy chọn thiết kế cố ý dùng TCP hoặc UDP thay vì hy vọng bộ dịch đoán đúng.
Đóng gói quyết định những gì bộ lọc thấy
Đóng gói thay đổi gói bên ngoài, và gói bên ngoài là thứ một quy tắc khớp vào. ESP gốc là giao thức 50, trong khi NAT traversal bọc ESP vào UDP 4500 để nó sống sót qua việc dịch địa chỉ. Bộ lọc cho phép UDP 4500 không bao giờ thấy giao thức 50, và bộ lọc viết cho giao thức 50 không bao giờ khớp với dạng đã bọc.
Hãy hỏi máy khách và cổng nối đã đồng ý đóng gói nào, rồi viết quy tắc cho đúng dạng bên ngoài đó và không gì hơn.
Viết quy tắc để ai đó có thể kiểm chứng
Diễn đạt mỗi quy tắc thành họ địa chỉ, giao thức bên ngoài, cổng truyền tải nếu có, hướng và cả hai điểm cuối. Người phản biện có thể so câu đó với bản bắt gói tin và đi đến kết luận. Một chỉ dẫn mở 47 thì không ai kiểm chứng được, và đó là lý do nó tồn tại nhiều năm trong sổ tay quy trình.
Thêm bài kiểm chứng điều đó: kết nối trong khi bắt gói trên giao diện bên ngoài, và xác nhận giao thức cùng cổng bên ngoài thực sự xuất hiện trong dấu vết.