VPN açıqdır və localhost işləmir: ad, proksi yoxsa bağlama?

İnkişaf serveriniz bir dəqiqə əvvəl cavab verirdi, indi tunel qalxdıqdan sonra sorğu heç yazmadığınız host adı ilə vaxt aşımına düşür. Demək olar ki, bütün halları iki mexanizm izah edir və kənardan onlar eyni görünür. Axtarış şəkilçisi qısa adı korporativ ada çevirir, proksi isə loopback trafikini ona çata bilməyən hosta göndərir. İkisini ayırmaq bir sorğuya başa gəlir və yazmaq üzrə olduğunuz firewall qaydasını qurtarır.

localhost korporativ zonaya həll olduqda

Tunel qalxarkən adın nəyə həll olduğunu yoxlayın, sonra eyni sorğunu tunel söndürülmüş halda işə salın və iki cavabı müqayisə edin. İşarə korporativ aralıqda 127.0.0.1 gözlədiyiniz yerdə görünən ünvandır. localhost.mycompany.corp kimi qeyd, müştəri həmin şəkilçini axtarış siyahısına əlavə etdikdən sonra loopback girişindən üstün gəlir və sorğu həmin portda heç nə dinləməyən şəxsi hosta gedir. Axtarış siyahısını təxmin etmək əvəzinə oxuyun, çünki müştəri birdən çox domen əlavə edə bilər və hansı namizədin ilk sınanacağını sıra həll edir:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Host adını tətbiqdə, verilənlər bazası müştərisində və ya notebook URL-ində hərfi ünvanla əvəz edin, sonra sorğunu təkrarlayın. Nasazlıq yox olursa, adlandırma probleminiz var idi və tunel yalnız tətik idi. Davam edirsə, növbəti şübhəli dinləyici və ya marşrutdur və ad sadəcə yanlış iz idi.

Loopback-i tutan proksi parametrləri

Tunel qalxarkən tətbiq olunan sistem proksisi 127.0.0.1 ünvanına sorğunu qəbul edib nəyi nəzərdə tutduğunuzu bilməyən uzaq proksiyə yönləndirəcək. Boş yan keçmə siyahısı yerli sorğunu uzaq sorğuya çevirir və xəta mesajı bunu nadir hallarda deyir. Loopback ünvanlarını yan keçmə siyahısına bir əmr üçün deyil, bütün sessiya üçün əlavə edin, sonra şəbəkə haqqında nəticə çıxarmazdan əvvəl alətin buna əməl etdiyini təsdiqləyin.

Tətbiq çərçivələri öz mühit dəyişənlərini və bəzən öz konfiqurasiya faylını oxuyur, ona görə bir alət üçün işləyən yan keçmə növbəti üçün heç nə sübut etmir. Brauzerlər bir incəlik əlavə edir: Chromium əsaslı brauzerlər loopback üçün proksidən gizli şəkildə yan keçir və yan keçmə nişanı bu davranışı silə bilər. Əməliyyat sistemi parametrinin bütün hekayə olduğunu fərz etmək əvəzinə faktiki proksi qərarını yoxlayın. Qabıqdan başladılan hər şey üçün iki əmr bunu həll edir:

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

Bağlama ünvanı kimin qoşula biləcəyini həll edir

127.0.0.1 üzərində başladılan server yalnız həmin maşından bağlantı qəbul edir, bu da adətən inkişaf üçün düzgün ilkin seçimdir. 0.0.0.0 üzərindəki server isə VPN adapteri də daxil olmaqla hər interfeysdə cavab verir, bu isə çoxlarının nəzərdə tutduğundan çox məruz qalma deməkdir. Hərfi loopback ünvanı uğursuz olduqda, hər şeydən əvvəl bağlamanı yoxlayın.

Dinləyən soketə baxın və yalnız portu deyil, bağlandığı ünvanı da qeyd edin. Başqa cihaz və ya konteyner xidmətə tunel vasitəsilə çatmalıdırsa, istifadə edəcəyi konkret interfeysə bağlayın və həmin porta qəsdən icazə verin. Yalnız öz maşınınıza lazımdırsa, dar bağlamanı saxlayın və serveri genişləndirmək əvəzinə müştərini düzəldin. Port yönləndirmə və ya tunel qatı ikisini birləşdirə bilər, amma hər biri sonradan öz sazlama işini tələb edən bir komponent əlavə edir.

Sazlama alətinin LAN gözlədiyi yer

Sazlama alətləri tunelin səssizcə pozduğu fərziyyələr daşıyır. Telefon sazlama körpüsü, VPN cihazın alt şəbəkəsini tutduqda cihazını itirir, ona görə LAN ünvanı və ya kabel ilə yenidən qoşulmaq toqquşmanı aradan qaldırır. Brauzer avtomatlaşdırma mərkəzi yalnız proksi vasitəsilə əlçatan olduqda və ya yerli firewall onun idarəetmə portunu atdıqda vaxt aşımına düşür. Uzaq sazlayıcı, müştərinin marşrutu yenidən yazdığı yerdə yüksəliş və loopback ünvanı tələb edə bilər.

İdarəetmə portunu və data portunu ayrıca müəyyənləşdirin, çünki biri çox vaxt sağ qalır, digəri isə yox. Sonra düzəlişin alətin konfiqurasiyasına, həmin alt şəbəkə üçün marşruta, yoxsa bölünmüş tunel qaydasına aid olduğuna qərar verin. hosts faylını hər inkişafçı maşınında redaktə etmək ən pis miqyaslanır və ilk unudulur. Tunelin sahibi olan şəxsin nəzərdən keçirə biləcəyi, profil ilə yaşayan parametri üstün tutun.

Uğursuz olan ilk mərhələdə dayanın

Üç mərhələ ilə irəliləyin: adı həll edin, hərfi ünvana soket açın, sonra alətin öz bağlantısını qurmasına icazə verin. Hər mərhələ bir qatı aradan qaldırır, ona görə ilk nasazlıq düzəldilməli qatı adlandırır və ondan sonrakı hər şey sınanmamış qalır. Nəyisə dəyişməzdən əvvəl nəticəni yazın, çünki ölçmədən əvvəl tətbiq olunan düzəlişi uğurdan ayırmaq mümkün deyil. İlk cəhd uğursuz olub təkrar işləyirsə, alət başlayanda tunel yəqin ki hazır deyildi.

Sabit gözləməni marşrutu gözləyən məhdud hazırlıq yoxlaması ilə əvəz edin və uğursuz mərhələni jurnalda saxlayın ki, növbəti şəxs harada dayandığını görsün. Özü bərpa olunan alət düzəldilməyib, sadəcə bəxti gətirib və bəxt başqasının maşınında tükənir. Tuneli ən sonda və yalnız həqiqətən uğursuz olan mərhələ üçün dəyişin. Bu sıra həm də işləyən quruluşa qayıdan ən qısa yoldur, çünki heç vaxt iştirak etməyən komponenti yenidən qurmağınızın qarşısını alır.