Ո՞ր հասցեն պետք է գրվի DNS-ում VPN-ով միացված սերվերի համար։
Հոստինգում տեղակայված սերվերն ունի երեք հասցե, և դրանք փոխարինելի չեն։ Ընտրեք այն արժեքը, որն անհրաժեշտ է յուրաքանչյուր ծառայությանը, ապա հաստատեք այն մեքենայից դուրս։
VPN տեղադրված հոստինգային սերվերը վերջում պահում է երեք հասցե, և դրանցից միայն մեկն է պատկանում յուրաքանչյուր այն տեղին, որը դուք պատրաստվում եք կարգավորել։ Համարը մատակարարի վահանակից DNS, լսորդ կամ թույլատրելիների ցանկ պատճենելը այն ուղին է, որով աշխատող թունելը դառնում է ծառայություն, որին ոչ ոք չի կարող հասնել։ Այս ուղեցույցը դասավորում է աշխատանքը այնպես, որ յուրաքանչյուր հասցե ընտրվի հայտարարված նպատակի համար։ Այն նաև թվարկում է հրամանները, որոնք հաստատում են, թե իրականում ինչ եք հրապարակել։
Քարտեզագրեք երեք հասցեները նախքան որևէ բան հրապարակելը
Անվանեք դրանք ըստ գործառույթի։ underlay հասցեն այն է, ինչ մեքենան օգտագործում է VPN-ի վերջնակետին ինտերնետով հասնելու համար, և այն հաճախ մասնավոր է մատակարարի NAT-ի հետևում։ Թունելի հասցեն ապրում է VPN-ի ներսում և տրվում է սերվերի կամ հաճախորդի կողմից՝ կախված արտադրանքից։ Հանրային ելքը այն հասցեն է, որը հեռավոր կայքը գրանցում է թարգմանությունից հետո, և այն պարտադիր չէ, որ գոյություն ունենա որևէ ինտերֆեյսում, որը կարող եք հարցնել։
Վահանակը, որը մեքենայի համար ցույց է տալիս մեկ հանրային հասցե, շատ քիչ բան է ասում մյուս երկու դերերի մասին։ underlay-ի հասանելիությունը պահանջ է, ոչ գնում. տնային երթուղիչի հետևում գտնվող նոութբուքը կարող է հասնել հոստինգային VPN վերջնակետին՝ առանց հանրային IPv4 հասցե ունենալու։ Ինչ չեք կարող անել, դա ներսային ուղի հորինելն է՝ գրելով անուն, որը լուծվում է հասցեի, որը ոչ ոք չի փոխանցում։
Ընտրեք հասցեն ըստ ծառայության, ոչ ըստ պիտակի
Գրեք, թե ինչ պետք է անի սերվերը նախքան համար ընտրելը։ Արտաքին API կանչերին անհրաժեշտ է կայուն ելք, երբ մյուս կողմը վարում է թույլատրելիների ցանկ։ Մասնավոր մուտքին անհրաժեշտ է թունելի հասցե, որին հաճախորդները կարող են երթուղավորել, և դրան կապված լսորդ։ Հանրային հոստինգին անհրաժեշտ է ներսային քարտեզագրում, որն իրականում առաջարկում է մատակարարը, և միայն ելքի հասցեն դա չի ապահովում։
Մեկ մեքենան կարող է սպասարկել բոլոր երեք նպատակներին և այնուամենայնիվ օգտագործել երեք տարբեր հասցե։ Ինչ որ կոտրվում է, այն այն ենթադրությունն է, որ մեկ արժեքը ծածկում է դրանք բոլորը.
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
Ներսային տողը այն է, ինչի շուրջ մարդիկ վիճում են։ Գրառումը, որը ցույց է տալիս ելքի հասցեին, չի ստեղծում լսորդ, բացվածք հակահրդեհային պատում կամ պորտի քարտեզագրում, և սպասելը դա չի փոխում։ Երբ մատակարարը վաճառում է առանձնացված հասցե ներսային կանոնի հետ միասին, այդ փաթեթն այն կարողությունն է, որը գնել եք. հասցեն ինքնին իրավունք չէ։
Հրամաններ, որոնք ցույց են տալիս, թե որ հասցեն որն է
Կարդացեք մեքենան, ոչ թե վահանակը։ Ինտերֆեյսների անունները տարբերվում են համակարգերում, այնպես որ հասցեները համապատասխանեցրեք սարքերին՝ պիտակին վստահելու փոխարեն։
Առաջին տողը թվարկում է յուրաքանչյուր IPv4 հասցե և դրա սարքը, իսկ երկրորդը հարցնում է միջուկին, թե որ սարքը կօգտագործեր հայտնի արտաքին նպատակակետի համար:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Եթե երթուղու որոնումը հանրային երթևեկության համար պատասխանում է թունելի սարքով, ձեր ամբողջական թունելը գործում է։ Լսորդի ստուգումը նույնքան կարևոր է, քանի որ միայն 127.0.0.1-ին կապված գործընթացը երբեք չի պատասխանի թունելի հասցեում, ինչ անուն էլ հրապարակեք։
Հրապարակեք այն, ապա ստուգեք դրսից
Հրապարակեք միայն այն արժեքը, որն անհրաժեշտ է ծառայությանը. A կամ AAAA գրառում հոստինգի համար, թույլատրելիների ցանկի մուտք արտաքին կանչերի համար, հաճախորդի պրոֆիլ մասնավոր մուտքի համար։ Ապա փորձարկեք այն դիրքից, որը նշանակություն ունի, և դա երբեք այն մեքենան չէ, որը հենց նոր խմբագրեցիք։
Երկու ստուգում ծածկում են մեծ մասը, և երկուսն էլ բավական էժան են, որպեսզի մնան սկրիպտում.
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthDNS պատասխանը, որն ապացուցում է, որ ձեր գրառումը գոյություն ունի, ապացույց չէ, որ հարցումը հասնում է, և մեկ հաջող հարցում ապացուցում է միայն, որ մեկ ուղի աշխատում է մեկ ցանցից։ Կրկնեք ստուգումը բջջային կապից, երբ թույլատրելիների ցանկը ներգրավված է, քանի որ ձեր դիտարկած ելքը կարող է կախված լինել հասցեների ընտանիքից և անցած երթուղուց։ Նշեք, թե որ ընտանիքն եք ստուգել. աշխատող IPv4 ուղին բացարձակապես ոչինչ չի ասում IPv6-ի մասին։
Եթե ծառայությունը ներսային է, ելքի հասցեն բավարար չէ
Ներսային մուտքին անհրաժեշտ է չորս բան մեկ գծում. անուն կամ հասցե, որին հաճախորդը կարող է հասնել, երթուղի, որը փաթեթը հասցնում է մեքենային, լսորդ, որն ընդունում է այն, և քաղաքականություն, որը չի գցում այն։ VPN-ն փոխում է երկրորդ տարրը և երբեմն առաջինը, իսկ երրորդի և չորրորդի համար ոչինչ չի անում։ Երբ թունելը մատակարարման ուղին է, հաճախորդները միանում են թունելի հասցեին, ոչ թե ելքին։
Գրանցեք, թե յուրաքանչյուր ծառայություն որ հասցեից է կախված, ապա վերանայեք այդ նշումը ամեն անգամ, երբ մատակարարը փոխում է իր երթուղավորման մոդելը։ Սերվերը, որը պատասխանում է մասնավոր և ձախողվում է հանրային, սովորաբար կոտրված չէ. այն պատասխանում է սխալ ինքնությամբ, և վերանորոգումը քարտեզագրման որոշում է, ոչ թե հակահրդեհային պատի փոփոխություն։