Beim Ausführen von VPN wird eine falsche PHP-Version angezeigt

Beim Ausführen von VPN wird eine falsche PHP-Version angezeigt

Ich habe ein seltsames Problem, über das ich wirklich gerne mehr erfahren würde. Gestern habe ich eine neue Site auf meinem Hosting-Server bereitgestellt. Am Tag zuvor habe ich auf dem Server von auf umgestellt PHP 5.2.17. PHP 5.4.10Das Seltsame war, dass die Version immer noch als 5.2.17? gemeldet wurde. Ich habe einen Kollegen gebeten, auf die Site zu gehen, und er hat die richtige Version erhalten. Schließlich habe ich mein VPN ausgeschaltet (nicht für diesen bestimmten Server verwendet) und konnte sofort sehen, dass der Server die richtige PHP-Version ausführte. Jetzt würde ich wirklich gerne wissen, warum das jemals passiert ist. Das Einzige, was mir einfällt, ist, dass dies eine Art Caching-Problem in Verbindung mit dem laufenden VPN-Tunnel sein muss?

Wenn ich über SSH im Webroot eine neue Datei erstelle, kann ich über meinen Browser nicht auf die Datei zugreifen, sondern erhalte eine 404-Seite. Wenn ich mein VPN ausschalte oder neu starte, verschwindet dieser Fehler.

Ich benutzeJuno Pulseals mein VPN-Client.

Eine weitere interessante Sache, die mir aufgefallen ist, ist, dass die Seite nach dem Neustart des VPN-Clients wieder die richtige Version meldet.

Antwort1

Für mich klingt das nach einem Provider- und DNS-Problem. Insbesondere gehe ich davon aus, dass der Provider über mehrere Rechner verfügt – möglicherweise mit gemeinsam genutztem Webspeicher, aber regelmäßig synchronisiertem Systemspeicher – und dass Sie durch die Verwendung/Nichtverwendung eines VPN das Routing auf einen anderen Rechner geändert haben – bevor PHP aktualisiert wurde.

Anzeichen dafür sind: 1. Es ist kein Cache. Durch Umbenennen der Datei info.php konnte dies ausgeschlossen werden. 2. Es handelt sich um ein Routing-bezogenes Problem – das VPN ändert das Routing. 3. Es war ein temporäres Problem.

Antwort2

Ohne die zugrunde liegende Konfiguration zu prüfen, ist es schwierig, das genaue Problem zu ermitteln. Basierend auf einigen der von Ihnen bereitgestellten Informationen war es jedoch unwahrscheinlich, dass es sich um einen Cache handelte, da Sie die Datei info2.php erstellt haben und dasselbe Problem auftrat.

Das würde darauf hinweisen, dass Sie bei Verwendung des VPN auf einen anderen Server umgeleitet wurden. Entweder durch einen Load Balancer bei Ihrem Anbieter oder DNS (prüfen Sie, ob mehrere Datensätze/Round-Robin vorhanden sind). Es gibt keine Caches bei Ihrem VPN, die dies möglicherweise verursachen könnten (was Sie, glaube ich, meinen).

Es gibt viele verschiedene Load Balancer-Konfigurationen, aber eine solche Konfiguration basiert auf einem Hash der IP, was erklären würde, warum Sie immer auf demselben System feststeckten (das Ihre Änderungen möglicherweise noch nicht synchronisiert hatte), aber beim Zugriff von einer anderen IP auf ein anderes System umgeleitet wurden. Siehe nginx'sip_hashfür ein Beispiel einer solchen Balancer-Konfiguration. Insbesondere

Als Hash-Schlüssel werden die ersten drei Oktette der IPv4-Adresse des Clients oder die gesamte IPv6-Adresse verwendet. Die Methode stellt sicher, dass Anfragen desselben Clients immer an denselben Server weitergeleitet werden, es sei denn, dieser Server ist nicht verfügbar.

Überprüfen Sie bei der DNS-Option, ob Ihre Domain zu mehreren A-Einträgen weiterleitet, möglicherweise mithilfe eines Tools wiemxtoolboxda dies auch die Weiterleitung zu einem anderen System erklären könnte, wenn kein tatsächliches LB vorhanden ist.

Bei einer ähnlichen Situation fällt mir Folgendes ein: Codeänderungen wurden kürzlich bei bestimmten Anfragen nicht angezeigt. Das Problem war, dass ENOM den CNAME für den Stammdatensatz zugelassen hat, was gemäß RFC1034 in ihrer Schnittstelle nicht zulässig ist. Was jedoch tatsächlich passiert, ist, dass sie einfach die A-Datensätze des CNAME nachschlagen, der in diesem Fall ein AWS ELB war, und 2 A-Datensätze für die beiden IPs erstellt haben, auf die der ELB aufgelöst wurde. Als AWS dann einige Monate später eine der IPs änderte, auf die der ELB weitergeleitet wurde, wurde dies nicht berücksichtigt, sodass einige Anfragen an die alte ELB-IP weitergeleitet wurden und wiederum der alte zwischengespeicherte Code angezeigt wurde.

verwandte Informationen