TL;DR

Oris Accounting აგდებს ერორს “HASP Error” No connection could be made because the target machine actively refused it. საჭიროა OrisHLM სერვისის სტატუსი შემოწმება და დასტარტვა.

პირველადი გამოძიება

მომხმარებელი აფიქსირებს პრობლემას: Oris Accounting არ ირთვება.

ეკრანზე ჩანს შეცდომა: HASP Error: No connection could be made because the target machine actively refused it 192.168.1.15:1961.

პირველ რიგში, შევამოწმოთ რომ ჰოსტი (ჩვენ შემთხვევაში 192.168.1.15) ჩართულია და ხელმისაწვდომია ქსელში. ვინაიდან მეორე ნაბიჯი იქნება გაშვებული სერვისების გადამოწმება, რისთვისაც სერვერზე შესვლა შეიძლება დაგვჭირდეს (RSAT თულების არ ქონის დროს) პირდაპირ რემოუთად ვცდილობთ დალოგინებას. თუ დალოგინება მოხერხდა ესეიგი ჰოსტი ჩართულია. თუ დალოგინება ვერ მოხერხდა დავიწყებთ გარკვევას, რატომ არაა ჰოსტი მიუწვდომელი

ჩვენ შემთხვევაში ჰოსტზე რემოუთ დესკტოპით შესვლა მოხერხდა ანუ ქსელის  L1-L3 დონის პრობლემები ამ ორისის სერვერთან გამოირიცხა. 

სიტყვა “HASP”-ის დანახვაზე, ინსტინქტი გკარნახობს, რომ შევამოწმოთ HASP License Manager სერვისი (hasplms). მაგრამ აქ ერთი ნიუანსია  hasplms სტანდარტულად უსმენს 1947 პორტს და ერორში სხვა კოდი ჩანს: 1961. Oris-ში შეცვალეს პორტი? მარტივად შევამოწმოთ:

netstat -ano | findstr: “1947”

პასუხად რამოდენიმე სტრიქონი გვიბრუნდება, გამოდის რომ ამ პორტს სისტემა აქტიურად უსმენს. მაღალი ალბათობით ეს hasplms-ია და არავის არ შეუცვლია მისი პორტი. მართალია რომ დავრწმუნდე ამაში, უნდა გავუშვა tasklist /fi “PID eq xxxx” სადაც xxxx არის Netstat-ის მიერ დაბრუნებული PID. მაგრამ ჩემი ინტუიცია მკარნახობს, რომ ჯობია გადავიდე თრაბლშუთინგის შემდეგ ეტაპზე.

შეცდომის სკრინზე არსებული actively refused ნიშნავს, რომ კლიენტმა გააგზავნა TCP SYN პაკეტი, მაგრამ დანიშნულების ჰოსტზე (ან ლოკალჰოსტზე) ამ კონკრეტულ პორტს არცერთი პროცესი არ უსმენს (არ არის LISTENING State-ში). Windows-ის TCP/IP სტეკი ასეთ დროს სტანდარტულად აბრუნებს Reset (RST) პაკეტს. შესაძლებელია პრობლემა ფაირვოლთან იყოს, მაგრამ ამ ეტაპზე უფრო ლოგიკურად მივიჩნევ პრობლემას პროგრამასთან

საბოლოო ჯამში ამ ეტაპისთვის ვადგენთ, რომ ჰოსტი (192.168.1.15) ცოცხალია, მაგრამ 1961 პორტზე სერვისი არ პასუხობს. ანუ პირველადი ჰიპოტეზა არის, რომ ორისის კლიენტი არა hasplms, არამედ სხვა სერვის უკავშირდება. როგორც ჩანს, კლიენტი მიმართავს რაღაც საკუთარ სერვისს (1961 პორტზე), რომელიც თავის მხრივ გადაამოწმებს ლიცენზიას HASP-თან (სავარაუდოდ). ვინაიდან Oris-ის სერვერული სერვისი გათიშულია, კლიენტი კავშირს ვერ ამყარებს, პანიკდება და გამოაქვს გენერალური “HASP Error”.

ჰიპოთეზის გადამოწმება

ახლა, როცა ვიცით რა უნდა ვეძებოთ, ვიწყებთ დიაგნოსტიკას.

  1. პორტის სტატუსის ვერიფიკაცია (Network Layer):
    ვამოწმებთ, მართლა ცარიელია თუ არა 1961 პორტი.
    netstat -ano | findstr “:1961”

    შედეგი: ცარიელი სტრიქონი. ჰიპოთეზა დადასტურდა — პორტს არავინ უსმენს.
  2. დამნაშავე სერვისის იდენტიფიკაცია (OS Layer): უნდა ვიპოვოთ Oris-ის სერვისი, რომელიც პასუხისმგებელია 1961 პორტზე. ვინაიდან ზუსტი სახელი არ ვიცით, ვეძებთ Pattern-ით. იმედი გვაქვს რომ სახელში ორისი ურევია. თუ ვერ ვიპოვეთ, შემდეგი გზა არის ორისის საპორტში დარეკვა (ან მკითხაობა :D)
    Get-Service -Name *oris* | Select-Object Name, DisplayName, Status

    შედეგი: სისტემამ დააბრუნა OrisHLM სერვისი, რომლის სტატუსია Stopped.

გამოსავალი და ვერიფიკაცია

ვიპოვეთ გათიშული სერვისი, ახლა უნდა გავუშვათ და დავრწმუნდეთ, რომ მან წარმატებით დაიკავა (Bind) თავისი პორტი.

  1. სერვისის გაშვება:
    Start-Service -Name “OrisHLM”
  2. შედეგის გადამოწმება
    არასდროს ენდოთ Start-Service-ის ჩუმ შესრულებას. შესაძლოა სერვისმა Crash განიცადოს Startup-ის დროს. ყოველთვის გადაამოწმეთ Socket-ის მდგომარეობა.
    netstat -ano | findstr “:1961”

    შედეგი: ვხედავთ ხაზს LISTENING სტატუსით 1961 პორტზე.
  3. შედეგის ვერიფიკაცია (სასურველი):
    შეგვეძლო ასევე tasklist /fi “PID eq xxxx” გვეცადა სადაც xxxx არის პროცესის PID. მაგრამ უფრო მარტივი გზით წავედი.

გავუშვი ორისი. ერორი აღარ ჩანს!

მორალი

უნდა იცოდეთ სტანდარტული პორტები და გადაამოწმოთ “საქმეში ჩართული” პორტები: პორტი 1947 HASP-ია, 1961 — არა. პორტების Listening-ის გადამოწმება საიმედო Troubleshooting-ის მეთოდია.