înregistrare Logare
Puncte:5
avatar Server

Browserul meu nu va afișa http://[sub.]example.com

drapel cn
Bob

Cand merg la http://sub.example.com în browser-ul meu primesc un "conexiune refuzata" mesaj sau un "certificat invalid" eroare, dar nici nu vreau să mă conectez prin https.

După cum știu:

  • Serverul web este configurat corect pentru sub.exemplu.com
  • Portul TCP 80 este deschis în grupurile de firewall/securitate
  • HTTP simplu și nu HTTPS este folosit în URL
  • înregistrarea DNS pentru sub.exemplu.com indică adresa IP corectă a serverului web
  • serverul web a fost repornit cu o nouă configurație
  • jurnalele nu arată pornirea sau alte erori

Cum pot depana și care este problema acolo?

1718
0 + 0
Puncte:19
avatar Server
drapel cn
Bob

Primul lucru de care trebuie să fii conștient este că browserele web moderne ar putea să nu fie cel mai bun instrument pentru depanarea problemelor precum acestea. Browserul poate fi chiar cauza acestora, deoarece serverul poate fi configurat complet corect și problema poate fi 100% partea clientului.

Continut:

  • testare (cu răsuci și browser incognito/anonim)
  • ambele teste afișează conținutul așteptat
  • răsuci face, dar fereastra browserului privat nu afișează conținutul corect
  • niciunul dintre teste nu afișează conținutul așteptat

testarea

Încercați să nu testați doar cu FQDN-ul http://sub.example.com dar utilizați o adresă URL mai completă, cum ar fi http://sub.example.com/some-page.html. Când știți că vă aflați în spatele unui proxy, adăugarea de parametri suplimentari va ocoli, de obicei, conținutul stocat în cache, adică adăugați și incrementați un contor, cum ar fi http://sub.example.com/some-page.html?test=3

  • testați dintr-o fereastră de browser „Privat/Incognito”.
    Acest lucru reduce șansele de a trage concluzii incorecte pe baza obiectelor din cache.

  • testați dintr-o linie de comandă (pe un server de testare) cu, de exemplu curl -vv http://sub.example.com/some-page.html sau utilizați telnet și emulați o solicitare web cu

    telnet sub.example.com 80

    GET /some-page.html HTTP/1.1
    Gazdă: sub.example.com

Lucruri de căutat în răsuci ieșire:

  • Setările proxy sunt cu siguranță un semn de pericol și o piedică reală la depanarea problemelor serverului. Serverele proxy pot stoca în cache (înregistrări DNS și conținut web), vă pot restricționa accesul și chiar pot înlocui certificatele TLS.

    curl -vv http://sub.example.com/some-page.html
* Utilizează variabila proxy env no_proxy == 'localhost,127.0.0.1,.corp.example.net'
* Utilizează variabila de mediu proxy http_proxy == „http://[utilizator]:[pass]@proxy.corp.example.net:8080/”
* Încercați 10.2.0.80:8080...
           ^^^ Pericol - Server proxy

  • Testați din (testare) sistem care nu se bazează pe un server proxy dacă doriți să testați corect configurația unui server web de internet. De obicei, nu am sisteme de testare care să accepte un browser complet, dar de obicei pot gestiona un sistem care va rula comenzi curl dintr-o linie de comandă.

    curl -vv http://sub.example.com/some-page.html
* Pe cale de conectare() la portul sub.example.com 80 (#0)
* Se încearcă 192.168.2.119...
* Conectat la sub.example.com (192.168.2.119) portul 80 (#0)
                                ^^^ VERIFICAȚI dacă aceasta este adresa IP corectă 
                                    al serverului dvs. web?
> GET /some-page.html HTTP/1.1
> User-Agent: curl/7.29.0
> Gazdă: sub.example.com
> Accept: */*

Acolo observați că o conexiune se stabilește cu succes la adresa IP și portul corecte ale serverului web. The > markerul precede anteturile cererii făcute de curl.

Antetele de răspuns ale serverului sunt marcate cu a < marker și apoi după o linie goală corpul răspunsului este trimis de server:

< HTTP/1.1 302 Găsit
  | ^^^ Codul de răspuns HTTP STATUS al serverului 
   `^^ versiunea protocolului HTTP

< Data: Luni, 07 Feb 2022 13:58:11 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< Locație: https://sub.example.com/some-page.html
< Lungimea conținutului: 216
< Content-Type: text/html; set de caractere=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
...

După primul antet de protocol HTTP/1.1 vine cel Cod de stare HTTP serverul generează. Acolo un 2xx răspuns înseamnă o formă de succes, 3xx răspunsurile sunt redirecționări (văzute aici), 4xx și 5xx sunt erori.

Dintre celelalte antete serverul trimite Locație: în acest exemplu indică ținta unui răspuns de redirecționare.

ambele teste afișează conținutul așteptat

Concluzie: Serverul web este configurat corect și problema este legată de browser.

Cel mai probabil cauză: este posibil să fi fost configurată o redirecționare permanentă înainte ca configurația serverului web să fie schimbată și redirecționările permanente (301) sunt stocate în cache de browsere. Destul de obișnuite sunt redirecționările rupte în cache sau redirecționările în cache către https și fără certificat și site-ul https pentru sub.exemplu.com este configurat încă.

Rezoluția 1: Goliți memoria cache a browserului și site-ul ar trebui să se încarce așa cum era de așteptat.
Rezoluția 2: Obțineți un certificat SSL pentru sub.example.com și activați TLS.

Cauza 2: Nu chiar aceeași cauză principală, dar cauze și efect similare efectiv cu o redirecționare în cache către https, a HTTP Strict Transport Security (HSTS) care este stabilită de exemplu.com domeniul este aplicabil și pentru toate subdomeniile (noi) ale example.com. Orice browser rezonabil de modern stochează și respectă politicile HSTS și va refuza să se conecteze prin http simplu la portul 80 și va rescrie în tăcere http://sub.example.com URL către https://sub.example.com și încercați să vă conectați la portul 443 cu TLS.

Rezoluţie: obțineți un certificat SSL pentru sub.example.com și activați TLS.
Ștergerea memoriei cache a browserului HSTS poate funcționa temporar, dar aceasta este eficientă numai atunci când eliminați și politica include subdomenii HSTS din example.com, ceea ce nu este recomandat.

răsuci face, dar fereastra browserului privat nu afișează conținutul corect

Concluzie: Serverul web este configurat corect și problema este legată de browser sau client.

Cauza 1: Nu chiar aceeași cauză rădăcină, dar cauze și efect similare efectiv cu cele stocate în cache HTTP Strict Transport Security politica (HSTS) este a domeniu din lista de pre-încărcare HSTS. Dar acolo unde politicile HSTS memorate în cache nu ar trebui respectate într-o fereastră „Privată/incognito”, lista de preîncărcare HSTS ar trebui să se aplice întotdeauna, chiar și în ferestrele private/incognito.

Consultați aceste întrebări și răspunsuri pentru o prezentare generală despre cum să determinați dacă domeniul dvs. sau TLD-ul dvs. se află pe lista de preîncărcare HSTS:
Lista de domenii de nivel superior (TLD-uri) care necesită conexiuni HTTPS, cum ar fi .dev

Rezoluţie: obțineți un certificat SSL pentru sub.example.com și activați TLS.

Cauza 2: deși înregistrările DNS sunt configurate corect, soluția clientului, desktopul pe care rulează browserul dvs., poate indica o adresă IP diferită. Verificați cu de exemplu nslookup și săpa ce rezolvă serverul de nume de client și că nu uitați că a fișier hosts intrarea pentru sub.example.com va suprascrie DNS.

Rezoluţie: eliminați fișier hosts intrare pentru sub.example.com sau investigați în continuare discrepanța DNS.

niciunul dintre teste nu afișează conținutul așteptat

Concluzie: Problema este la server, nu la client.

Niciun raspuns

A se referi la Ce cauzează mesajul „Conexiune refuzată”? când se pare că serverul web nu răspunde deloc pe portul 80.

Răspuns de redirecționare

Când serverul web răspunde, priviți mai atent acel răspuns:

< HTTP/1.1 302 Găsit
< Data: Luni, 07 Feb 2022 13:58:11 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16
< Locație: https://sub.example.com/some-page.html
< Lungimea conținutului: 216
< Content-Type: text/html; set de caractere=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
...

Acesta este un răspuns destul de tipic pentru un server web care este configurat să redirecționeze HTTP simplu la HTTPS.

The 302 Găsit codul de stare din primul antet indică o redirecționare temporară. Pentru o redirecționare permanentă ar fi a 301 mutat permanent antet de stare http.

The Locație: antetul arată unde este redirecționat clientul.

Cauză: atunci când nu este definit în configurația serverului web, este foarte frecvent ca aplicațiile web să genereze redirecționări fie la https, fie la un domeniu diferit.
Pe serverele web Apache (care le permit) a .htaccess fișierul poate fi, de asemenea, sursa unei redirecționări.

Rezoluţie: ajustați sau eliminați redirecționarea sau asigurați-vă că redirecționarea devine validă și că ceva răspunde la ținta redirecționării.
Frecvent: obțineți acel certificat SSL și activați TLS!

Cauză: adesea ținta redirecționării este ruptă, verificați și acolo dacă există greșeli subtile de scriere, am văzut că lipsesc /este pentru a redirecționa către sub.example.comsome-page.html și parametrii utilizați incorect care redirecționează către http://some-page.html, sau http://www.example.com/http://sub.example.com/some-page.html si asemanatoare.
De asemenea, testați buclele făcând o solicitare către Locație: mai multe niveluri de redirecționări indică de obicei și o configurație întreruptă și elimină bucla.

Conținut de pe site-uri diferite

Când vezi conținut de pe un alt site pe care îl găzduiești și nu conținutul pentru care sub.exemplu.com rețineți că majoritatea serverelor web vor afișa conținutul de pe un site implicit atunci când nu pot potrivi un nume de gazdă cu un anumit site.

Rezoluţie: Verificați din nou configurația pentru greșeli de tipar și confirmați că serverul web a fost repornit cu configurația actualizată.

0 + 0
drapel cn
Bergi
Nu înțeleg cauza 2 pentru „buclele funcționează, dar browserul nu”. Cum pot fi afectate numai acestea din urmă de problemele DNS?
0
Răspunde
drapel cn
Bob
Pentru că de obicei rulez comenzi cli nu de pe desktopul pe care rulează browserul meu web, ci de pe serverul meu de testare. Serverul meu de testare nu folosește, de exemplu, serverele interne de nume corporative și nici nu face parte dintr-un domeniu AD. Și am scris aceste întrebări și răspunsuri după ce am văzut întrebări similare repetate în mod regulat și obosit să repet remarci similare. Așa că vedeți asta ca depanare 101 cu presupuneri educate despre problemele tipice cu care se confruntă oamenii, cum testez acele ipoteze și cum le-ar rezolva
1
Răspunde
drapel cn
Bergi
Ah, atunci vă rugăm să adăugați asta la răspuns - fie o recomandare de a rula `curl` de pe o altă mașină în secțiunea „testare”, fie explicați doar discrepanța dns cauzată de rularea browser-ului și curl pe diferite mașini. Nu mi-ar fi trecut prin cap să folosesc un server de salt în mod implicit
3
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.