DNS-ul la distanță poate rezolva o problemă de căutare a destinației și totuși vă poate lăsa fără posibilitatea de a vă conecta. Clientul trebuie mai întâi să găsească proxy-ul.

Luați în considerare un punct final numit proxy.office.example. Trimiterea unui nume de gazdă de site web prin SOCKS nu îi spune clientului cum să obțină adresa acelui punct final inițial. Conversația SOCKS nu a început încă.

Acest lucru contează atunci când numele proxy-ului aparține unui spațiu de nume privat. Un resolver de acasă s-ar putea să nu îl cunoască, în timp ce un resolver din rețeaua de birou aprobată îl cunoaște. Un nume scurt de proxy poate depinde și de configurația domeniului de căutare, care diferă între rețele.

Țineți numele separate

  • Numele punctului final al proxy-ului este necesar pentru a stabili prima conexiune.
  • Numele site-ului web poate fi transportat în cererea de proxy acceptată pentru rezolvare la distanță.

Notați care nume a eșuat înainte de a schimba resolverul. Înlocuirea DNS-ului clientului cu un serviciu public nelegat poate face un nume privat de proxy mai puțin accesibil, nu mai mult. Folosiți configurația de rezolvare a numelor acceptată de rețeaua dorită.

Un IP de proxy alocat poate elimina o căutare de nume de gazdă în unele aranjamente, dar nu este universal interschimbabil cu numele. TLS către un proxy HTTPS și autentificarea bazată pe nume pot depinde de identitatea așteptată. Păstrați acea identitate intactă în loc să îi dezactivați verificările.

Odată ce prima conexiune funcționează, investigați separat etapa destinației. Un nume de gazdă de proxy funcțional nu dovedește nici că proxy-ul cunoaște numele site-ului, nici că are voie să se conecteze acolo.

Articole similare