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

Ինչ է իրականում տեղադրել հաճախորդը

Հարցրեք, թե որ ինտերֆեյսը փաթեթը կտանի իրական նպատակակետ, փոխանակ հարցնելու՝ թունելը միացվա՞ծ է։ Թունելը, որն այդ նպատակակետի երթուղի չունի, մասնավոր ճանապարհ է, որով ոչ ոք չի գնում։

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

Առաջին հրամանը պատասխանում է Linux-ում և macOS-ում, իսկ մյուս երկուսը Windows-ի համարժեքներն են, որտեղ մեկը բավական է։ Եթե պատասխանը նշում է ֆիզիկական ադապտերը, թունելը միացված է, և լռելյայն երթուղին երբեք չի շարժվել։ Կրկնեք ստուգումը նպատակակետի համար, որը պետք է օգտագործի թունելը, քանի որ երկու ստուգում՝ մեկը հեռավոր և մեկը սովորական, ասում են, թե որ նախագիծն է տեղակայված։

Ընտրովի երթուղավորման երեք ձև

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Կարդացեք պրոֆիլը որոշող հրահանգի համար, ապա աղյուսակը՝ այն բանի համար, ինչ այն արտադրել է։ Հրահանգը կարող է ճնշվել նաև հաճախորդի կողմից, դրա համար պրոֆիլը և աղյուսակը պետք է համընկնեն, նախքան սերվերին մեղադրելը։

Հեռավոր կողմը պետք է վերագրի աղբյուրի հասցեն

Կա երկրորդ խափանում, որը զննարկիչից նույնն է թվում։ Երթուղին տանում է թունելի մեջ, սերվերը ստանում է փաթեթները, ապա փոխանցում դրանք հաճախորդի մասնավոր հասցեով անփոփոխ։ Հաջորդ թռիչքը այդ հասցեի համար վերադարձի ուղի չունի, ուստի պատասխանները անհետանում են, և էջերը կախվում են։ Սերվերը պետք է ընդհանրապես փոխանցի, և պետք է թարգմանի աղբյուրը մի բանի, որը ինտերնետը կարող է հետ երթուղավորել։

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Անվանեք ինտերֆեյսը, որն իրոք նայում է ինտերնետին, ինչը ժամանակակից բաշխման մեջ միշտ eth0 չէ։ Ֆիքսված հասցեով հոսթինգ սերվերը կարող է ուղղակիորեն թարգմանել այդ հասցեին՝ masquerade-ի փոխարեն։ Երկու կեսերն էլ կարևոր են, քանի որ առանց թարգմանության փոխանցումը արտահոսում է չերթուղավորելի աղբյուրներ, իսկ առանց փոխանցման թարգմանությունը երբեք չի տեսնում փաթեթը։

Անունների լուծումն իր ուղին ունի

Երթևեկությունը կարող է դուրս գալ թունելով, մինչ անունը գտած ստուգումը գնացել է տեղական ցանցի լուծիչի մոտ։ Տեսանելի հասցեն մնում է նույնը, ստուգումները՝ ոչ, և այդ բացը հենց այն է, ինչ ընտրում է բաժանված DNS-ի նախագիծը։

resolvectl status | head -20
resolvectl query example.org

Նկատեք, թե որ սերվերն է պատասխանել և արդյոք այն տարբերվում է թունելից առաջ ելակետից։ Բաժանված թունելում սա սովորաբար այն կարգավորումն է, որ մարդիկ ուզում էին փոխել, երբ բողոքում էին հասցեից, և հենց այն, որին երբեք չեն նայել։

Չորս դիտարկում, որոնք լուծում են հարցը

Գրանցեք ելքի հասցեն թունելն անջատված, ապա միացված։ Գործարկեք նպատակակետի ստուգումը երկու վիճակում և ամեն անգամ նշեք ինտերֆեյսը։

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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

Առնչվող հոդվածներ