デビット/クレジットピンパッド端末は15分後にネットワークから切断されます。1つのエラー後に再接続する

私たちはHPのプロカーブネットワークと、最近ではほぼすべての店舗で誰もが見慣れている約20の標準デビット/クレジットピンパッド端末を持っています。それらはLANに直接接続し、SSL / 443上の支払いサイトとのみ通信します。途中にソフトウェアやサーバーはありません。

問題は、デバイスが通常、最初に使用を試みたときにTCP接続障害を発生させることです。その後、1時間連続で問題なく動作します。ただし、アイドル状態を10〜15分間（約）許可すると、最初のエラーが1回スローされます。

当初、それらはすべて単一の会社からのものであり、それは彼らのセットアップ、またはメーカー/モデルと関係があると考えました。しかし最近、まったく異なるベンダーの新しいデバイスをいくつかのタイプのピンパッドを使用してインストールしましたが、同じエラーが発生します。

静的IPアドレスとDHCP IPアドレスを比較しました。外部の支払いサイトを特別なファイアウォールルールに追加し、通常の脅威チェックなしでユーザーが終了できるようにしました。さまざまなVLANで試してみました。私たちはそれらをさまざまなタイプのエリアスイッチに接続してみました。3分ごとにpingを実行するスケジュールされたバッチファイル（ホームメイドステイアライブ）も試しました。何も違いはありません。ネットワークの問題に関しては、デバイスはすべて、近くのキャッシュコンピューター/プリンターとまったく同じvlanとエリアスイッチに接続されており、他には何の問題もありません。キャッシュシステムは完全なクライアント/サーバー/データベースアプリを実行し、地域のネットワークが悪かったために同じ不快な問題が発生した場合は、すぐにそれを聞きます。

私がこれから取り組む最新の理論は、arpキャッシュタイムアウトに関連していますが、まだ始まったばかりです。

いくつかの援助をいただければ幸いです...クレイジーなアイデアも歓迎します。

W

私は過去に同様の問題を見たことがあります。私の問題は、NATデバイスを介して接続を確立しているデバイスに関連し、その接続が長時間アイドル状態のままでした（何も送信されず、何も受信されませんでした）。接続の両端はまったくわかりませんでしたが、中央のNATデバイスは、非アクティブのため接続を閉じることにしました。次に、トラフィックがNATを通過しようとしたときに、NATルールが存在しないため、パケットがドロップされていました。

デバイスが同様のことをしている可能性があります。私の解決策は、2つのデバイス間でキープアライブパケットを使用することでした。60秒ごとにパケットを送信し、これにより私の問題が解決されました（システムは、数年前から手を触れる必要なく稼働しています）。同じLANからどちらかのデバイスにpingを送信するだけでは、NATルールを維持するのに十分ではありませんでした。デバイスは定期的に相互に通信する必要があります。

ただし、特定のシステムについて詳しく知らなければ、これが当てはまるかどうかを判断するのは困難です。

お役に立てれば。

問題は、デバイスが通常、最初に使用を試みたときにTCP接続障害を発生させることです。その後、1時間連続で問題なく動作します。ただし、アイドル状態を10〜15分間（約）許可すると、最初のエラーが1回スローされます。

最初にお勧めするのは、マニュアルのコピーを入手するか、ベンダーに問い合わせて、デバイスが生成するエラーの意味を正確に説明することです。エラーが実際に別のことを意味していたときに、レイヤー3/4の問題を探すのに時間を無駄にしました。すべてのベンダーが用語を正しくまたは一貫して使用しているわけではありません。

デバイスが処理を送信していないか、キープアライブを正しく実行していないようです。TCP接続を通過するデータがない場合、最終的には閉じられます。これを防ぐには、1つのエンドポイント（または両方）がキープアライブパケットを送信して、接続が終了しないようにします。これはTCP（レイヤー4）で実行でき、おそらくSSL / TLS（レイヤー7）でも実行できることを知っています。

これらのデバイスの1つとインフラストラクチャの間に選択したパケットスニファを配置し、機能する時間から機能しない時間までのすべてのトラフィックを記録します。次に、それを調べて、接続先のデバイスまたはサーバーが終了シーケンスを開始している場所を見つけ、その直前に何があるかを確認します。また、デバイスが「TCP接続障害」エラーをスローした時点を確認してください。確立されていると思われるが、サーバーが終了していると考える接続を使用しようとしていますか？ここでも奇妙なことが起こっています-接続が確立されない場合、エラーをスローする代わりに、クレジットカードデバイスが新しいものを作成しようとします（2回目には正常に行われるようです）。

そして最後に、NATを使用している場合は、これらのデバイスの1つにテスト目的で直接非NAT接続を与えることを検討してください（ここでも、パケットキャプチャを実行します）。NATは、エンドツーエンドの原則に依存するアプリケーションやプロトコルに対して非常に奇妙なことを行う可能性があり、NATや、接続に干渉する他のステートフルデバイスの広範な使用を考慮に入れていません。

プロキシを使用している場合は、プロキシが含まれていないこと、またはプロキシがこれらのデバイスを処理するように正しく構成されていることを確認してください。ホストオペレーティングシステムのWPAD設定を使用するのに十分スマートなデバイスまたはプロセスがたくさんありますが、HTTP / HTTPS要求でそれらを実行しているユーザーアカウントのActive Directory資格情報を送信せず、プロキシはすべての接続が認証され、そのため、プロセスは静かにクライアント側で失敗します。