Ինչու ձեր VPN թունելի հասցեն չի բացում մուտքային պորտ
Թունելի հասցեն նույնականացնում է ձեր հաճախորդին այն գործընկերների համար, որոնք կարող են երթուղավորել դեպի այն, և երբեք լսորդ չի ստեղծում։ Ստուգեք կապումը, վերադարձի ուղին, ապա քաղաքականությունը։
Միացեք գրասենյակի VPN-ին, գործարկեք փոքր ծառայություն 8443 պորտում, ուղարկեք թունելի հասցեն գործընկերոջը և տեսեք, թե ինչպես է կապը ձախողվում, մինչ հաճախորդը դեռ հայտնում է, որ միացած է։ Թունելում ոչինչ փչացած չէ. հասցեն տրվել է, սեսիան ակտիվ է, և պատասխանը կրող փաթեթները պարզապես երբեք չեն թույլատրվում։ Կատարեք ստորև նշված երեք ստուգումները հերթականությամբ և կանգ առեք այն մեկի վրա, որը ձախողվում է, որովհետև յուրաքանչյուրն ունի տարբեր ուղղում, և դրանցից միայն մեկն է վերաբերում VPN-ին։
Սկսեք նրանից, թե որտեղ է սոքեթն իրականում կապված
Նախքան ինչ-որ բան երթուղավորվելը, ինչ-որ բան պետք է լսի հասցեում, որին զանգահարողը կարող է հասնել։ Զարգացման սերվերները սովորական մեղավորն են, քանի որ դրանցից շատերը լռելյայն կապվում են loopback-ին և ընդունում են միայն նույն մեքենայից ծագող միացումները։ Թունելի հասցեն չի փոխում այդ կապումը, և օպերացիոն համակարգը կմերժի միացումը շատ ավելի վաղ, քան VPN-ը կներգրավվի։
ss -ltnp | grep 8443
netstat -ano | findstr 8443Կարդացեք տեղական հասցեի սյունակը, ոչ թե վիճակը։ 127.0.0.1:8443 նշանակում է միայն loopback, և ուղղումը 0.0.0.0-ին կամ հենց թունելի հասցեին կապելն է։ 0.0.0.0:8443-ը ընդունում է բոլոր ինտերֆեյսների վրա, ինչը ավելի լայն է, քան մարդկանց մեծ մասը նկատի ունի, երբ մեքենան ունի նաև հանրային հասցե. 10.64.7.15:8443-ը նեղ տարբերակն է, որը լսում է միայն այնտեղ, որտեղ գործընկերը կարող է հասնել։ Նշեք նաև գործընթացի անունը նույն ելքում, որովհետև նախորդ փորձարկումից մնացած ավելորդ օրինակը սովորական պատճառ է, որ պորտը բաց է թվում և սխալ բովանդակությամբ պատասխանում։
Ապա հարցրեք, թե արդյոք ինչ-որ բան կարող է երթուղավորել այդ հասցեին
Թունելի հասցեն իմաստ ունի միայն այն գործընկերների համար, որոնք կարգավորված են այդ նախածանցն ուղարկել թունել։ Գործընկերոջ մեքենան ունի իր աղյուսակը, և եթե թունելի ենթացանցի համար երթուղի չկա, փաթեթը գնում է լռելյայն դարպասին և մահանում այնպիսի տեղում, որը գաղափար չունի հասցեի գոյության մասին։ Սա երթուղավորման հարց է զանգահարողի կողմում, ոչ թե թույլտվություն ձեր կողմում։
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Երկու հաճախորդների միջև սերվերը նույնքան կարևոր է։ Հեռահար մուտքի սովորական ձևավորման մեջ յուրաքանչյուր հաճախորդ բացում է ելքային միացում դեպի դարպաս, և դարպասը պահում է այդ հոսքերի վիճակը, այնպես որ պատասխանները վերադառնում են իրեն արդեն հայտնի ուղով։ Մի հաճախորդից մյուսին միացումը նոր հոսք է, որը դարպասը պետք է ընդունի և փոխանցի, և շատ տեղակայումներ դա միտումնավոր անջատում են՝ հաճախորդներին միմյանցից մեկուսացված պահելու համար։ Սպառողական VPN ծառայությունները սովորաբար մեկուսացնում են լռելյայն. կորպորատիվ դարպասները երբեմն դա թույլատրում են ըստ խմբի։
Ստուգեք ուղղությունը նախքան հոսթի վրա ինչ-որ բան փոխելը։ Եթե թունելի հասցեն պատասխանում է հենց դարպասից, բայց ոչ գործընկերոջից, տարբերությունը դարպասի հաճախորդ-հաճախորդ կարգավորումն է, և տեղական հրշեջ պատի ոչ մի խմբագրում չի փոխարինի դրան։
Վերջում գտեք այն քաղաքականությունը, որը թույլ է տալիս հոսքը
Երեք քաղաքական շերտ են կանգնած երթուղավորված փաթեթի և պատասխանող ծառայության միջև. VPN սերվերի փոխանցման որոշումը, հոսթի հրշեջ պատը և ցանկացած ամպային անվտանգության խումբ օրինակի դիմաց։ Երեքն էլ պետք է համաձայնեն, և նրանք ձախողվում են տարբեր ձևերով, դրա համար էլ վերևի աղյուսակի ախտանիշն ավելի օգտակար է, քան բրաուզերի սխալի հաղորդագրությունը։
Հոսթի հրշեջ պատը այն շերտն է, որ մարդիկ մոռանում են հաջող կապումից հետո, որովհետև LAN ինտերֆեյսում պորտը թույլատրող կանոնը ավտոմատ չի թույլատրում այն թունելի ինտերֆեյսում։ Ինտերֆեյսով սահմանափակված կանոնները ճիշտ ձևավորում են և միևնույն ժամանակ սովորական պատճառն այն ծառայության, որը աշխատում է գրասենյակից, բայց ոչ տնից։ Կարդացեք կանոնի ծավալը, ոչ թե նրա պորտի համարը։
Վիճակով զտումը բացատրում է հակառակ դեպքը։ Ձեր նոթբուքից ելքային միացումը վիճակ է ստեղծում, և դրա պատասխանները թույլատրվում են առանց մուտքային կանոնի։ Գործընկերոջ միացումը լրիվ նոր հոսք է՝ առանց իր հետևում վիճակի, ուստի այն պահանջում է բացահայտ թույլտվություն։ Այդ ասիմետրիան է ամբողջ պատճառը, թե ինչու ձեր սեփական մեքենայի վրա աշխատող բրաուզերի սեսիան ոչինչ չի ասում այն մասին, թե արդյոք ծառայությունը հասանելի է դրսից։
Երբ մի ստուգում ձախողվի, փոխեք ձևավորումը, ոչ թե թունելը
Եթե պահանջն այն է, որ գործընկերը բացի ձեր տեղական ծառայությունը, ազնիվ պատասխանը սովորաբար մուտքային հասանելիության համար կառուցված մեխանիզմն է։ Հակառակ SSH թունելը ամենափոքրն է. ձեր մեքենան ելքային միացում է հաստատում այնպիսի հոսթի հետ, որին գործընկերն արդեն կարող է հասնել, և լսորդը գոյություն ունի այդ հոսթում։
ssh -N -R 8443:127.0.0.1:8443 [email protected]Ռելեն իր SSH սերվերի կազմաձևում պահանջում է GatewayPorts clientspecified, այլապես փոխանցված լսորդը ռելեում կապվում է loopback-ին, և գործընկերը բախվում է նույն մերժմանը, ինչ նախկինում։ Այն ամենի համար, ինչը տևում է ավելի քան մեկ կեսօր, բեռնվածքի հավասարակշռիչը կամ ingress-ը՝ առողջության ստուգմամբ և հրապարակված անվան վկայականով, ավելի լավ գործիք է, և կայք-կայք թունելը՝ երկու ենթացանցերի երթուղիներով, ճիշտ պատասխանն է, երբ երկու ցանցերն իսկապես պետք է խոսեն։
Այդ ձևավորումներից յուրաքանչյուրը բացահայտ է դարձնում ազդեցությունը, և դա է իմաստը։ VPN-ը փաթեթներ է տեղափոխում այն ցանցերի միջև, որոնք դուք արդեն լիազորված էիք օգտագործել. այն ծառայություն չի հրապարակում և նոթբուքը չի վերածում ինտերնետին ուղղված հոսթի։ Խնդիրը որոշելն է, թե երեք շերտերից որն փոխել, և թունելը հազվադեպ է դրանցից մեկը։