Vì sao NAT tại nhà không bảo vệ giao diện VPN của bạn
Router tại nhà chuyển tiếp đường hầm, nhưng máy chủ đánh giá gói tin đã giải mã. Đọc riêng trình lắng nghe, đường đi bên trong và chính sách đầu vào.
Máy tính xách tay sau một router tại nhà không mở cổng vẫn chấp nhận các kết nối SSH đến qua VPN. Đó không phải mâu thuẫn, vì hai thiết bị khác nhau đánh giá hai gói tin khác nhau. Router chuyển tiếp phần vận chuyển đã mã hóa, còn máy chủ quyết định làm gì với gói tin đã giải mã đến giao diện đường hầm của nó. Tách hai quyết định đó ra chính là toàn bộ bài tập.
Router chuyển tiếp đường hầm, máy chủ đánh giá gói tin
Hãy vẽ đường đi từ nguồn từ xa đến dịch vụ trước khi xem một quy tắc nào. Chặng ngoài là phần vận chuyển VPN, do router và cổng vào xử lý. Chặng trong bắt đầu khi điểm cuối bóc lớp đường hầm và máy chủ nhận một gói tin được gửi đến địa chỉ VPN của nó.
Gộp hai chặng đó lại và router được ghi công cho một quyết định mà máy chủ đưa ra. Một trang chuyển tiếp cổng hay nhật ký router chỉ mô tả các cuộc trò chuyện bên ngoài, và không cái nào nói lưu lượng đã giải mã nào mà máy chủ sẽ chấp nhận. Máy chủ áp dụng chính sách đầu vào của riêng nó cho gói tin bên trong, giống như với bất kỳ gói tin nào đến một giao diện. Chính trong chính sách đó, câu hỏi về phơi nhiễm mới thực sự được giải quyết.
Trình lắng nghe wildcard không phải là dịch vụ công cộng
Trên Linux, liên kết với INADDR_ANY nghĩa là mọi địa chỉ cục bộ, nên một dịch vụ có thể trả lời trên giao diện đường hầm mà nó chưa từng đặt tên. Tài liệu tham chiếu socket IP mô tả liên kết đó, và đáng đọc trước khi rút ra kết luận từ danh sách trình lắng nghe. Một mục wildcard là sự thật về socket, không phải khẳng định về khả năng tiếp cận.
Hai dòng dưới đây là cùng một dịch vụ trong hai liên kết khác nhau, và sự khác biệt chính là toàn bộ câu trả lời cho việc giao diện có quan trọng hay không. Hãy đọc socket nằm ở địa chỉ nào trước mọi thứ khác.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))Gọi tên cách bố trí có thể chạm tới cổng
Ba cách bố trí đưa một gói tin lên giao diện đó, và chúng có chủ sở hữu khác nhau. Gọi đúng tên cách nào sẽ quyết định ai phải thay đổi chính sách.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
Một kết quả trình duyệt hiển thị địa chỉ ra công cộng không nói gì về cả ba, vì nó mô tả lưu lượng đi ra rời đi thế nào chứ không phải lưu lượng đi vào được phép gì. Hãy làm ngược từ trình lắng nghe và địa chỉ nguồn trong nhật ký dịch vụ. Nếu nguồn là một peer đường hầm khác, chính sách cổng vào là tài liệu đáng quan tâm. Nếu đó là một địa chỉ đã dịch, hãy tìm bản dịch trước khi đổi một quy tắc.
Giới hạn dịch vụ trong đường đi bạn dự định
Nếu SSH chỉ cần từ một đường quản trị, hãy ghi đường đó thành một dải nguồn cộng với một giao diện. Sau đó giới hạn các quy tắc đầu vào của máy chủ theo giao diện, đích và nguồn thay vì theo tên mạng, vì một cái tên trông như riêng tư có thể đại diện cho bất kỳ địa chỉ nào. Để lại một tuyến cho người sẽ sửa vấn đề tiếp theo.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter inputMột quy tắc nêu tên giao diện đường hầm và dải quản trị sẽ nói rõ ý định ở một nơi. Hãy so sánh với một quy tắc viết cho mạng Wi-Fi, vốn không nói gì về lưu lượng đường hầm đã giải mã. Khi hai lớp không đồng ý, chính sách của máy chủ là cái mà gói tin gặp phải.
Hãy để đăng nhập và bản vá đúng chỗ của chúng; chạm tới một cổng chưa bao giờ giống với việc được phép dùng nó. Ghi lại họ địa chỉ và thời gian cho mọi nguồn lạ, và điều tra trước khi đổ lỗi cho một tính năng hay một lỗ hổng. Một quy tắc chấp nhận mọi peer đường hầm là thiết kế khác với quy tắc chấp nhận một mạng con quản trị, và không dòng nhật ký nào sẽ nói cái nào là dự định.
Chấp nhận bản sửa với một thành công và một từ chối
Chứng minh cả hai nửa: một kết nối được chấp thuận thành công và một đường bị loại trừ bị từ chối. Sự từ chối là nửa mà người ta bỏ qua, và nó là cái cho thấy quy tắc đang làm việc thay vì đứng cạnh một giá trị mặc định dễ dãi. Hãy thử từ phía bị loại trừ thay vì lý luận về nó.
Lặp lại cặp này sau khi kết nối lại, vì một đường hầm trở lại với tên giao diện khác có thể âm thầm vượt qua một quy tắc chỉ giới hạn cho cái cũ. Ranh giới quan trọng là cái mà máy chủ áp dụng cho những gói tin nó thực sự nhận.