VPN қосулы, ал localhost жұмыс істемейді: атауы, прокси әлде bind пе?

Іздеу суффиксі немесе прокси басқаруды алғанда, localhost енді сіздің машинаңызды білдірмейді. Алдымен атауын, содан кейін маршрутты, содан кейін құралдың қосылым жолын түзетіңіз.

Әзірлеу серверіңіз бір минут бұрын жауап берген, енді туннель көтерілген кезде сұрау ешқашан термеген хост атауымен уақыт шегінен өтеді. Барлық дерлік жағдайды екі механизм түсіндіреді және сырттан олар бірдей көрінеді. Іздеу суффиксі қысқа атауды корпоративтік атауға айналдырады, ал прокси loopback трафигін оған жете алмайтын хостқа жібереді. Осы екеуін ажырату бір сұрауға тұрарлық және жазуға отырған файрвол ережесін үнемдейді.

localhost корпоративтік аймаққа шешілгенде

Туннель көтерілгенде атаудың неге шешілетінін тексеріңіз, содан кейін сол сұрауды туннельді түсіріп орындап, екі жауапты салыстырыңыз. Белгі – 127.0.0.1 күткен жерде корпоративтік диапазондағы мекенжай. localhost.mycompany.corp сияқты жазба клиент сол суффиксті іздеу тізіміне қосқан бойда loopback жазбасынан басым түседі, ал сұрау сол портта ештеңе тыңдамайтын жеке хостқа кетеді. Іздеу тізімін болжауға емес, оқуға кеңес беремін, өйткені клиент бірнеше домен қосуы мүмкін және қай кандидат бірінші сыналатынын рет анықтайды:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Хост атауын қолданбадағы, дерекқор клиентіндегі немесе дәптер URL-індегі нақты мекенжаймен алмастырыңыз, содан кейін сұрауды қайталаңыз. Егер ақау жоғалса, атау мәселесі болды және туннель тек түрткі ғана еді. Егер ол қалса, тыңдаушы немесе маршрут келесі күдікті, ал атау жай ғана жалған із болды.

loopback-ті ұстайтын прокси параметрлері

Туннель көтерілгенде қолданылатын жүйелік прокси 127.0.0.1 мекенжайына сұрауды қабылдап, оны не айтқыңызды білмейтін қашықтағы проксиге жібереді. Бос айрықшалар тізімі жергілікті сұрауды қашықтағыға айналдырады, ал қате хабарламасы мұны сирек айтады. Loopback мекенжайларын бір командаға емес, бүкіл сессияға айрықшалар тізіміне қосыңыз, содан кейін желі туралы қорытынды жасамас бұрын құралдың оны сақтайтынын растаңыз.

Қолданба фреймворктері өз орта айнымалыларын және кейде өз конфигурация файлын оқиды, сондықтан бір құрал үшін жұмыс істейтін айрықша келесісі үшін ештеңе дәлелдемейді. Браузерлер бір ерекшелік қосады: Chromium негізіндегі браузерлер loopback үшін проксиді жасырын түрде айналып өтеді, ал айрықша токені бұл мінез-құлықты жоюы мүмкін. Операциялық жүйе параметрі бүкіл әңгіме деп ойламай, нақты прокси шешімін тексеріңіз. Shell-ден іске қосылған кез келген нәрсе үшін екі команда мұны шешеді:

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

bind мекенжайы кімнің қосыла алатынын шешеді

127.0.0.1 мекенжайында іске қосылған сервер тек сол машинадан қосылымдарды қабылдайды, бұл әзірлеу үшін әдетте дұрыс әдепкі. 0.0.0.0 мекенжайындағы сервер VPN адаптерін қоса алғанда барлық интерфейстерде жауап береді, бұл көпшілік ойлағаннан көбірек әшкерелеу. Нақты loopback мекенжайы істемесе, ең алдымен bind-ті тексеріңіз.

Тыңдап тұрған сокетке қарап, оның қай мекенжайға байланғанын жазып алыңыз, тек портты емес. Егер басқа құрылғы немесе контейнер қызметке туннель арқылы жетуі керек болса, ол пайдаланатын нақты интерфейске байлаңыз және сол портқа әдейі рұқсат беріңіз. Егер тек өз машинаңызға қажет болса, тар bind-ті сақтап, серверді кеңейтудің орнына клиентті түзетіңіз. Портты бағыттау немесе туннель қабаты екеуін жалғауы мүмкін, бірақ әрқайсысы кейін өз жөндеуін қажет ететін компонент қосады.

Жөндеу құралы LAN-ды күтетін жер

Жөндеу құралдары туннель үнсіз бұзатын болжамдарды алып жүреді. Телефонды жөндеу көпірі VPN құрылғының ішкі желісін ұстап алғанда құрылғысынан айырылады, сондықтан LAN мекенжайы немесе кабель арқылы қайта қосылу қақтығысты болдырмайды. Браузерді автоматтандыру хабы хаб тек прокси арқылы қолжетімді болғанда немесе жергілікті файрвол оның басқару портын тастағанда уақыт шегінен өтеді. Қашықтағы жөндеуші клиент маршрутты қайта жазған жерде құқық көтеру мен loopback мекенжайын талап етуі мүмкін.

Басқару порты мен деректер портын бөлек анықтаңыз, өйткені жиі біреуі тірі қалады, екіншісі қалмайды. Содан кейін түзету құрал конфигурациясына, сол ішкі желінің маршрутына немесе бөлінген туннель ережесіне жататынын шешіңіз. Әр әзірлеуші машинасында hosts файлын өңдеу ең нашар масштабталады және бірінші ұмытылады. Профильмен бірге өмір сүретін және туннель иесі қарап шыға алатын параметрді таңдаңыз.

Бірінші сәтсіз кезеңде тоқтаңыз

Үш кезеңмен төмен жүріңіз: атауды шешіңіз, нақты мекенжайға сокет ашыңыз, содан кейін құрал өз қосылымын жасасын. Әр кезең бір қабатты жояды, сондықтан бірінші ақау түзетілетін қабатты атайды және одан кейінгінің бәрі тексерілмеген күйде қалады. Бірдеңені өзгертуден бұрын нәтижені жазыңыз, өйткені өлшеуден бұрын қолданылған түзетуді сәттіліктен ажырату мүмкін емес. Бірінші әрекет сәтсіз болып, қайталау жұмыс істесе, құрал іске қосылғанда туннель дайын болмаған шығар.

Тұрақты күтуді маршрутты күтетін шектеулі дайындық тексерісімен ауыстырыңыз және сәтсіз кезеңді журналда қалдырыңыз, келесі адам қай жерде тоқтағанын көрсін. Өзінен өзі қалпына келетін құрал түзетілген жоқ, ол жай ғана сәтті, ал сәттілік басқа біреудің машинасында таусылады. Туннельді соңында және тек шынымен сәтсіз болған кезең үшін өзгертіңіз. Бұл рет те жұмыс істейтін build-ке қайтудың ең қысқа жолы, өйткені ол ешқашан қатыспаған компонентті қайта жасауға жол бермейді.

Қатысты мақалалар