VPN-ը միացված է, իսկ localhost-ը չի աշխատում՝ անուն, պրոքսի, թե bind։

Ձեր զարգացման սերվերը պատասխանել էր մեկ րոպե առաջ, իսկ հիմա, երբ թունելը բարձրացած է, հարցումը ժամկետանցվում է մի հոսթի անունով, որը դուք երբեք չեք մուտքագրել։ Գրեթե բոլոր դեպքերը բացատրում են երկու մեխանիզմ, և դրսից դրանք նույնական են թվում։ Որոնման վերջածանցը կարճ անունը դարձնում է կորպորատիվ, մինչդեռ պրոքսին loopback երթևեկությունն ուղարկում է մի հոսթ, որը չի կարող հասնել դրան։ Այս երկուսը բաժանելը արժե մեկ հարցում և խնայում է այն firewall կանոնը, որը դուք պատրաստվում էիք գրել։

Երբ 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 հասցեով կամ մալուխով վերամիանալը խուսափում է կոնֆլիկտից։ Զննարկիչի ավտոմատացման հանգույցը ժամկետանցվում է, երբ հանգույցը հասանելի է միայն պրոքսիով, կամ երբ տեղական firewall-ը գցում է նրա կառավարման պորտը։ Հեռավոր վրիպազերծիչը կարող է պահանջել բարձրացված իրավունքներ և loopback հասցե այնտեղ, որտեղ հաճախորդը վերաշարադրել է երթուղին։

Առանձին որոշեք կառավարման պորտը և տվյալների պորտը, որովհետև հաճախ մեկը ողջ է մնում, իսկ մյուսը՝ ոչ։ Ապա որոշեք՝ ուղղումը պատկանում է գործիքի կոնֆիգուրացիային, այդ ենթացանցի երթուղուն, թե բաժանված թունելի կանոնին։ hosts ֆայլը յուրաքանչյուր մշակողի մեքենայում խմբագրելը ամենավատ է մասշտաբավորվում և առաջինն է մոռացվում։ Նախընտրեք այն կարգավորումը, որն ապրում է պրոֆիլի հետ և կարող է վերանայվել թունելի տիրոջ կողմից։

Կանգնեք առաջին ձախողվող փուլում

Անցեք երեք փուլով՝ լուծեք անունը, բացեք սոքեթ դեպի բառացի հասցեն, ապա թողեք գործիքն ինքնուրույն միանա։ Յուրաքանչյուր փուլ վերացնում է մեկ շերտ, ուստի առաջին ձախողումը նշում է ուղղվող շերտը, և դրանից հետո ամեն ինչ մնում է չփորձված։ Գրեք արդյունքը նախքան որևէ բան փոխելը, որովհետև չափումից առաջ կիրառված ուղղումը չի տարբերվում բախտից։ Եթե առաջին փորձը ձախողվում է, իսկ կրկնությունը՝ աշխատում, ապա թունելը, հավանաբար, պատրաստ չէր, երբ գործիքը մեկնարկեց։

Փոխարինեք ֆիքսված սպասումը սահմանափակ պատրաստվածության ստուգմամբ, որը սպասում է երթուղուն, և պահեք ձախողվող փուլը մատյանում, որպեսզի հաջորդ մարդը տեսնի, թե որտեղ այն կանգ առավ։ Գործիքը, որն ինքնուրույն վերականգնվում է, ուղղված չէ, այն բախտավոր է, և բախտը սպառվում է ուրիշի մեքենայում։ Փոխեք թունելը վերջինը և միայն այն փուլի համար, որն իսկապես ձախողվեց։ Այդ հերթականությունը նաև աշխատող build-ին վերադառնալու ամենակարճ ճանապարհն է, որովհետև այն հետ է պահում ձեզ վերակառուցելու բաղադրիչ, որը երբեք ներգրավված չի եղել։