VPN dihidupkan dan localhost berhenti berfungsi: nama, proksi atau bind?

Pelayan pembangunan anda menjawab seminit lalu, dan kini apabila terowong naik permintaan tamat masa dengan nama hos yang tidak pernah anda taip. Dua mekanisme menjelaskan hampir setiap kes, dan dari luar kedua-duanya kelihatan serupa. Akhiran carian menukar nama pendek menjadi nama korporat, manakala proksi menghantar trafik loopback ke hos yang tidak dapat mencapainya. Mengasingkan kedua-duanya memerlukan satu pertanyaan dan menyelamatkan peraturan tembok api yang hampir anda tulis.

Apabila localhost diselesaikan ke zon korporat

Semak ke mana nama itu diselesaikan semasa terowong naik, kemudian jalankan pertanyaan yang sama dengan terowong turun dan bandingkan kedua-dua jawapan. Petunjuknya ialah alamat dalam julat korporat di tempat anda menjangkakan 127.0.0.1. Rekod seperti localhost.mycompany.corp mengalahkan entri loopback sebaik sahaja klien menambah akhiran itu pada senarai carian, dan permintaan bergerak ke hos peribadi yang tiada apa mendengar pada port itu. Baca senarai carian daripada menekanya, kerana klien boleh menambah lebih daripada satu domain dan susunan menentukan calon mana yang dicuba dahulu:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Gantikan nama hos dengan alamat literal dalam aplikasi, klien pangkalan data atau URL buku nota, kemudian ulangi permintaan. Jika kegagalan hilang, anda mempunyai masalah penamaan dan terowong hanyalah pencetus. Jika ia berterusan, pendengar atau laluan ialah suspek seterusnya dan nama itu hanyalah jejak palsu.

Tetapan proksi yang menangkap loopback

Proksi sistem yang digunakan apabila terowong naik akan menerima permintaan ke 127.0.0.1 dan memajukannya ke proksi jauh yang tidak tahu apa yang anda maksudkan. Senarai pengecualian kosong menukar permintaan setempat menjadi jauh, dan mesej ralat jarang menyatakannya. Tambahkan alamat loopback pada senarai pengecualian untuk seluruh sesi dan bukan untuk satu arahan, kemudian sahkan alat itu mematuhinya sebelum membuat sebarang kesimpulan tentang rangkaian.

Kerangka aplikasi membaca pemboleh ubah persekitarannya sendiri dan kadangkala fail konfigurasinya sendiri, jadi pengecualian yang berfungsi untuk satu alat tidak membuktikan apa-apa untuk yang seterusnya. Pelayar menambah satu halus: pelayar berasaskan Chromium memintas proksi untuk loopback secara tersirat, dan token pengecualian boleh membuang tingkah laku itu. Semak keputusan proksi sebenar daripada menganggap tetapan sistem pengendalian ialah keseluruhan cerita. Dua arahan menyelesaikannya untuk apa sahaja yang dilancarkan daripada shell:

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

Alamat bind menentukan siapa boleh bersambung

Pelayan yang dimulakan pada 127.0.0.1 hanya menerima sambungan daripada mesin itu, yang biasanya merupakan lalai yang betul untuk pembangunan. Pelayan pada 0.0.0.0 menjawab pada setiap antara muka, termasuk penyesuai VPN, iaitu pendedahan lebih besar daripada yang dimaksudkan kebanyakan orang. Apabila alamat loopback literal gagal, semak bind sebelum apa-apa lagi.

Lihat soket yang mendengar dan catat alamat yang diikatnya, bukan hanya port. Jika peranti lain atau kontena perlu mencapai perkhidmatan melalui terowong, ikat pada antara muka tertentu yang akan digunakannya dan benarkan port itu dengan sengaja. Jika hanya mesin anda sendiri memerlukannya, kekalkan bind sempit dan betulkan klien daripada meluaskan pelayan. Pemajuan port atau lapisan terowong boleh menjambatani kedua-duanya, tetapi setiap satu menambah komponen yang kemudiannya memerlukan penyahpepijatannya sendiri.

Di mana alat penyahpepijat menjangkakan LAN

Alat penyahpepijat membawa andaian yang dipecahkan oleh terowong secara senyap. Jambatan penyahpepijat telefon kehilangan perantinya apabila VPN menangkap subnet peranti itu, jadi menyambung semula melalui alamat LAN atau kabel mengelakkan konflik. Hab automasi pelayar tamat masa apabila hab hanya boleh dicapai melalui proksi, atau apabila tembok api setempat menggugurkan port kawalannya. Penyahpepijat jauh mungkin menuntut penaikan dan alamat loopback di tempat klien menulis semula laluan.

Kenal pasti port kawalan dan port data secara berasingan, kerana selalunya satu bertahan manakala yang lain tidak. Kemudian tentukan sama ada pembetulan itu tergolong dalam konfigurasi alat, dalam laluan untuk subnet itu, atau peraturan terowong berpisah. Menyunting fail hosts pada setiap mesin pembangun paling teruk skalanya dan paling dahulu dilupakan. Utamakan tetapan yang hidup bersama profil dan boleh disemak oleh sesiapa yang memiliki terowong itu.

Berhenti pada peringkat pertama yang gagal

Turuni tiga peringkat: selesaikan nama, buka soket ke alamat literal, kemudian biarkan alat membuat sambungannya sendiri. Setiap peringkat menghapuskan satu lapisan, jadi kegagalan pertama menamakan lapisan yang perlu dibetulkan dan segala-galanya selepas itu kekal tidak diuji. Tuliskan hasilnya sebelum mengubah apa-apa, kerana pembetulan yang digunakan sebelum pengukuran tidak dapat dibezakan daripada nasib. Jika percubaan pertama gagal dan percubaan semula berjaya, terowong itu mungkin belum sedia ketika alat dimulakan.

Gantikan tidur tetap dengan pemeriksaan kesediaan terbatas yang menunggu laluan, dan simpan peringkat yang gagal dalam log supaya orang seterusnya melihat di mana ia berhenti. Alat yang pulih sendiri tidak dibetulkan, ia bertuah, dan tuah itu habis pada mesin orang lain. Ubah terowong paling akhir, dan hanya untuk peringkat yang benar-benar gagal. Urutan itu juga laluan terpendek kembali kepada build yang berfungsi, kerana ia menghalang anda membina semula komponen yang tidak pernah terlibat.