ტელეფონი გვერდს ვერ ხსნის: შეამოწმეთ მოსმენის მისამართი
localhost-ზე პასუხის მიმცემი გვერდი შესაძლოა მხოლოდ loopback-ზე იყოს მიბმული. წაიკითხეთ socket-ის მისამართი, შემდეგ firewall-ის წესი და URL, რომელსაც ტელეფონი რეალურად იყენებს.
ლეპტოპი გვერდს localhost-ზე ამარაგებს, ტელეფონი იმავე VPN-ს უერთდება, და ტელეფონის ბრაუზერი იტყობინება, რომ საიტამდე მისვლა შეუძლებელია. გვირაბში ჯერ არაფერია არასწორი, რადგან გვირაბი მხოლოდ პაკეტებს აწვდის. loopback ინტერფეისზე მიბმული დეველოპმენტ სერვერი არასოდეს იღებს სხვა რამეზე მიმართულ კავშირს, ამიტომ პირველი ადგილი, სადაც უნდა შეხედოთ, მოსმენის socket-ია და არა VPN.
გაიარეთ socket-ი, bind-ის პარამეტრი, firewall-ის წესი და URL ზუსტად ამ თანმიმდევრობით.
socket-ი უფრო ვიწრო კითხვას პასუხობს
127.0.0.1-ზე შექმნილი მსმენელი იღებს ტრაფიკს თავად მანქანიდან და უარყოფს ყველაფერს, რაც სხვა მისამართზე მოდის. wildcard მისამართზე მყოფი მსმენელი იღებს ყველა ლოკალურ ინტერფეისზე, VPN ინტერფეისის ჩათვლით, რაც უფრო ფართოა, ვიდრე დეველოპმენტის გარემოების უმეტესობას სჭირდება. ერთ კონკრეტულ VPN მისამართზე მიბმული მსმენელი ყველაზე ვიწრო სასარგებლო ვარიანტია და მუშაობს მხოლოდ მანამ, სანამ ეს მისამართი არსებობს.
აქედან ორი სახელდების ხაფანგი გამომდინარეობს. ტელეფონის ბრაუზერში localhost ნიშნავს ტელეფონს და არა ლეპტოპს. wildcard მისამართი bind-ის მნიშვნელობაა და არა რამე, რაც URL-ში უნდა ჩაიწეროს. ვინც ერთ-ერთი მათგანით შეამოწმებს, შეატყობინებს წარუმატებლობას, რომელშიც ქსელი საერთოდ არ მონაწილეობდა.
IPv6 მესამე შემთხვევას ამატებს, რადგან socket-ს შეუძლია მიიღოს IPv4 და IPv6 ადვილად გამოსაშვები პარამეტრებიდან გამომდინარე. წაიკითხეთ მისამართების ოჯახი სიაში. ერთი ოჯახის wildcard ჩანაწერი მეორეს არ აღწერს.
წაიკითხეთ მოსმენის მისამართი
შეისწავლეთ socket-ი კონფიგურაციის შეცვლამდე. ლოკალური მისამართი, პორტი და მფლობელი პროცესი ერთად განსაზღვრავს, არის თუ არა სერვერი საერთოდ ხელმისაწვდომი VPN-იდან.
Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess ipconfig | Select-String -Pattern 'IPv4' Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action
127.0.0.1 ლოკალური მისამართი კითხვას წყვეტს: firewall-ის ვერცერთი ცვლილება არ დაეხმარება, რადგან აპლიკაცია VPN ინტერფეისზე არ უსმენს. wildcard ან VPN მისამართი ნიშნავს, რომ socket-ი რიგზეა და შემდეგი საზღვარი მოქმედებს.
ადასტურეთ მფლობელი პროცესიც, რადგან ჩვეულ პორტზე მყოფმა უკავშირო სერვისმა შეიძლება ცხრილი სწორად აჩვენოს, მაშინ როცა განკუთვნილი სერვერი არასოდეს გაშვებულა. შეადარეთ შესრულებადი ფაილის გზა და არა მხოლოდ სახელი. წინა გაშვებიდან დარჩენილი მოძველებული პროცესი ხშირი თვითმარქვიაა.
შეცვალეთ bind აპლიკაციის მეშვეობით
გამოიყენეთ framework-ის დოკუმენტირებული მოსმენის მისამართის პარამეტრი და გადატვირთეთ პროცესი. თუ ლეპტოპს ეკუთვნის კერძო მისამართი 10.77.0.1, ტელეფონის URL გახდება http://10.77.0.1:8080/ და ეს მისამართი VPN-ის გავლით უნდა იყოს მარშრუტიზებული; პარამეტრებში სხვა არაფერი იცვლება.
არ დაამატოთ თვითნებური მისამართები Windows-ში და არ შეცვალოთ გეითვეი bind-ის იძულებისთვის. ეს ცვლილებები გადარჩება გამართვის სეანსს და გააოცებს შემდეგ ადამიანს. VPN მისამართის არსებობამდე გაშვებული სერვერიც შეიძლება ვერ მიბმულიყოს, ამიტომ გარდამავალი ინტერფეისისთვის გაშვების რიგი მნიშვნელოვანია. მიეცით მას ხელახალი ცდა ან გაუშვით გვირაბის შემდეგ. ჩატვირთვისას bind-ის წარუმატებლობა მეორე დილით ზუსტად firewall-ის პრობლემას ჰგავს.
HTTPS-ისთვის შეინარჩუნეთ სერვისის ჰოსტის სახელი და სერტიფიკატის შემოწმება უცვლელად. ნედლ მისამართზე სერტიფიკატის გაფრთხილება სახელდების პრობლემაა და არა დაწკაპუნებით გადასავლელი ნაბიჯი, და კერძო DNS უნდა შეესაბამებოდეს თქვენ მიერ არჩეულ მსმენელს.
გახსენით ერთი წესი და არა მთელი ქსელი
როგორც კი socket-ი VPN მისამართზე მიიღებს, firewall-ი წყვეტს, მოვა თუ არა მოთხოვნა. შეზღუდეთ წესი ამ აპლიკაციაზე, ამ პროტოკოლზე, ამ ლოკალურ პორტზე და ავტორიზებულ დისტანციურ წყაროზე, და დაადასტურეთ, რომელი პროფილია აქტიური VPN ადაპტერზე.
გამოიყენეთ ის წყაროს მისამართი, რომელსაც Windows რეალურად ხედავს, მათ შორის გეითვეის მიერ შესრულებული ნებისმიერი ტრანსლაცია, რადგან საწყისი კლიენტის მისამართისთვის დაწერილი წესი ტრანსლირებულს არ დაემთხვევა.
გვერდი, რომელიც იტვირთება და აპლიკაციის შეცდომას აჩვენებს, პროგრესია: HTTP-ის უარყოფა განსხვავებული წარუმატებლობაა, ვიდრე TCP კავშირის არარსებობა, და შემდეგი გამოძიება ეხება თავად აპლიკაციის წვდომის პოლიტიკას და არა ქსელს.
დაასრულეთ გვერდის განკუთვნილი ტელეფონიდან მოთხოვნით და დადასტურებით, რომ გამორიცხული მოწყობილობა კვლავ ვერ აღწევს მას. მომუშავე მსმენელი ყველაფრის დამშვები წესით იგივე შედეგი არ არის.