Versi PHP salah ditampilkan saat menjalankan VPN

Saya memiliki masalah aneh yang ingin saya ketahui lebih banyak. Kemarin saya menyebarkan situs baru di server hosting saya. Sehari sebelum saya beralih dari PHP 5.2.17ke PHP 5.4.10di server. Yang aneh adalah bahwa versi itu masih dilaporkan 5.2.17? Saya meminta seorang rekan kerja untuk pergi ke situs tersebut dan dia mendapatkan versi yang benar. Akhirnya, saya mengaktifkan VPN saya (tidak digunakan untuk server khusus ini) dan langsung saya bisa melihat server menjalankan versi PHP yang benar. Sekarang saya benar-benar ingin tahu mengapa ini terjadi? Satu-satunya hal yang dapat saya pikirkan adalah bahwa ini harus menjadi semacam masalah caching sehubungan dengan menjalankan VPN tunnel?

Jika saya membuat file baru melalui SSH di webroot saya tidak dapat mengakses file melalui browser saya, sebagai gantinya saya menerima halaman 404. Jika saya mengaktifkan atau memulai ulang VPN saya, kesalahan ini hilang.

Saya menggunakan Juno Pulse sebagai klien VPN saya.

Hal menarik lain yang saya perhatikan adalah bahwa setelah saya memulai kembali klien VPN, halaman melaporkan versi yang benar lagi.

vpn php

— Cyclonecode
sumber

Klien VPN apa yang Anda gunakan dan bagaimana Anda memeriksa versi PHP?

— Spokey

@Spokey - Saya mengedit jawaban saya dan menambahkan info tentang klien. Saya menggunakan Juno Pulse. Saya memeriksa versi php dengan menambahkan file info.php yang mengeksekusi phpInfo();dan menambahkan ini ke root situs.

— Cyclonecode

Sepertinya Anda telah mencapai halaman cache. Karena Anda tidak lagi dipengaruhi oleh perilaku ini, apa sebenarnya pertanyaan Anda?

— Ramhound

@Ramhound - Pertanyaannya adalah mengapa ini terjadi. Apa itu cache halaman? Jika saya mengganti nama info.phpmenjadi info2.php(ini tidak boleh di-cache) maka saya mengalami perilaku yang sama ketika mengakses info2.phpfile baru melalui browser saya?

— Cyclonecode

Tidak perlu - itu tergantung pada bagaimana penyeimbang beban dikonfigurasi. Itu bisa menyeimbangkan alamat IP atau semacam cookie sesi. Mungkin patut mencoba peramban lain untuk menghilangkan kemungkinan cookie yang disuntikkan untuk penyeimbangan muatan. Anda mungkin juga ingin mencoba sidik jari server untuk melihat apakah mereka berbeda [keduanya adalah foto yang agak panjang, tetapi patut dicoba.

— davidgo

Jawaban:

Kedengarannya bagi saya seperti masalah penyedia + dns - khususnya saya mendalilkan penyedia memiliki beberapa mesin - mungkin dengan penyimpanan web bersama tetapi penyimpanan sistem disinkronkan secara berkala -, dan dengan menggunakan / tidak menggunakan VPN Anda mengubah rute ke mesin yang berbeda - sebelum PHP - telah diperbarui.

Tanda-tanda ini adalah: 1. Ini bukan cache. Mengganti nama file info.php mengesampingkannya. 2. Ini masalah terkait perutean - thr VPN menghubungkan perutean. 3. Itu adalah masalah sementara.

— davidgo
sumber

Saya tidak percaya itu adalah masalah sementara karena saya bisa mereproduksi dengan memulai kembali koneksi VPN.

— Cyclonecode

Tanpa memeriksa pengaturan yang mendasarinya, sulit untuk mengatakan dengan tepat apa masalahnya berdasarkan pada beberapa informasi yang Anda berikan. Itu tidak mungkin merupakan cache mengingat Anda membuat file info2.php dan memiliki masalah yang sama.

Yang akan menunjukkan Anda di mana dialihkan ke server lain saat menggunakan VPN. Baik oleh penyeimbang beban di penyedia Anda atau DNS (Lihat apakah ada beberapa catatan / round-robin). Tidak ada cache di VPN Anda yang mungkin menyebabkan hal ini (yang menurut saya adalah maksud Anda).

Ada banyak konfigurasi penyeimbang beban yang berbeda tetapi satu konfigurasi seperti itu didasarkan pada hash IP yang akan menjelaskan mengapa Anda selalu terjebak di sistem yang sama (yang mungkin belum menyinkronkan perubahan Anda) tetapi di mana dialihkan ke yang lain ketika mengakses dari yang lain AKU P. Lihat ip_hash nginx untuk contoh dari salah satu konfigurasi penyeimbang tersebut. Secara khusus,

Tiga oktet pertama dari alamat IPv4 klien, atau seluruh alamat IPv6, digunakan sebagai kunci hashing. Metode ini memastikan bahwa permintaan dari klien yang sama akan selalu diteruskan ke server yang sama kecuali ketika server ini tidak tersedia.

Adapun opsi DNS memeriksa apakah domain Anda merutekan ke beberapa catatan A, mungkin menggunakan alat seperti mxtoolbox karena ini juga mungkin menjelaskan dirutekan ke sistem lain jika tidak ada LB yang sebenarnya.

Sesuatu yang muncul dalam pikiran untuk situasi yang mirip dengan ini adalah perubahan kode baru-baru ini di mana tidak ditampilkan untuk permintaan tertentu. Masalahnya adalah ENOM mengizinkan CNAME ke catatan root yang tidak diizinkan per RFC1034 di antarmuka mereka. Namun apa yang sebenarnya terjadi adalah mereka hanya mencari catatan A CNAME yang dalam hal ini adalah AWS ELB dan membuat 2 A catatan untuk dua IP ELB diselesaikan dan kemudian beberapa bulan kemudian ketika AWS mengubah salah satu IP ELB yang ELB. merutekan ke ini tidak tercermin sehingga beberapa permintaan dialihkan ke ELB IP lama dan pada gilirannya menampilkan kode cache lama.

— Scott-Mc
sumber