NAT-ով LAN-ը tun0-ի միջով OpenBSD VPN դարպասի վրա

Նույն OpenBSD դարպասով երկու ինժեներ հաճախ քեզ կտան հեռավոր ցանցին հասնելու երկու տարբեր կանոնների հավաքածու, և երկուսն էլ կարելի է պաշտպանել։ Աղբյուրի թարգմանության և վերադարձի երթուղու միջև ընտրությունը բոլորովին շարահյուսության հարց չէ։ Ամեն ինչ կախված է նրանից, թե հեռավոր կողմն ինչ գիտի 192.168.88.0/24-ի մասին և ինչ պետք է պահես քո մատյաններում։ Սխալվիր դրանում, և nat-to տողը կթվա կատարյալ ճիշտ, մինչ պատասխանները կանհետանան հեռավոր լռելյային դարպասում։

Երթուղավորումը և վերաշարադրումը պատասխանում են տարբեր հարցերի

Երթուղային աղյուսակը որոշում է, որ 172.20.0.0/16-ը հասանելի է tun0-ով, և այդ որոշումը կայացվում է նախքան որևէ pf թարգմանության հետ խորհրդակցվելու։ Աղբյուրի թարգմանությունն այնուհետև փոխում է փաթեթի վերնագիրը, որպեսզի հեռավոր ծայրը տեսնի դարպասի թունելի հասցեն և ոչ LAN հյուրը։ Ոչ մի մեխանիզմ չի փոխարինում մյուսին. nat կանոնը չի կարող երթուղի ստեղծել, իսկ երթուղը չի կարող համոզել հեռավոր երթուղիչին, որը երբևէ չի լսել քո մասնավոր ենթացանցի մասին։ Երբ հեռավոր կողմը չունի վերադարձի ուղի, պատասխանները դեն են նետվում կամ ուղարկվում նրա լռելյային դարպասին, և կանոնների ոչ մի լարում չի ուղղում դա։

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

Երեք պայման, որոնք որոշումը են կայացնում

Տուր երեք հարց հերթով, և նախագիծը սովորաբար ինքն է ընտրվում։ Արդյոք հեռավոր ցանցն ունի ստատիկ երթուղի, որն ուղղված է թունելի հասցեին 192.168.88.0/24-ի համար, թե՞ նրա ադմինիստրատորը վերահսկում է այդ ուղու երթուղիչներին։ Եթե այո, թող LAN հասցեները ճամփորդեն առանց փոխության և ընդբողն բաց թողնեք թարգմանությունը։ Դեզ պետք է հեռավոր կողմում համար հասանելիություն յուրաքանչյուր համար՝ թե՞ մուտքի քաղաքականության, թե՞ աուդիտի հետքի համար։ Եթե այո, աղբյուրը պահելը արժանի է երթուղավորման աշխատանքը։ Արդյոք թունելի հասցեն բավարար կայուն է հեռավոր երթուղում գրելու համար, թե՞ այն փոխվում է վերամիությունների միջև։

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

Հատվածը տեղադրել այնպես, որ pf-ը իրոք գնահատի այն

Ստորև բերված հատվածը ենթադրում է, որ LAN-ը 192.168.88.0/24 է, հեռավոր ցանցը՝ 172.20.0.0/16, իսկ թունելի ինտերֆեյսը՝ tun0։ Դրանում ոչինչ հաջորդ թռիչք չի ընտրում։ Այն միայն վերաշարադրում է աղբյուրը այն փաթետներում, որոնք արդեն դուրս են գալիս թունելով։

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Այդ առաջին տողի երկու մանրամասներն են կրում ամենամեծ ծանրը։ tun0-ի շուրջ փակագծերը pf-ին ասում են կարդալ ինտերֆեյսի հասցեն ամեն անգամ, երբ վիճակի գրառում է ստեղծում, ինչը կարևոր է, երբ թունելը վերահամարակրացվում է վերամիությունից հետո։ match բառը նշանակում է, որ կանոնը վերաշարադրում է, ապա ընկնում ներքևում, ուստի առանձին pass կանոնը դեռ պետք է թույլատրի հոսքը։ match տողում նշված ինտերֆեյսը նույնպես պետք է լինի այն, որը ընտրում է երթուղային աղյուսակը, հակառակ դեպքում pf-ը կանոնը կգնահատի մեկ այլ ելքային ուղուվ, քան այն, որով փաթեթը իրոք անցնում է։

Չմոռանաս միջուկի կողմը։ IPv4 փոխանցումը պետք է միացված լինի, և թունելի և LAN-ի վիճակով pass կանոնները պետք է գոյություն ունենան նախքան այս ամենը իմաստ ստանար։ OpenBSD FAQ-ի PF NAT բաժինը ճիշտ հղումն է այստեղ հիմնաբառերի հերթականության համար։

Ստուգիր կանոնների հավաքածուն նախքան երթևեկությանը վստահելը

Նախ ստուգիր շարահյուսությունը pfctl -nf /etc/pf.conf-ով, որը վերլուծում է ֆայլը առանց բեռնելու։ Այնուհետև բեռնիր քաղաքականությունը և հետ կարդա այն, ինչ իրոք պահում է միջուկը, որովհետև մաքուր վերլուծված կանոնը դեռ կարող է ստվերվել կամ կցվել սխալ ինտերֆեյսին։ pfctl -sn-ը տպում է թարգմանության կանոնները բեռնված տեսքով, իսկ pfctl -sr-ը՝ զտիչ կանոնները գնահատման կարգով։

Հետո հետևիր լարին։ Դարպասի վրա tcpdump -ni tun0 'host 172.20.0.10'-ը ցույց տալիս, թե թունելից դուրս եկող աղբյուրի հասցեն թունելի հասցենզ է, թե՞ LAN հյուրը։ Արագ netstat -rn -f inet-ը հաստատում է, թե որ ինտերֆեյսին է լուծվում նպատակը։ Երբ երթևեկությունը սկսի հոսել, pfctl -ss-ը թվարկում է վիճակի գրառումները. եթե հոսքը վիճակ չի ստեղծել, փաթեթը երբևէ չի հանդիպել այնպիսի կանոնի, որը մեկը կստեղծի։

Եթե թունելի կողմը ճիշտ է թվում, իսկ պատասխանները դեռ չեն գալիս, դադարեցրու pf-ը խմբագրելուց։ Մնացած խափանումը հեռավոր երթուղիչի վրա է, որտեղ պատասխանը ուղարկվում է դեպի մասնավոր հասցեի, որին այդ կողմը չի կարող հասնել։

Երբ թարգմանությունն ավելի թանկ է նստում, քան խնայում է

Թարգմանությունը թաքցնում է հաճախորդներին, և երբեմն դա հենց սխալ գործարքն է։ Համընկնող ենթացանցը մեկ դեպք է. եթե հեռավոր կողմը նույնպես ներսին օգտագործում է 192.168.88.0/24-ը, ապա LAN հյուրերը դարպաս ներկայացնելությունը բախումը դարձնում է շատ վատթար, քան լավացնում։ IPsec քաղաքականությունները, որոնւ ընտրում են երթևեկությունը ըստ հասցեզույգի, մեկ այլ դեպք են, քանի անվտանգության քաղաքականության տվյալները համեմատվում են թարգմանությունից առաջ, և երբևէ չի տեսնում ցանցագրված փաթեթը։ Ցանկացաց տեղադրումը, որը հաշվարկում է, սահմանափակում կամ աուդիտ է անում յուրաքանչյուր օգտատիրոջ, նույնպես կորցնում է այն ինքնությունը, որը զին անհրաժեշտ է, այն պահին, երբ աղբյուրը կրճվում է մեկ հասցեի։

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

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