pfSense-ի ելքային NAT. սկզբում կարդացեք գեներացված կանոնները

Բացեք Firewall-ը, ապա NAT-ը, ապա Outbound-ը և կարդացեք ռեժիմը նախքան որևէ բան ավելացնելը։ Automatic ռեժիմում pfSense-ը կանոններ է գեներացնում WAN ինտերֆեյսների համար և դրանց թվում՝ հեռավոր մուտքի VPN ցանցերի համար, ուստի այն լողավազանը, որը պատրաստվում եք ավելացնել, հաճախ արդեն ծածկված է։ Ձեռքով գրված տողի բացակայությունը վկայություն չէ թարգմանության բացակայության։ Ստորև բերված հերթականությունը հետ է պահում ձեզ ամբողջ firewall-ը Manual դարձնելուց մեկ լողավազան լուծելու համար։

Ռեժիմը որոշում է, թե ով է պահպանում թարգմանությունը սարքի վրա գտնվող մյուս բոլոր ցանցերի համար, և դա ավելի մեծ որոշում է, քան մեկ VPN բացառությունը։

Automatic ռեժիմն արդեն ծածկում է VPN լողավազանը

Յուրաքանչյուր ռեժիմ ունի իր սեփականատերը։ Automatic-ը կանոններ է գեներացնում WAN ինտերֆեյսների համար և իր աղբյուրների թվում ներառում է հեռավոր մուտքի VPN ցանցերը։ Hybrid-ը պահպանում է այդ գեներացված կանոնները և թույլ է տալիս կողքին ավելացնել ձեռքով կանոններ։ Manual-ը դադարում է որևէ բան գեներացնել, ուստի firewall-ի վրա ամեն թարգմանություն դառնում է ձեր պատասխանատվությունը, ներառյալ նրանք, որոնք դուք չեք գրել։ Չորրորդ կարգավորումն ամբողջությամբ անջատում է ելքային NAT-ը։ Ձեռքով գրված թվացող տողը ոչինչ չի ապացուցում, քանի դեռ չգիտեք, թե որ ռեժիմն է ակտիվ։

Automatic և Hybrid ռեժիմներում էջը ցուցադրում է նաև գեներացված կանոնները։ Կարդացեք դրանք նախքան եզրակացնելը, որ VPN լողավազանը թարգմանություն չունի՝ աղբյուրի սյունակում փնտրեք լողավազանի ցանցը, իսկ ինտերֆեյսի սյունակում՝ WAN ինտերֆեյսը։

Hybrid ընտրեք միայն վերանայված բացառության համար

Փաստաթղթավորված բացառությունը դեռ հնարավոր է, երբ ելքի քաղաքականությունն իսկապես տարբերվում է։ Պատկերացրեք սերվեր, որը բաժանում է 10.90.0.0/24, որտեղ firewall-ը պետք է ապահովի IPv4 ինտերնետ ելք, և երթուղավորումն արդեն ընտրում է WAN։ Սպասվող ձևափոխությունն այն է, որ 10.90.0.23 աղբյուրը վերագրվի WAN հասցեին։ Ստուգեք՝ արդյոք գեներացված կանոնն արդեն դա անում է այդ ելքի վրա։ Եթե ոչ, Hybrid-ը պահպանում է ավտոմատ ծածկույթը և ավելացնում ձեր վերանայված կանոնը։

Որպես աղբյուր օգտագործեք իրական VPN լողավազանը կամ դրա համար աջակցվող անվանում, և երբեք չընտրեք անհամապատասխան հասցե միայն այն պատճառով, որ OpenVPN օրինակի անունը բացակայում է ընտրացանկից։ Խուսափեք any աղբյուրից, որը թարգմանում է նաև այն երթևեկությունը, որն ինքը firewall-ն է ստեղծում։

Մեկ լողավազանի համար ամբողջ firewall-ը Manual մի՛ դարձրեք։ Այդ որոշումը վերաբաշխում է սպասարկումը յուրաքանչյուր ներքին ցանցի և յուրաքանչյուր ապագա WAN փոփոխության համար։

NAT-ը չի ընտրում ելքը

Երթուղավորումն է ընտրում ելքի ինտերֆեյսը. ելքային NAT կանոնը միայն նկարագրում է, թե ինչպես է աղբյուրը վերագրվում փաթեթի դուրս գալուց հետո։ WAN-ի համար քարտեզագրումը չի ստիպում երթուղավորման կողմից այլուր ուղարկված փաթեթին անցնել WAN-ով, դրա համար էլ NAT ավելացնելը չի կարող ուղղել սխալ երթուղին։ Ստուգեք նաև կիրառելի 1:1 NAT գրառումները և բացառությունները, քանի որ հերթականությունը կարևոր է, և նոր տողը պարտադիր չէ, որ հաղթի։ Իսկ ելքային էջը ֆիլտրման էջը չէ։

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

Ապացուցեք ձևափոխությունը նոր միացման վրա

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

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