%20verbinden%3F.png)
Ich möchte die Antwortenden auf diesen Thread verweisen unterLinux Mint-Foren:
Ich habe das in den letzten zwei Wochen ungefähr viermal gesehen. Der Verbindungsverlust führt schließlichklarnach einer unbekannten Zeit (am längsten dauerte es 4 Tage).
Kurz gesagt, fast alle URLs funktionieren, aber wichtige URLs, die Sie für (tatsächliche) Aufgaben benötigen, wie google.com, linkedin.com, youtube.com oder yahoo.com usw., funktionieren nicht. Andere Sites, von denen Sie denken, dass sie damit zusammenhängen, funktionieren dagegen. Es ist unvorhersehbar. Heute Abend ist ein gutes Beispiel. URL:
- http://mail.google.com- scheitert, während
- http://google.com(Suchen) - wird angezeigt.
Das Problem betrifft alles, was ich getestet habe (für die 'fehlen' URL) …
- Feuerfuchs
- Chrom
- Locke
- wget
- graben
Ich weiß nicht, ob es speziell am DNS liegt.
(aktualisieren:11.11.2015)
Das glückliche Erlebnis, zu einem mobilen Breitbandmodem und zurück zu wechseln, war kein „Workaround“, sondern nur ein Glücksfall. Die Ergebnisse eines solchen Wechsels funktionieren nicht immer.
Ich denke, die DNS-Probleme sind nur ein Symptom. Die Nachricht für
curl https//:mail.google.com
Zurückgeben ist...
curl: (7) Couldn't connect to server
Ich vermute, dass es den Server zwar „sehen“ kann, aber keine Verbindung herstellt. Wie erwähnt kann ich E-Mails von anderen Geräten über denselben Zugangspunkt senden, z. B. von einem Android-Telefon. Ich frage mich also, welche Diagnosen es für diese Art von Dingen in Linux Mint gibt, damit ich einen Überblick darüber bekomme, welcher Teil des Stapelsgesteckt?
(aktualisieren:10.11.2015)
Ich habe einige neue Informationen. Sie können anderen helfen oder dem Brain's Trust einen Tipp geben, wie dieses Problem gelöst werden kann. Heute Abend konnte ich nicht auf GitHub, stackexchange.com, netbeans und Wikipedia zugreifen, um nur einige zu nennen. Jetzt bin ich hier, also was ist passiert?
Als ich drückteF5hier erhielt ich diese Bannernachricht oben auf dem Bildschirm:
Unix & Linux Stack Exchange requires external
JavaScript from another domain, which is blocked
or failed to load.
upsIch dachte, es ist schon wieder passiert. Ich wollte unbedingt nachsehen, ob es Antworten gibt, denn wie Sie sich vorstellen können, verzögert dieser Fehler den Fortschritt erheblich. Ich habe also ein kleines Guthaben auf einem USB-Modem. Ich dachte, ich versuche, das zu nutzen.
- Den WLAN-Zugangspunkt ausgetauscht
- Mit dem USB-/Mobilfunknetz verbunden
Ergebnis: Keine Änderung, kann Wikipedia nicht aufrufen und auf dieser Seite wurde die nervige Skriptnachricht angezeigt.
- Trennen Sie die Verbindung zum USB-/mobilen Breitbandnetzwerk
- Verbinden Sie den WLAN-Zugangspunkt erneut
Einer meiner Dig-Tests ergab ein anderes ErgebnisNachVerbindung (zurück) zum WLAN-Zugangspunkt herstellen.Jetzt) ...
- Die nervige Bannermeldung auf StackExchange ist verschwunden. Ich kann Wikipedia und GitHub wieder sehen.
Es scheint, dass etwas im Stapel nicht zurückgesetzt/aktualisiert wird, bis der 'Verdrahtet' (Zugangspunkt-)Verbindung wird wiederhergestellt. Aber nicht einfach nur wiederhergestellt; sie wird usurpiert, so dass alles (erneut) wiederhergestellt werden muss.
Das andere Merkwürdige ist, dass das mobile Breitband die (effektiven) Inhalte im Datenkommunikationsstapel NICHT aktualisiert/zurückgesetzt hat. Warum nicht? Wie?
Noch wichtiger: Was kann ich tun, um das Zurücksetzen/Aktualisieren der kabelgebundenen Verbindung und der Wi-Fi-Verbindung zu erzwingen, ohne ein nicht mehr funktionierendes mobiles Breitband zu erneuern, wenn die aktuellen Fusionsrestguthabenabtropfen lassen??!!
Ansonsten bleibt alles wie beim letzten Update
(Update-Ende)
Im Moment kann ich nur sagen, dass die Google-Suche (Arbeiten) und Gmail (funktioniert nicht) zeigen die folgenden Antworten von Dig.
$ dig google.com
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19398
;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 114 IN A 120.19.255.38
google.com. 114 IN A 120.19.255.27
google.com. 114 IN A 120.19.255.19
google.com. 114 IN A 120.19.255.59
google.com. 114 IN A 120.19.255.53
google.com. 114 IN A 120.19.255.29
google.com. 114 IN A 120.19.255.15
google.com. 114 IN A 120.19.255.49
google.com. 114 IN A 120.19.255.57
google.com. 114 IN A 120.19.255.34
google.com. 114 IN A 120.19.255.23
google.com. 114 IN A 120.19.255.45
google.com. 114 IN A 120.19.255.44
google.com. 114 IN A 120.19.255.42
google.com. 114 IN A 120.19.255.30
;; Query time: 108 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Tue Nov 03 23:14:22 AEDT 2015
;; MSG SIZE rcvd: 268
Und$ dig mail.google.com
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> mail.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40641
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;mail.google.com. IN A
;; AUTHORITY SECTION:
. 49606 IN NS localhost.
;; Query time: 106 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Tue Nov 03 23:15:02 AEDT 2015
;; MSG SIZE rcvd: 55
Im Gegensatz dazu zeigt die Dig-Ausgabe auf einer funktionierenden Box, auf die ich Zugriff habe, hinsichtlich der Nameserver ein anderes Bild.
Auf einer funktionierenden Maschine:$ dig gmail.com(im Update hinzugefügt)
; <<>> DiG 9.6-ESV-R11 <<>> gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22330
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN A
;; ANSWER SECTION:
gmail.com. 192 IN A 216.58.220.101
;; Query time: 15 msec
;; SERVER: 192.168.172.1#53(192.168.172.1)
;; WHEN: Wed Nov 04 14:02:50 EST 2015
;; MSG SIZE rcvd: 43
Im ersten nicht funktionierenden Beispiel verwendet das Linux-Setup localhost. Für mich klingt das, als müsste ich es aktualisieren oder so etwas. Kommentare?
Im Wesentlichen geht es um folgendes:
- Linux Mint v17.2 - Rafaela (Zimt 64-Bit)
- dnsmasq Version 2.68
Ich habe den im Forum vorgeschlagenen Netzwerkneustart getestet, leider hat er mir nicht geholfen, auf Gmail zuzugreifen. Zurück zu den Reißbrettern/Stackexchange :-)
Abgesehen von der Frage nach derMint-ForumIch habe nichts gefunden, was darauf hinweist,Ja' oder 'Nein' für dieses Problem. Der erste Beitrag zu diesem Thema war vor langer Zeit in2011und es sieht so aus, als ob es übersprungen wurde als 'nicht gut' Frage, also gibt es dieses Phänomen schon seit einiger Zeit. Es wäre gut, eine wirksame Antwort zu finden. Hoffentlich hat einer von uns eineFix bereits.
Vorschläge sind willkommen und ich suche gerne nach weiteren Informationen.
Antwort1
(aktualisieren:16.12.2015)
In den letzten Tagen hatte ich Gelegenheit, die restlichen MBs des USB-Modems zu verbrauchen. Ich hatte absolut keine DNS-Probleme.
Irgendwann habe ich das drahtlose USB-Breitbandmodem an jemanden ausgeliehen und den Micro-USB-Anschluss über ein Mobiltelefon (gleicher Netzanbieter) verwendet. Die DNS-Probleme traten sehr schnell wieder auf!
Die Problemumgehung scheint darin zu bestehen, kabelgebundene Micro-USB-Verbindungen (Mobiltelefone) zu vermeiden. Oder eine Verbindung über WLAN herzustellen.
Ich habe vielleicht einen Weg nach vorne, wenn auch keine wirkliche Lösung. Bei diesem Problem muss ich sehen, wie es sich über einen Monat entwickelt, und sicherstellen, dass es keine Ausfälle gibt.
Auf diesem System ist eine Neuinstallation von Linux Mint 17.2 - Rafaela installiert. Ich habe die Netzwerkkonfiguration nicht bewusst verändert, bevor die Probleme auftraten. Anfangs funktionierte es mehr oder weniger einwandfrei. Da es sich um ein zeitweiliges Problem handelte, kann ich dazu nichts sagen.
Mit Blick auf dieMint-Seite, stellte ich fest, dass diesem System die
/etc/dnsmasq.confKonfigurationsdatei
Also habe ich beschlossen, dnsmasq (neu) zu installieren
sudo apt-get install dnsmasq
Und arbeiten Sie durch dieLernprogrammsowie auf den Unterabschnitt über die VerwendungGoogle DNSWiki-Seite. Und dnsmasq neu gestartet.
sudo /etc/init.d/dnsmasq restart
In jedem Fall ist es manchmal das Beste, die Installation neu durchzuführen und sicherzustellen, dass Sie eine saubere Weste haben. Die bisherigen Tests zeigen, dass alles einwandfrei funktioniert. Der DNS-Cache war definitivNICHTfunktionierte, bevor ich es neu installiert habe. Meine Grabungszeit liegt jetzt bei gängigen Domänen bei nahezu Null! Ja
Hoffe, das hilft anderen. Übrigens habe ich viele Informationen zum Zurücksetzen von NetworkManager gesehen. So wie ich das verstehe, ist NetworkManager eine Alternative zu einem DNSmasq-Setup. Ich würde mich über eine Klarstellung in diesem Punkt freuen. Soweit ich weiß, sind die beiden jedenfalls nicht miteinander kompatibel.
Zurzeit ist DNSmasq für mich besser. Es ist schon seit einiger Zeit in Debian -> Ubuntu -> Mint verfügbar, daher kann man wohl sagen, dass es in den meisten Fällen die bessere Option ist.
einige Ressourcen: