pfSense-ը որպես VPN սերվեր և կլիենտ՝ երկու ուղի, մեկ երթուղիչ

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

Անվանեք երկու դերերը՝ նախքան որևէ կարգավորում դիպչելը

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

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

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

Պահեք սերվերի պատասխանները WAN ուղու վրա

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

Չկա մեկ նշիչ, որը լուծում է սա, որովհետև որոշումը վերաբերում է նրան, թե ինչ երթևեկություն կարող է բռնել ելքային կլիենտը։ Կամ ոչ մի երթուղի մի քաշեք և ուղղորդեք միայն այն, ինչ ընտրում եք, կամ քաշեք երթուղիները և ավելացրեք այն բացառությունները, որոնք պահում են սարքի սեփական ծառայությունները աշխատունակ։ Գրեք ընտրությունը օրինակի կողքին, այլապես հաջորդ մարդը կենթադրի մյուսը։

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

Թույլ մի տվեք, որ ելքային թունելն ուտի իր սեփական վերջնակետը

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Ընտրեք, թե որ օգտատերերն են ստանում ելքը

Աղբյուրի քաղաքականությունը պատկանում է մուտքին, որտեղ երթևեկությունը մտնում է սարք, այնպես որ ընտրեք հեռահար մուտքի լողավազանը կամ դրա ներսի ավելի նեղ ինքնություններ։ Պահպանեք այն մասնավոր նպատակակետերն ու կառավարման բացառությունները, որոնք երբեք չպետք է ուղարկվեն ելք, և այդ կանոնները դրեք լայնից առաջ։ Այնուհետև ելքի ուղուն պետք է իր սեփական թարգմանությունը կամ երթուղավորված վերադարձի կարգավորումը, ինչը նախագծերի մեծ մասում նշանակում է ելքային NAT ելքի ինտերֆեյսի վրա՝ ծածկելով լողավազանը։ Թարգմանությունը ելք չի ընտրում. այն միայն վերաշարադրում է այն, ինչ արդեն դուրս է եկել, ուստի անկապ WAN-ի վրա NAT կանոնը ոչինչ չի փոխում ընտրության մեջ։

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

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

Որոշեք, թե ինչ է լինում, երբ ելքը խափանվում է

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

Անջատեք կլիենտի օրինակը, դիտեք, թե միացված օգտատերը դեռ ինչի կարող է հասնել, ապա նորից գործարկեք այն։ Ժամկետը լրացնող հարցումը ձեր խնդրած ամբողջական արգելափակման արդյունքն է. այն, որը պատասխանում է WAN հասցեով, այն վերադարձն է, որը չեք փաստաթղթավորել։ Կրկնեք ստուգումը IPv6-ի և DNS-ի համար, որովհետև IPv4-ի համար գրված քաղաքականությունը ոչինչ չի ասում AAAA երթևեկության մասին, և թունելներից որևէ մեկի մղած լուծիչը պատասխանում է այնտեղից, որտեղից հարցումն իրականում դուրս է գալիս։

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

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