VPN menyala dan localhost berhenti bekerja: nama, proksi, atau bind?

Server pengembangan Anda menjawab satu menit lalu, dan sekarang setelah terowongan aktif permintaan habis waktu dengan nama host yang tidak pernah Anda ketik. Dua mekanisme menjelaskan hampir setiap kasus, dan dari luar keduanya tampak identik. Akhiran pencarian mengubah nama pendek menjadi nama korporat, sementara proksi mengirim lalu lintas loopback ke host yang tidak dapat menjangkaunya. Memisahkan keduanya memerlukan satu kueri dan menyelamatkan aturan firewall yang hampir Anda tulis.

Ketika localhost diselesaikan ke zona korporat

Periksa ke mana nama itu diselesaikan saat terowongan aktif, lalu jalankan kueri yang sama dengan terowongan mati dan bandingkan kedua jawabannya. Petunjuknya adalah alamat di rentang korporat di tempat Anda mengharapkan 127.0.0.1. Catatan seperti localhost.mycompany.corp mengalahkan entri loopback begitu klien menambahkan akhiran itu ke daftar pencarian, dan permintaan berjalan ke host privat yang tidak ada yang mendengarkan di port itu. Baca daftar pencarian alih-alih menebaknya, karena klien dapat menambahkan lebih dari satu domain dan urutannya menentukan kandidat mana yang dicoba lebih dulu:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Ganti nama host dengan alamat literal di aplikasi, klien basis data, atau URL notebook, lalu ulangi permintaannya. Jika kegagalan hilang, Anda punya masalah penamaan dan terowongan hanya pemicunya. Jika tetap ada, pendengar atau rute adalah tersangka berikutnya dan nama itu hanya jejak palsu.

Pengaturan proksi yang menangkap loopback

Proksi sistem yang diterapkan saat terowongan naik akan menerima permintaan ke 127.0.0.1 dan meneruskannya ke proksi jarak jauh yang tidak tahu apa maksud Anda. Daftar pengecualian yang kosong mengubah permintaan lokal menjadi jarak jauh, dan pesan galat jarang mengatakannya. Tambahkan alamat loopback ke daftar pengecualian untuk seluruh sesi, bukan untuk satu perintah, lalu pastikan alat itu mematuhinya sebelum menyimpulkan apa pun tentang jaringan.

Kerangka aplikasi membaca variabel lingkungannya sendiri dan kadang file konfigurasinya sendiri, jadi pengecualian yang berfungsi untuk satu alat tidak membuktikan apa pun untuk alat berikutnya. Peramban menambahkan satu hal: peramban berbasis Chromium melewati proksi untuk loopback secara implisit, dan token pengecualian dapat menghapus perilaku itu. Periksa keputusan proksi yang sebenarnya alih-alih menganggap pengaturan sistem operasi adalah seluruh ceritanya. Dua perintah menyelesaikannya untuk apa pun yang diluncurkan dari shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Alamat bind menentukan siapa yang dapat terhubung

Server yang dimulai di 127.0.0.1 hanya menerima koneksi dari mesin itu, yang biasanya merupakan default yang tepat untuk pengembangan. Server di 0.0.0.0 menjawab di setiap antarmuka, termasuk adaptor VPN, yang merupakan paparan lebih besar daripada yang dimaksudkan kebanyakan orang. Ketika alamat loopback literal gagal, periksa bind sebelum hal lain.

Lihat soket yang mendengarkan dan catat alamat yang diikatnya, bukan hanya portnya. Jika perangkat lain atau kontainer harus menjangkau layanan melalui terowongan, ikat ke antarmuka tertentu yang akan digunakannya dan izinkan port itu dengan sengaja. Jika hanya mesin Anda sendiri yang membutuhkannya, pertahankan bind yang sempit dan perbaiki klien alih-alih memperlebar server. Penerusan port atau lapisan terowongan dapat menjembatani keduanya, tetapi masing-masing menambah komponen yang nanti memerlukan penelusuran kesalahannya sendiri.

Di mana alat penelusuran kesalahan mengharapkan LAN

Alat penelusuran kesalahan membawa asumsi yang diam-diam dipatahkan terowongan. Jembatan penelusuran ponsel kehilangan perangkatnya ketika VPN menangkap subnet perangkat, jadi menyambung ulang melalui alamat LAN atau kabel menghindari konflik. Hub otomasi peramban habis waktu ketika hub hanya dapat dijangkau melalui proksi, atau ketika firewall lokal menjatuhkan port kendalinya. Penelusur jarak jauh mungkin menuntut elevasi dan alamat loopback di tempat klien menulis ulang rutenya.

Identifikasi port kendali dan port data secara terpisah, karena sering kali yang satu bertahan sementara yang lain tidak. Lalu putuskan apakah perbaikannya ada di konfigurasi alat, di rute untuk subnet itu, atau aturan terowongan terpisah. Mengedit file hosts di setiap mesin pengembang paling buruk skalanya dan paling cepat terlupakan. Utamakan pengaturan yang hidup bersama profil dan dapat ditinjau oleh siapa pun yang memiliki terowongan.

Berhenti pada tahap pertama yang gagal

Turuni tiga tahap: selesaikan namanya, buka soket ke alamat literal, lalu biarkan alat membuat koneksinya sendiri. Setiap tahap menghilangkan satu lapisan, jadi kegagalan pertama menyebut lapisan yang harus diperbaiki dan semua setelahnya tetap belum diuji. Tuliskan hasilnya sebelum mengubah apa pun, karena perbaikan yang diterapkan sebelum pengukuran tidak dapat dibedakan dari keberuntungan. Jika percobaan pertama gagal dan percobaan ulang berhasil, terowongan mungkin belum siap saat alat dimulai.

Ganti tidur tetap dengan pemeriksaan kesiapan terbatas yang menunggu rute, dan simpan tahap yang gagal di log agar orang berikutnya melihat di mana ia berhenti. Alat yang pulih sendiri tidak diperbaiki, ia hanya beruntung, dan keberuntungan habis di mesin orang lain. Ubah terowongan paling akhir, dan hanya untuk tahap yang benar-benar gagal. Urutan itu juga jalur terpendek kembali ke build yang berfungsi, karena mencegah Anda membangun ulang komponen yang tidak pernah terlibat.