15 분 후에 직불 / 신용 핀 패드 터미널이 네트워크에서 분리됩니다. 한 번의 오류 후 다시 연결


8

우리는 HP 조달 네트워크와 요즘 거의 모든 매장에서 모든 사람들이 보는 데 사용되는 약 20 개의 표준 직불 / 신용 핀 패드 터미널을 보유하고 있습니다. 그들은 LAN에 직접 연결하고 SSL / 443의 지불 사이트와 만 통신합니다. 중간에 소프트웨어 나 서버가 없습니다.

문제는 일반적으로 장치를 처음 사용하면 TCP 연결이 실패한다는 것입니다. 그런 다음 한 시간 동안 제대로 작동합니다. 그러나 10-15 분 (약) 동안 유휴 상태로두면 초기 오류가 한 번 발생합니다.

처음에는 모두 단일 회사에서 왔으며 우리는 그것이 회사의 설정 또는 제조업체 / 모델과 관련이 있다고 생각했습니다. 그러나 최근에 다른 유형의 핀 패드를 사용하여 완전히 다른 공급 업체의 일부 새로운 장치를 설치했으며 동일한 오류가 있습니다.

정적 IP 주소와 DHCP IP 주소 지정을 시도했습니다. 외부 결제 사이트를 일반적인 방화벽 검사없이 종료 할 수있는 특수 방화벽 규칙에 추가했습니다. 우리는 다양한 Vlan에서 시도했습니다. 우리는 그것들을 다양한 유형의 영역 스위치에 연결하려고 시도했습니다. 매 3 분마다 핑 (집에서 만든 상태로 유지)하는 예약 된 배치 파일을 사용해 보았습니다. 아무것도 차이가 없습니다. 네트워크 문제와 관련하여 장치는 모두 근처의 현금 컴퓨터 / 프린터와 동일한 vlan 및 영역 스위치에 연결되어 있으며 다른 문제는 없습니다. 현금 시스템은 전체 클라이언트 / 서버 / 데이터베이스 앱을 실행하며 해당 지역의 네트워킹이 나빠서 동일한 불일치 문제가 발생한 경우 우리는 그 소식을 빨리들을 수 있습니다.

내가 다루려고하는 최신 이론은 arp cache timeouts와 관련이 있지만 시작하기 시작했습니다.

도움을 부탁드립니다 ... 미친 아이디어도 환영합니다.

W.


7
wiresharking 시작 :)
SpacemanSpiff

나는 wireshark 제안에 전적으로 동의합니다. IP 경로가 변경 되었습니까? 그들은 DNS 요청 (및 올바른 서버)을 수행합니까? dhcpleases를 갱신하려고합니까? 소프트웨어가 처음에 올바른 요청을하고 있습니까?
Stephan

방화벽에 트래픽을 SSL 결제 사이트로 로그인하도록 하시겠습니까?
Danie

믹스 어딘가에 Sonicwall 장치가 있습니까?
ewwhite

답변:


5

나는 과거에 비슷한 문제를 보았습니다. 내 문제는 내 장치가 NAT 장치를 통해 연결을 설정하는 것과 관련이 있으며 그 연결이 너무 오랫동안 유휴 상태로 유지되었습니다 (아무것도받지 못했습니다). 연결의 양쪽 끝은 전혀 몰랐지만 중간에있는 NAT 장치는 비 활동으로 인해 연결을 닫기로 결정했습니다. 그런 다음 트래픽이 NAT를 통과하려고 할 때 NAT 규칙이 더 이상 존재하지 않기 때문에 패킷이 삭제되었습니다.

장치가 비슷한 것을 수행하고있을 수 있습니다. 내 솔루션은 두 장치 사이에 연결 유지 패킷을 사용하는 것이 었습니다. 60 초마다 패킷을 보내면 문제가 해결되었습니다 (시스템을 몇 년 동안 만질 필요가 없었습니다). 동일한 LAN에서 두 장치 중 하나만 핑하는 것만으로는 NAT 규칙을 그대로 유지할 수 없습니다. 장치는 서로 정기적으로 대화해야합니다.

그러나 특정 시스템에 대해 더 많이 알지 못하면 이것이 적용되는지 말하기 어렵습니다.

도움이 되었기를 바랍니다.


2

문제는 일반적으로 장치를 처음 사용하면 TCP 연결이 실패한다는 것입니다. 그런 다음 한 시간 동안 제대로 작동합니다. 그러나 10-15 분 (약) 동안 유휴 상태로두면 초기 오류가 한 번 발생합니다.

내가 권장하는 첫 번째 것은 매뉴얼 사본을 얻거나 공급 업체에 문의하여 장치가 생성하는 오류가 무엇을 의미하는지 정확하게 설명하는 것입니다. 오류가 실제로 다른 것을 의미 했을 때 Layer-3 / 4 문제를 찾는 데 시간을 낭비했습니다 . 모든 공급 업체가 용어를 정확하거나 일관되게 사용하는 것은 아닙니다.

장치가 처리를 보내지 않거나 연결 유지를 올바르게 수행하지 않는 것 같습니다. TCP 연결을 통한 데이터 이동이 없으면 결국 닫힙니다. 이 하나의 끝점 (또는 둘 다)을 방지하기 위해 연결이 종료되지 않도록 연결 유지 패킷을 보낼 수 있습니다. TCP (Layer-4) 로이 작업을 수행 할 수 있으며 SSL / TLS (Layer-7)로도 가능하다는 것을 알고 있습니다.

이러한 장치 중 하나와 인프라 사이에 패킷 스니퍼를 선택하고 작동 시간부터 작동하지 않는 시간까지 모든 트래픽을 기록하십시오. 그런 다음 살펴보고 연결하는 장치 또는 서버가 종료 시퀀스를 시작하는 위치 를 찾은 다음 바로 앞에 나오는 것을 확인하십시오. 또한 장치에서 "TCP 연결 실패"오류가 발생하는 시점을 살펴보십시오. 연결이 설정되었다고 생각하지만 서버가 종료되었다고 생각하는 연결을 사용하려고합니까? 이상한 일이 여기에서도 발생합니다. 연결이 설정되지 않으면 오류를 발생시키는 대신 신용 카드 장치가 새로운 것을 생성하려고 시도해야합니다 (두 번째로 성공한 것 같습니다).

마지막으로 NAT를 사용하는 경우 이러한 장치 중 하나에 테스트 목적으로 NAT가 아닌 직접 연결을 제공하는 것이 좋습니다 (다시 패킷 캡처를 수행하십시오). NAT는 엔드 투 엔드 원칙 에 의존하는 응용 프로그램이나 프로토콜에 매우 이상한 일을 할 수 있으며 연결을 방해하는 널리 사용되는 NAT 또는 기타 상태 저장 장치를 고려하지 않습니다.

프록시를 사용하는 경우 프록시가 관련되지 않았거나 이러한 장치를 처리하도록 올바르게 구성되어 있는지 확인하십시오. 호스트 운영 체제의 WPAD 설정을 사용하기에 충분히 똑똑하지만 HTTP / HTTPS 요청으로 실행중인 사용자 계정의 활성 디렉토리 자격 증명을 제출하지 않는 많은 장치 또는 프로세스가 있으며 프록시는 모든 연결이 인증되고 프로세스가 클라이언트 측에서 조용히 실패합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.