Filtrarea DNS prin VPN a oprit încărcarea unui site: citiți răspunsul
Un resolver care filtrează poate bloca un singur nume în timp ce tunelul funcționează. Citiți tipul răspunsului, aflați cine deține resolverul și schimbați doar ce controlați.
Un nume eșuează în timp ce tunelul este activ, iar browserul numește asta eroare de rețea, deși cauza reală este răspunsul DNS pe care resolverul l-a returnat. Un resolver care filtrează poate reține, refuza sau rescrie un singur nume și lăsa toate celelalte interogări să funcționeze. Tunelul transportă interogarea; resolverul decide răspunsul. Examinați acel răspuns înainte de a atinge setările de criptare.
Tunelul este activ, deci criptarea nu este suspectul
Starea conexiunii spune dacă pachetele se mișcă, nu dacă un nume se rezolvă. Rezolvarea este o interogare către serverul cu care clientul este configurat, iar o politică de acolo poate răspunde unui domeniu altfel decât tuturor celorlalte. Din partea browserului toate acele răspunsuri se topesc într-o eroare generică, de aceea indicatorul de stare dovedește atât de puțin.
Notați mai întâi trei lucruri: resolverul pe care l-a folosit clientul, codul de răspuns pentru numele care eșuează și aceeași interogare pentru un nume care ar trebui să funcționeze. Întrebați resolverul direct cu dig example.com @10.20.0.1 și citiți linia de stare, nu mesajul browserului. Dacă numele de control se rezolvă, iar cel care eșuează returnează un răspuns de politică, dovada este completă. Dacă ambele eșuează, filtrul nu este încă implicat.
Patru răspunsuri, patru proprietari diferiți
Un resolver care filtrează nu are o singură modalitate de a spune nu, iar forma refuzului indică un alt pas următor. Notați codul de răspuns, pentru că browserul rescrie toate patru în ceva ce sună ca o conexiune întreruptă.
| Answer | What it points at |
|---|---|
| NXDOMAIN | The name is withheld: a policy entry or a zone decision removed it |
| Refused | The resolver declines to answer; usually an access or policy rule |
| Replacement address | A redirect to a block page or sinkhole you can query and inspect |
| No answer at all | Weakest evidence: reachability, load or routing, not necessarily policy |
Comparați răspunsul cu tabelul înainte de a atribui ceva tunelului. Un refuz și un nume reținut înseamnă amândouă că resolverul a luat o decizie, în timp ce tăcerea înseamnă că interogarea nu a primit niciodată răspuns. Această diferență decide dacă urmăriți un proprietar de politică sau o cale de rețea.
Două browsere pot urma două politici
Un browser care își aduce propriul resolver criptat nu trebuie să folosească serverul pe care sistemul de operare îl distribuie, așa că poate ignora politica pentru care a fost construit tunelul. Atunci două browsere de pe aceeași mașină nu sunt de acord asupra aceluiași nume de gazdă, și niciunul nu este stricat. Verificați la ce resolver este legată fiecare aplicație înainte de a numi filtrul inconsecvent.
Când ambele aplicații folosesc resolverul tunelului și doar una eșuează, diferența este în aplicație, nu în DNS. Notați adresa resolverului pentru fiecare aplicație, pentru că acel detaliu dispare când fereastra se închide.
Schimbați ce dețineți, escaladați ce nu dețineți
Următorul pas depinde de cine deține resolverul către care indicați. Unul pe care îl rulați singur este o funcție pe care o puteți citi și configura: verificați opțiunea de filtrare documentată și excepțiile ei, apoi permiteți acel singur nume. Unul pe care îl rulează angajatorul sau furnizorul este un tichet cu domeniul, răspunsul exact și ora.
Nu înlocuiți niciodată cu un resolver public pentru a forța deschiderea site-ului, pentru că numele private nu mai sunt rezolvate și o politică deliberată nu se mai aplică. Schimbarea îngustă păstrează și dovada intactă, astfel încât proprietarul să poată compara raportul cu propriile înregistrări. După schimbare, repetați testul original al aplicației în loc de o interogare dintr-un shell.
O pagină de blocare nu este un certificat de încredere
O pagină de substituție care își prezintă propriul certificat va ridica o avertizare de identitate HTTPS, iar redirecționarea nu face acel certificat valid. Nu faceți clic prin ea doar pentru că tunelul este activ; avertizarea este o decizie de încredere separată care tot trebuie să fie corectă.
Diagnosticul se închide când numele care eșuează returnează un răspuns de politică și un nume de control returnează unul normal prin același resolver. În acel moment reparația este o schimbare de politică, nu de tunel, iar RFC 1035 codurile de răspuns sunt ceea ce citați în raport. Țineți ambele nume și răspunsurile împreună; acesta este tot cazul.