Vì sao kết quả quét cổng thay đổi phía sau một lối ra VPN?

Chạy cùng một phép kiểm tra cổng từ một đường dây văn phòng và từ một lối ra VPN, và hai câu trả lời có thể không đồng ý về một địa chỉ mà không ai thay đổi. Khoảng cách đó đến từ tuyến đường và từ việc máy chủ nào đã trả lời, không phải từ việc dịch vụ đang chạy hay đã tắt. Ba câu hỏi tách những lời giải thích đó: đầu dò thực sự đã hỏi gì, máy chủ nào đã trả lời, và máy chủ của bạn đã ghi lại gì. Đi qua chúng theo thứ tự đó và viết ra từng câu trả lời trước khi chuyển sang câu tiếp theo.

Sửa đầu dò trước khi so sánh hai lần chạy

Một từ trạng thái chỉ so sánh được với một từ trạng thái khác khi cả hai cùng ra từ một thí nghiệm. Năm trường cố định điều đó: địa chỉ nguồn mà phía xa đã thấy, đích đã phân giải, cổng, kiểu quét và thời điểm. Thay đổi bất kỳ trường nào và bạn đã làm thí nghiệm thứ hai thay vì đo lần đầu hai lần.

Kiểm tra nguồn trước mọi thứ khác, vì một ứng dụng khách VPN có thể đang bật trong khi lưu lượng vẫn ra qua giao diện vật lý. Hỏi phía xa xem nó thấy gì, rồi hỏi nhân hệ điều hành đã chọn giao diện nào:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Hai địa chỉ trên các mạng khác nhau nghĩa là lời giải thích đã nằm trong tay, và phần còn lại của các phép kiểm tra này sẽ chỉ xác nhận nó. Khi chúng khớp nhau, hãy ghi lại đầu dò với cờ lý do bật, để trạng thái quay về gắn với một lời giải thích thay vì đứng một mình như một từ trần trụi. Kiểu quét cũng thuộc về bản ghi đó, vì nó mô tả điều đã được hỏi, không phải điều đã trở về. Một trạng thái không có nguồn, không có phương pháp và không có dấu thời gian thì không thể so với bất cứ thứ gì:

nmap -sT -p 443,8443 --reason 203.0.113.20

Giữ đầu ra đó bên cạnh bản ghi chứ không phải trong bộ đệm cuộn mà người tiếp theo không thể thấy. Hai lần quét trung thực không đồng ý chỉ là tranh cãi khi không ai viết ra các điều kiện. Khi các điều kiện đã cố định, hoặc kết quả khớp nhau và câu hỏi đóng lại, hoặc chúng khác nhau và sự khác biệt là một thực tế về tuyến đường.

Tìm ra máy chủ nào đã hoàn tất cú bắt tay

Một cú bắt tay hoàn tất chứng minh rằng một máy chủ nào đó đã hoàn tất nó, và máy chủ đó không nhất thiết là tiến trình bạn đang nghĩ tới. Một bộ cân bằng tải, một proxy ngược hoặc một proxy SYN có thể trả lời trước khi máy chủ thật tham gia, đó là thiết kế thông thường chứ không phải triệu chứng. Chứng chỉ hợp lệ cho tên mong đợi cũng không thu hẹp điều này, vì chứng chỉ mô tả quan hệ dịch vụ và không nói gì về việc máy nào đã kết thúc kết nối.

Tài liệu tham chiếu về trạng thái cổng của Nmap coi đây là điều cơ bản: một trạng thái ghi lại điều đầu dò có thể quan sát từ nơi nó được gửi đi, không phải một thuộc tính của cổng. Đọc một từ trạng thái theo cách đó và hai lần chạy từng không đồng ý bắt đầu trông nhất quán thay vì mâu thuẫn, trong khi câu hỏi chuyển từ việc cổng có mở hay không sang việc ai đang đứng trước nó.

Trả lời câu hỏi thứ hai ở phần phụ trợ chứ không phải từ bên ngoài. Một giao diện đầu không nhận kết nối rồi không tới được thượng nguồn của nó tạo ra đúng hình ảnh bên ngoài của một dịch vụ khỏe mạnh với ứng dụng chậm. Chỉ bản ghi của chính thượng nguồn mới tách hai trường hợp:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

Dòng nhật ký cho thấy địa chỉ khách mà ứng dụng thực sự đã thấy, và lệnh thứ hai cho thấy tiến trình giữ cổng 443 là ứng dụng của bạn hay là thứ gì đó đứng trước nó. Nếu hai bên không đồng ý về việc địa chỉ nào đã kết nối, bạn đang nhìn hai chân của một yêu cầu và phiếu sự cố nên nói như vậy.

Kiểm tra quy tắc của chính bạn trước khi đổ lỗi cho đường hầm

Chính sách có chủ đích là lý do phổ biến nhất khiến một cổng trả lời trên mạng này mà không trên mạng khác, và đó là lời giải thích kém thú vị nhất hiện có. Các quy tắc truy cập tồn tại để cho phép một nguồn và bỏ phần còn lại, nên việc thay đổi lối ra chính là sự kiện mà chúng được viết ra để xử lý. Vì vậy một trạng thái khác đi qua VPN không chứng minh rằng nhà cung cấp đang kiểm tra lưu lượng. Nó cho thấy địa chỉ nguồn của bạn giờ đã khác, đó là một tuyên bố nhỏ hơn nhiều.

Những quy tắc đó đọc được trên máy chủ, nên hãy đọc chúng thay vì suy đoán về phần giữa của mạng. Liệt kê các quy tắc lọc có nhắc tới một trong hai dải địa chỉ, rồi kiểm tra xem kết nối có tới được tiến trình nền hay không:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Một kết quả thứ hai trống rỗng là có thông tin, vì không có gì tới được tiến trình nền và câu hỏi thuộc về một bộ lọc, một nhóm bảo mật hoặc chính tuyến đường. Một lần trúng nghĩa là dịch vụ đã thấy nguồn của bạn và chọn câu trả lời của nó, và quyết định đó thường được ghi trong một quy tắc bạn có thể đọc. Không kết quả nào ủng hộ một câu chuyện về nhà cung cấp, và cả hai đều rẻ hơn để kiểm tra so với việc bắt gói tin.

Đọc riêng phần vận chuyển, chứng chỉ và phản hồi

Ba lớp tạo ra ba quan sát, và một đầu dò kiểm tra một trong số đó không thể báo cáo về hai cái còn lại. Giữ chúng thành những dòng riêng trong bản ghi thay vì gấp chúng vào một phán quyết duy nhất, vì mỗi dòng thất bại theo cách của nó và cách thất bại cho bạn biết nên nhìn ở đâu tiếp theo.

Một lệnh duy nhất tạo ra ba dòng đầu tiên đối với một dịch vụ bạn kiểm soát. Đặt đầu ra của nó vào bản ghi bên cạnh lần quét chứ không phải trong tin nhắn trò chuyện:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Đọc đầu ra theo thứ tự: cú bắt tay trả lời câu hỏi vận chuyển, chủ thể chứng chỉ trả lời câu hỏi tên, và phần thân phản hồi trả lời câu hỏi ứng dụng. Khi dòng bắt tay thành công mà dòng phản hồi thì không, bạn có một giao diện đầu với thượng nguồn hỏng chứ không phải một cổng bị chặn. Đó là một phiếu khác với phiếu bạn đã mở, và đáng để nói thẳng ra.

Kết thúc bằng việc ghi bốn sự thật vào phiếu: địa chỉ nguồn, kiểu quét, máy chủ đã trả lời và thời điểm. Mọi thứ một so sánh sau này cần đều sống trong bốn điều đó, và người nhận vụ việc tiếp theo sẽ không có lịch sử đầu cuối của bạn. Nếu bạn không điền được cả bốn, lần chạy chưa xong.