Thiết bị đầu cuối ghi nợ / tín dụng pinpad ngắt kết nối mạng sau 15 phút. Kết nối lại sau một lỗi


8

Chúng tôi có một mạng lưới mua sắm HP và khoảng 20 thiết bị đầu cuối pinpad ghi nợ / tín dụng tiêu chuẩn mà mọi người thường thấy ở mọi cửa hàng trong những ngày này. Họ kết nối trực tiếp với mạng LAN và chỉ liên lạc với một trang web thanh toán trên SSL / 443. Không có phần mềm hoặc máy chủ ở giữa.

Vấn đề là các thiết bị thường bị lỗi kết nối TCP trong lần sử dụng đầu tiên. Sau đó họ sẽ làm việc tốt trong một giờ. Nhưng, nếu được phép ngồi yên trong 10 - 15 phút (xấp xỉ), họ sẽ ném lỗi ban đầu một lần.

Ban đầu, tất cả họ đều đến từ một công ty duy nhất và chúng tôi nghĩ rằng nó có liên quan đến thiết lập của họ, hoặc kiểu dáng / mô hình. Nhưng gần đây, chúng tôi đã cài đặt một số thiết bị mới từ một nhà cung cấp hoàn toàn khác, sử dụng các loại pinpad khác nhau ... và chúng có cùng một lỗi.

Chúng tôi đã thử địa chỉ IP tĩnh so với DHCP. Chúng tôi đã thêm trang web thanh toán bên ngoài vào quy tắc tường lửa đặc biệt cho phép họ thoát mà không cần kiểm tra mối đe dọa thông thường. Chúng tôi đã thử chúng trên nhiều Vlans. Chúng tôi đã thử kết hợp chúng với các loại thiết bị chuyển mạch khu vực khác nhau. Thậm chí đã thử một tệp bó theo lịch trình mà ping chúng (nhà làm cho sống sót), cứ sau 3 phút. Không có gì làm cho bất kỳ sự khác biệt. Về các vấn đề mạng, tất cả các thiết bị đều được kết hợp với các vlans và khu vực chuyển đổi chính xác giống như các máy tính / máy in tiền mặt gần đó - và chúng tôi không gặp vấn đề gì với bất kỳ điều gì khác. Các hệ thống tiền mặt chạy các ứng dụng khách / máy chủ / cơ sở dữ liệu đầy đủ và nếu có vấn đề tương tự xảy ra với họ vì mạng trong khu vực rất tệ, chúng tôi sẽ nghe về nó nhanh.

Lý thuyết mới nhất tôi sắp giải quyết có liên quan đến thời gian chờ bộ đệm arp, nhưng tôi mới bắt đầu.

Sẽ đánh giá cao một số trợ giúp ... những ý tưởng điên rồ cũng được chào đón.

W.


7
Bắt đầu wiresharking :)
SpacemanSpiff

Tôi hoàn toàn đồng ý với đề nghị của wireshark. Các tuyến IP có bao giờ thay đổi? Họ có thực hiện các yêu cầu DNS (và đến đúng máy chủ không?) Họ có đang cố gắng gia hạn dhcplease không? Là phần mềm thậm chí thực hiện đúng yêu cầu ban đầu?
Stephan

Bạn có tường lửa đăng nhập lưu lượng truy cập vào trang web thanh toán ssl không?
Danie

Có một thiết bị Sonicwall ở đâu đó trong hỗn hợp?
ewwhite

Câu trả lời:


5

Tôi đã thấy một vấn đề tương tự trong quá khứ. Vấn đề của tôi liên quan đến thiết bị của tôi khi thiết lập kết nối thông qua thiết bị NAT và sau đó kết nối đó không hoạt động quá lâu (không gửi gì, không nhận được gì). Cả hai đầu của kết nối không có ý tưởng, nhưng thiết bị NAT ở giữa đã quyết định đóng kết nối vì không hoạt động. Sau đó, khi lưu lượng truy cập đang cố gắng vượt qua NAT, các gói tin đã bị hủy do quy tắc NAT không còn tồn tại.

Thiết bị của bạn có thể đang làm một cái gì đó tương tự. Giải pháp của tôi là sử dụng gói duy trì giữa hai thiết bị. Nó sẽ gửi một gói cứ sau 60 giây và điều này đã giải quyết được vấn đề của tôi (hệ thống đã chạy được vài năm nay mà không cần phải chạm vào). Chỉ cần ping một trong hai thiết bị từ cùng một mạng LAN là không đủ để giữ nguyên tắc NAT. Các thiết bị PHẢI nói chuyện với nhau thường xuyên.

Tuy nhiên, không biết thêm về các hệ thống cụ thể của bạn, thật khó để nói nếu điều này áp dụng cho bạn.

Hi vọng điêu nay co ich.


2

Vấn đề là các thiết bị thường bị lỗi kết nối TCP trong lần sử dụng đầu tiên. Sau đó họ sẽ làm việc tốt trong một giờ. Nhưng, nếu được phép ngồi yên trong 10 - 15 phút (xấp xỉ), họ sẽ ném lỗi ban đầu một lần.

Điều đầu tiên tôi muốn giới thiệu là lấy một bản sao của hướng dẫn hoặc nói chuyện với nhà cung cấp để có được lời giải thích về chính xác lỗi mà thiết bị tạo ra có nghĩa là gì. Tôi đã lãng phí thời gian để tìm kiếm các vấn đề của Lớp 3/4 khi lỗi thực sự có ý nghĩa khác. Không phải tất cả các nhà cung cấp sử dụng thuật ngữ chính xác hoặc nhất quán.

Có vẻ như các thiết bị không gửi xử lý hoặc thực hiện chính xác. Nếu không có dữ liệu truyền qua kết nối TCP của bạn, cuối cùng nó sẽ bị đóng. Để ngăn chặn một điểm cuối này (hoặc cả hai) có thể gửi các gói giữ nguyên để ngăn kết nối bị ngắt. Tôi biết điều này có thể được thực hiện với TCP (Lớp 4) và có lẽ nó cũng có thể được thực hiện với SSL / TLS (Lớp 7).

Đặt một gói sniffer lựa chọn giữa một trong những thiết bị này và cơ sở hạ tầng của bạn và ghi lại tất cả lưu lượng truy cập của nó từ khi nó hoạt động cho đến khi nó không hoạt động. Sau đó nhìn qua nó và tìm nơi thiết bị hoặc máy chủ mà nó kết nối đang bắt đầu trình tự kết thúc , sau đó xem điều gì xảy ra ngay trước đó. Ngoài ra, hãy xem thời điểm thiết bị gặp lỗi "lỗi kết nối TCP". Có phải nó đang cố gắng sử dụng một kết nối mà nó nghĩ là đã được thiết lập nhưng máy chủ cho rằng đã bị chấm dứt? Một cái gì đó kỳ lạ cũng đang xảy ra ở đây - nếu kết nối không được thiết lập, thay vì gây ra lỗi, thiết bị thẻ tín dụng của bạn sẽ cố gắng tạo một cái mới (dường như xảy ra thành công lần thứ hai).

Và cuối cùng nếu bạn đang sử dụng NAT, hãy cân nhắc việc cung cấp cho một trong các thiết bị này một kết nối trực tiếp, không phải NAT cho mục đích thử nghiệm (một lần nữa, hãy chụp gói). NAT có thể làm những điều rất lạ đối với các ứng dụng hoặc giao thức phụ thuộc vào Nguyên tắc từ đầu đến cuối và không sử dụng rộng rãi NAT hoặc các thiết bị trạng thái khác can thiệp vào kết nối.

Nếu bạn đang sử dụng proxy, hãy đảm bảo rằng nó không liên quan hoặc nó được cấu hình đúng để xử lý các thiết bị này. Chúng tôi có nhiều thiết bị hoặc quy trình đủ thông minh để sử dụng cài đặt WPAD của hệ điều hành máy chủ của họ nhưng không gửi thông tin xác thực thư mục hoạt động của tài khoản người dùng đang chạy chúng với các yêu cầu HTTP / HTTPS của họ và proxy hy vọng tất cả các kết nối sẽ được xác thực và vì vậy quá trình sẽ lặng lẽ thất bại phía khách hàng.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.