Ինչու OpenVPN-ի հաճախորդները բաց թողնում են դարպասի IPsec ընտրիչները
Դարպասից արված ping-ը ապացուցում է այլ հոսք։ Հետևեք հաճախորդների պուլին հրող ուղու, IPsec ընտրիչների, փոխանցման շղթայի և պատասխանի ուղու միջով։
Ping արեք դարպասից հեռավոր IPsec թունելի հետևում գտնվող հոսթին, և այն մաքուր պատասխանում է, այնպես որ թունելը առողջ է թվում, և տոմսը շարժվում է առաջ։ Այնուհետև միացված հաճախորդ փորձում է նույն հոսթը և ոչինչ չի ստանում։ Այդ ping-ը երբեք հաճախորդի հոսքի ապացույց չի եղել, որովհետև այն դուրս է եկել դարպասի սեփական աղբյուրի հասցեով և համընկել է այլ IPsec ընտրիչի հետ։ Հասկանալը, թե ինչու են այս երկու դեպքերը տարբերվում, ուղղման մեծ մասն է։
Դարպասի ping-ը ստուգում է հոսք, որը ձեր հաճախորդը երբեք չի օգտագործում
Աղբյուրի հասցեն է որոշում, թե որ քաղաքականությունն է գործում։ Դարպասի վրա ստեղծված փաթեթը դուրս է գալիս իր տեղական LAN-ի կամ թունելի վերջնակետի հասցեով, և դրան համապատասխանող քաղաքականությունը գրվել է հենց այդ դեպքի համար։ Հաճախորդի փաթեթը OpenVPN ինտերֆեյս է հասնում հաճախորդների պուլի հասցեով, ինչը բոլորովին այլ ընտրիչ է։
Այդ պատճառով խափանումը նման է երթուղավորման խնդրի, մինչդեռ իրականում քաղաքականության ծավալի խնդիր է։ Դարպասից հասանելիությունը ապացուցում է, որ գործընկերը աշխատում է և առաջարկները բանակցված են, և ոչինչ չի ապացուցում այն մասին, թե արդյոք պուլը պաշտպանված է։
Հրեք այն հեռավոր նախածանցը, որն իսկապես անհրաժեշտ է հավելվածին
Վերցրեք 10.8.0.0/24 և 172.30.239.0/25 պատկերավոր զույգը՝ միացված հաճախորդների և պաշտպանված հեռավոր ցանցի համար։ Հաճախորդին պետք է երթուղի դեպի այդ երկրորդ նախածանցը, ոչ դարպասի LAN, և ոչ էլ որևէ այլ թունելի հասցե։ Պուլի մեջ հրված երթուղին է, որ ստիպում է հաճախորդին ընդհանրապես այդ տրաֆիկը հանձնել դարպասին։ Առանց դրա փաթեթը երբեք չի հասնում այն քաղաքականության որոշմանը, որը դուք վրիպազերծում եք։
Community սերվերում, որն ընդունում է հրված երթուղիներ, հրահանգը վերցնում է իրական դիմակը՝ push "route 172.30.239.0 255.255.255.128"։ Access Server-ը նույն նպատակակետը կարգավորում է տեղադրված տարբերակի մասնավոր ցանցի կամ մուտքի կանոնների կարգավորումներով՝ երթուղային կամ թարգմանված ռեժիմը գիտակցաբար ընտրելով։ Գեներացված firewall շղթաները սեփական կոնֆիգուրացիայի փոխարեն խմբագրելը հենց այն ուղին է, որով աշխատող տեղակայումը դառնում է անվերարտադրելի։
Միանալուց հետո կարդացեք հաճախորդի երթուղային աղյուսակը, ոչ թե սերվերի մտադրությունը։ Միայն պուլը ծածկող երթուղին նշանակում է, որ հրումը երբեք չի հասել, իսկ թունելով անցնող լռելյայն երթուղին ավելի լայն է այս պահանջից և ուշ կզարմացնի ձեզ։ Ստուգեք դիմակը և նախածանցը, որովհետև /25-ը որպես /24 հրելը հարևան հասցեների տրաֆիկը ուղարկում է ուղի, որը չի կարող տանել այն։ Այնուհետև հաստատեք, որ հաճախորդը այդ նպատակակետի համար ընտրել է թունելի ինտերֆեյսը։
Թող ընտրիչները ներառեն հաճախորդների պուլը
Հաճախորդների հասցեները պահպանող երթուղային մուտքի համար IPsec քաղաքականությունը պետք է պաշտպանի պուլի և հեռավոր նախածանցի միջև տրաֆիկը։ Դարպասի սեփական LAN-ի համար գրված ընտրիչները թույլ են տալիս ping-ը և գցում հաճախորդի հարցումը, և սա հենց այն անհամաչափությունն է, որով սկսվեց այս հետաքննությունը։
Քննեք բանակցված քաղաքականությունը և կարգավորված առաջարկները, օրինակ strongSwan-ում ipsec statusall-ով կամ ձեր իրականացման համարժեք կարգավիճակի հրամանով։ Քաղաքականության վրա հիմնված IPsec-ում սովորական երթուղին կարող է ցույց տալ ֆիզիկական ինտերֆեյսի, մինչ համապատասխան տրաֆիկը դեռ գաղտնագրվում է, ուստի թունելի սարքի բացակայությունը ոչինչ չի ապացուցում։ Համեմատեք ընտրիչների զույգերը ձեր գրած պուլի և նախածանցի հետ։
Դարպասի վրա ընդհանուր աղբյուրային NAT-ը նույնպես կարող է կոտրել համընկնումը։ Եթե masquerade կանոնը վերագրում է հաճախորդի աղբյուրը նախքան քաղաքականության ստուգումը, փաթեթն այլևս չի նմանվում ձեր գրած ընտրիչին։ Սա է պատճառներից մեկը, թե ինչու լայն masquerade կանոնը վատ լուծում է երկրորդ VPN-ի համար. այն փոխում է, թե որ քաղաքականությունն է գործում և որ հասցեն է գրանցում հեռավոր կողմը։ Ազատեք այն տրաֆիկը, որը մտադիր եք երթուղավորել, կամ գիտակցաբար թարգմանեք այն և թարմացրեք ընտրիչները։
Գիտակցաբար ընտրեք երթուղավորում կամ թարգմանություն
Երթուղավորումը հաճախորդի հասցեն տեսանելի է պահում հեռավոր կողմի համար, այնպես որ հեռավոր մատյաններն ու աղբյուրով պայմանավորված կանոնները մնում են իմաստալից, և պահանջում է, որ հեռավոր դարպասը իմանա պուլ վերադարձի ուղին։ Թարգմանությունը պուլը թաքցնում է մեկ հասցեի հետևում, ինչը վերացնում է վերադարձի ուղու խնդիրը և ոչնչացնում յուրաքանչյուր հաճախորդի ինքնությունը։
Ընտրեք մեկ դիզայն և գրեք այն, որովհետև երկուսին պետք են տարբեր ընտրիչներ և տարբեր firewall հերթականություն։ Կիսով կիրառված masquerade-ը ընկնում է նրանց միջև և ոչ մեկին չի բավարարում։ Գրավոր ընտրությունն է նաև այն, ինչ թույլ է տալիս հաջորդ ինժեներին տարբերել սխալը գիտակցված որոշումից։
Փակեք շղթան փոխանցման և պատասխանի վրա
Դարպասը պետք է փոխանցի այն արձանագրությունն ու նպատակակետը, որ նկատի ունեք, ինչը նշանակում է միացված IP փոխանցում և փոխանցման շղթա, որը թույլ է տալիս զույգին։ Այնուհետև հեռավոր կողմը պետք է պատասխանները հետ ուղարկի IPsec ուղով, և դա երթուղավորման որոշում է նրանց դարպասի վրա, ոչ ձերին։ Երկու կեսերն էլ սովորական կոնֆիգուրացիա են, և երկուսն էլ հեշտ է կիսատ թողնել։ Փորձարկեք դրանք առանձին, որպեսզի բացակայող փոխանցման կանոնը չշփոթվի կոտրված թունելի հետ։
Ստուգեք մեկ իրական հաճախորդից հավելված հարցումով՝ դիտելով, թե ինչպես է այն անցնում OpenVPN ինտերֆեյսով, IPsec որոշմամբ և հեռավոր հոսթով։ Քննեք պատասխանը որպես առանձին դիտարկում, որովհետև հասնող հարցումը և երբեք չվերադարձող պատասխանը հաճախորդի տեղից նույն տեսքն ունեն։ Մեկ հետագծված հարցումն ավելի արժեքավոր է, քան ցանկացած քանակի ping դարպասից։
Փորձարկման ընթացքում նպատակակետի լիազորումը նեղ պահեք և հաստատեք, որ առանց կանոնի հաճախորդը չի կարող հասնել ծառայությանը։ Տեղադրված երթուղին և հաստատված ասոցիացիան նույնը չեն, ինչ տրված մուտքը։