Երկու սպասարկման հասցե մեկ OpenVPN հաճախորդի վրա՝ iroute և lo

Ծրագիրը պատասխանում է իր թունելի հասցեով, իսկ ձեր փաստաթղթավորած հասցեն ոչ մի տեղ չի տանում։ Ոչինչ չի բողոքում OpenVPN-ի մատյանում, գործընկերը ցուցադրվում է միացված, և հանգույցը թվարկում է ուղիղ մեկ հաճախորդ։ Բացը նրանում է, որ հաճախորդի երկրորդ հասցեն երկու առանձին փաստ է. հյուրը պետք է տիրապետի դրան, և հանգույցը պետք է իմանա, թե որ գործընկերն է տիրապետում։ Կարգավորեք մեկը առանց մյուսի, և երթևեկությունը կա՛մ մահանում է հանգույցում, կա՛մ հասնում է առանց տուն վերադարձի երթուղու։

Կեղծանունը տեղային է, սեփականությունը՝ հեռավոր

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

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

Ձեր նշումներում նույնպես երկու միջակայքերը առանձին պահեք։ Օրինակի հասցեները փաստաթղթային արժեքներ են, և դրանք իրական LAN-ի հետ համընկնելը ամենաարագ ճանապարհն է աշխատող կարգավորումը կոտրված ցույց տալու։

Ավելացրեք հասցեն հաճախորդի վրա մշտապես

Տեղադրեք սպասարկման հասցեն loopback-ի վրա հյուրի նախածանցով, որպեսզի հյուրը այն վերաբերվի որպես տեղային մուտք, այլ ոչ որպես հասանելի ենթացանց։ ip address add 10.66.0.10/32 dev lo դա անում է մեկ հասցեի համար, և հրամանի կրկնությունը երկրորդ հասցեի համար մոդելավորում է երկու ծառայություն։

Գործարկեք դա որպես մեկանգամյա փորձարկում, ապա տեղափոխեք այն ամենի մեջ, ինչը տիրապետում է հյուրի ցանցային կարգավորումներին, քանի որ գործարկման ընթացքում ավելացվածը անհետանում է վերագործարկման ժամանակ, և կրկնօրինակները կուտակվում են վերամիացումների միջև։ Ցանցից հետո դասավորված systemd միավորը մեկ տարբերակ է, իսկ տարածման ցանցային կառավարիչը՝ մյուսը։ Ինչ էլ ընտրեք, հասցեն պետք է գոյություն ունենա նախքան ծրագրի կապվելը, այլապես ծառայությունը կբարձրանա սխալ սոքեթի վրա։ Ստուգեք ip address show dev lo-ով վերագործարկումից հետո, ոչ թե ձեռքով հրամանից հետո։

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

Պահանջեք այն CCD ֆայլում, որը հանգույցն իրականում կարդում է

Սերվերի վրա սեփականության հայտարարությունը գնում է այն ֆայլը՝ ըստ հաճախորդի, որը ընտրվում է նույնականացված ընդհանուր անունով, client-config-dir-ով անվանված պանակի ներսում։ Տողը iroute 10.66.0.10 255.255.255.255 է, մեկը յուրաքանչյուր հասցեի համար, և այն սերվերին ասում է, թե որ գործընկերը պետք է ստանա երթևեկություն այդ նպատակակետի համար։

Երկու մանրամասնություն լուռ կոտրում են սա։ Ֆայլի անունը պետք է համընկնի սերվերի իրականում օգտագործած անվան հետ, որը տարբերվում է, երբ խաղի մեջ է username-as-common-name։ Եվ iroute ուժի մեջ է մտնում միայն TUN ռեժիմում՝ կարգավորված հաճախորդի կարգավորումների պանակով, ուստի նույն տողը ոչինչ չի անում կամուրջային տեղակայման մեջ։ Տողեր ավելացրեք գոյություն ունեցող ֆայլին՝ այն փոխարինելու փոխարեն, քանի որ այն կարող է արդեն կրել ֆիքսված հասցե կամ push ընտրանքներ։ OpenVPN 2.6 տեղեկատուն փաստաթղթավորում է և՛ պանակը, և՛ սեփականության հրահանգը։

Հանգույցի սեփական միջուկին նույնպես պետք է ուղի դեպի այդ նպատակակետերը, որպեսզի տեղում ստեղծված երթևեկությունը մտնի թունելի գործընթաց։ Սերվերի կարգավորումներում route 10.66.0.10 255.255.255.255-ը ծածկում է սերվերի իսկ ստեղծած երթևեկությունը, մինչդեռ այլ հաճախորդներին պետք է push "route 10.66.0.10 255.255.255.255"՝ նպատակակետն ինքնուրույն սովորելու համար։

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

Ստուգեք մուտքի քաղաքականությունը և պատասխանի ուղին

Կեղծանունին հասցեագրված փաթեթը հասնում է տիրապետող հյուրին որպես տեղային մուտք, ուստի հարցն այն է՝ արդյոք տեղային հրապարակը թույլատրում է այդ աղբյուրն ու պորտը։ Թույլատրեք կոնկրետ սպասարկման պորտը VPN աղբյուրի միջակայքից՝ ամբողջ հասցեն բացելու փոխարեն։

Պատասխաններին պետք է վերադարձի ուղի դեպի զանգահարողը։ Սովորական թունելային լողավազանի ներսում գտնվող զանգահարողի համար այդ ուղին արդեն գոյություն ունի, քանի որ այն կրում է թունելի սարքը։ Մեկ այլ երթուղավորված ցանցի հետևում գտնվող զանգահարողին պետք է նաև այդ ցանցի վերադարձի ուղին, և հենց այստեղ են ասիմետրիկ կարգավորումները կորցնում փաթեթներ։

Ուշադրություն դարձրեք նույն պորտի վրա մեկ այլ հասցեին կապված երկրորդ լսողի, քանի որ միջուկը հանձնում է այն սոքեթին, որը համընկնում է, և արդյունքները պատահական են թվում։ Ստուգեք ss -lntp-ով և հաստատեք, որ կապված հասցեն սպասարկման կեղծանունն է։ Աղբյուրի NAT-ը այստեղ պարտադիր չէ, և դրա ավելացումը թաքցնում է զանգահարողի ինքնությունը, որից կախված են ձեր մատյանները։

Փորձարկեք հասցեները և սեփականությունը առանձին

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

Ստուգեք նաև ձախողման ռեժիմները, որոնք վերապրում են կապը. կեղծանունը մնում է նշանակված, երբ թունելը իջեցված է, և հանգույցը պահում է իր երթուղին, երբ գործընկերը բացակայում է։ Ոչ մի օբյեկտ ինքնին չի ապացուցում, որ ծառայությունը հասանելի է, դրա համար էլ երկքայլ փորձարկումը գերազանցում է նոութբուքից մեկ ping-ին։