Các kết nối TCP của tôi có bị phá hoại bởi chính phủ nước tôi không?

Tôi nghi ngờ rằng chính phủ nước tôi đang phá hủy gói ACK nhận được trên các kết nối TCP, bằng cách nào đó.

Khi tôi cố gắng thiết lập kết nối TCP với máy chủ bên ngoài trên các cổng khác ngoài 80, bắt tay TCP sẽ không thành công. Tôi đã chụp tệp pcap (gmail.pcap: http://www.slingfile.com/file/aWXGLLFPwb ) và tôi phát hiện ra rằng máy tính của tôi sẽ nhận được ACK sau khi gửi TCP SYN nhưng thay vì trả lời bằng SYN ACK, nó sẽ gửi một RST.

Tôi đã kiểm tra gói ACK từ máy chủ bên ngoài, nhưng có vẻ như hoàn toàn hợp pháp. Số thứ tự và tất cả các cờ mà tôi biết, là chính xác. Ai đó có thể cho tôi biết tại sao máy tính của tôi (một máy linux) sẽ gửi gói RST không?

ảnh chụp màn hình pcap

— Mohammad
nguồn

Chúng tôi có thể hỏi như nước nào?

— Kev

Tôi cố tình không đề cập đến nó. Nhưng bây giờ khi bạn hỏi, tôi không thể nghĩ ra lý do tại sao không nói. Đây là một trong những vấn đề hàng ngày của tôi ở Iran.

— Mohammad

Là chụp được lấy từ máy của bạn đang cố gắng thiết lập kết nối?

— the-wợi

Đúng. Tôi thực thi tcpdump -w gmail.pcap và sau đó telnet gmail.com 443.

— Mohammad

telnet sẽ không hoạt động, bạn cần xem câu trả lời của tôi dưới đây :-)

— The

Câu trả lời:

Từ dòng cmd:

openssl s_client -connect serveryourtryingtocontact.com:443

Điều này sẽ xác minh nếu bạn có thể kết nối SSL với máy chủ từ xa. Có lẽ làm cho một Wireshark của giao thông này.

Nếu bạn không có openssl, thì bạn có thể apt-get install openssl.

Chúng ta phải xác định nơi RST đang được tạo. Nó có xảy ra với tất cả các trang web SSL không? Bạn có kết nối trực tiếp với NAT-gateway không? Bạn đang sử dụng proxy?

Sử dụng phương pháp này sẽ loại bỏ mọi vấn đề với ngăn xếp SSL của bạn.

— Bộ xử lý Unix
nguồn

Vấn đề không phải là SSL. Đó là TCP. Kết nối TCP sẽ không được thiết lập ở vị trí đầu tiên, do đó SSL thậm chí sẽ không bắt đầu gửi tiêu đề của nó. đó không chỉ là số cổng 443, ví dụ tôi thậm chí không thể bắt đầu kết nối http bình thường với máy chủ trên cổng 8000 và lệnh openssl của bạn sẽ dẫn đến "kết nối: Đã hết thời gian kết nối"

— Mohammad

Mặc dù thỉnh thoảng, tin đồn của Iran có thể phá vỡ HTTPS, nhưng từ dữ liệu bạn đã cung cấp, nó trông giống như gói SYN, gói ACK từ 173.194.32.22 đang đến máy chủ của bạn, nhưng không bao giờ chuyển đến ngăn xếp TCP của bạn. Ngăn xếp thử lại gửi các SYN sau một giây, hai giây, bốn giây và tám giây một cách trân trọng - nhưng dường như không bao giờ thấy phản hồi.

SYN, ACK đến dường như được lọc - bạn không có iptablesquy tắc nào cho lưu lượng truy cập tcp trong chuỗi INPUT của bạn có REJECT --reject-with tcp-resetmục tiêu nào?

— the-wợi
nguồn

Không, iptables của tôi hoàn toàn không có bất kỳ quy tắc nào và trên một lưu ý khác tôi phải nói rằng tôi có thể thiết lập kết nối TCP thành công cho bất kỳ máy chủ nào bên trong iran hoặc thậm chí một vài trang web nước ngoài (thực sự chỉ có kernel.org!)

— Mohammad

Tôi đoán là chính phủ đang thay đổi gói thứ hai (SYN / ACK) nên gói không hợp lệ và do đó nó không bao giờ được chuyển sang ngăn xếp TCP.

— Mohammad

@Mohammad Gói tin hợp lệ. Ngay cả khi không, ngăn xếp sẽ không thực hiện cả hai: trả lời bằng RST và tiếp tục như thể nó chưa được nhận. Một cái gì đó đang bắt nó trên đường đến ngăn xếp. Tôi khuyên bạn nên khởi động một bản cài đặt đã biết (ví dụ: đĩa CD Linux trực tiếp) và chạy lại các bài kiểm tra

— the-wợi

Cảm ơn bạn. Tôi cũng không thể tìm thấy bất kỳ vấn đề nào với gói ACK. Nhưng vấn đề là vấn đề này xảy ra mỗi ngày (từ 4 ngày trước) vào buổi sáng tại nơi làm việc của tôi! Mọi người (khoảng 50 người) đều có cùng một vấn đề và tôi vẫn tự hỏi tại sao? Tôi không có vấn đề tương tự ở nhà nhưng tôi nghe bạn bè của tôi nói rằng Internet có vấn đề nghiêm trọng những ngày này.

— Mohammad

@Mohammad kiểm tra phần mềm độc hại rồi. Chạy một bản cài đặt đã biết như đã đề xuất ở trên là một thử nghiệm dễ dàng và quan trọng cho trường hợp này.

— the-wợi