Երթուղավորեք մասնավոր LAN-երի միջև՝ նախքան ևս մեկ NAT ավելացնելը
Համընկնող հասցեատարածությունը, բացակայող վերադարձի ուղին կամ անվստահելի տրանզիտը որոշում են ընտրությունը երթուղավորման, NAT-ի և թունելի միջև։ Ստուգեք այդ երեքը՝ նախքան firewall-ը խմբագրելը։
Երկու ներքին firewall, մեկ մասնավոր տրանզիտ հատված և խնդրանք՝ թույլ տալ մի քանի հոսթերի յուրաքանչյուր LAN-ում խոսել մյուսի հետ։ Սովորական արձագանքը VPN կանգնեցնելը կամ երկրորդ NAT շերտ ավելացնելն է, և երկու արձագանքներն էլ արժեն ավելի, քան խնդիրը արժանի է։ Սովորական երթուղավորումը բավարար է, երբ բավարարվում են երեք պայման՝ հասցեների միջակայքերը չեն համընկնում, երկու կողմերն էլ կարող են երթևեկությունը վերադարձնել մյուս LAN, և տրանզիտ հատվածն արդեն բավական վստահելի է տվյալների համար։ Ստուգեք այդ երեքը՝ նախքան որևէ բան նախագծելը, որովհետև դրանցից յուրաքանչյուրը փոխում է պատասխանը։
Երեք պայման, որոնք որոշում են նախագիծը
Առաջին պայմանը հասցեատարածությունն է։ Եթե երկու LAN-երն էլ օգտագործում են նույն RFC 1918 բլոկը, երթուղավորումը չի կարող դրանք տարբերել, և թարգմանությունը դառնում է անխուսափելի՝ ոչ թե ընտրովի։ Երկրորդը վերադարձի ուղին է՝ A-ից B ուղին անօգուտ է, եթե B-ն էլ չգիտի, թե ինչպես հասնել A-ի LAN-ին, և ասիմետրիկ գիտելիքն ամենատարածված պատճառն է, որ երթուղավորված նախագիծը լուռ գցում է պատասխանները։
Երրորդը վստահությունն է։ Երթուղավորումը տեղափոխում է փաթեթներ, այն չի պաշտպանում դրանք։ Մեկ շենքի ներսում մասնավոր տրանզիտ հատվածը այլ բան է, քան մատակարարին հանձնումը կամ ընդհանուր կամպուսային ողնաշարը հատող կապը։ Եթե հատվածը վստահելի չէ, պատասխանը երկու firewall-ների միջև թունելն է, և ներքևի երթուղավորման պլանը դեռ գործում է դրա ներսում։
Պարզ նախագիծը հաղթում է միայն այն ժամանակ, երբ բոլոր երեքը նույն ուղղությամբ են ցույց տալիս։ Երբ դրանցից մեկը ձախողվում է, ուղղեք հենց այդ պայմանը բացահայտորեն՝ թարգմանությամբ այն քողարկելու փոխարեն, որովհետև NAT-ը թաքցնում է խափանումը՝ փոխանակ լուծելու այն։
Կառուցեք երթուղու պլանը տրանզիտ ցանցի վրա
Տվեք յուրաքանչյուր firewall-ին հասցե ընդհանուր հատվածում և ավելացրեք մեկ կոնկրետ երթուղի յուրաքանչյուր հեռավոր LAN-ի համար։ Գոյություն ունեցող կարգավորումում ուրիշ ոչինչ պետք չէ տեղափոխել, և հատկապես ինտերնետի լռելյայն երթուղին պետք է մնա ճիշտ այնտեղ, որտեղ կա։ Լռելյայն երթուղին գործընկեր firewall-ով փոխարինելը կուղարկեր յուրաքանչյուր անկապ նպատակակետ տրանզիտով, ինչը շատ ավելի մեծ փոփոխություն է, քան պահանջվածը։ pfSense-ի ստատիկ երթուղավորման փաստաթղթերը նկարագրում են նույն երթուղի-գումարած-դարպաս մոդելը այդ հարթակի համար, և համարժեք կառավարումը գոյություն ունի ցանկացած firewall-ում, որն իրականում օգտագործում եք։
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
Firewall A-ն սպասարկում է 10.30.0.0/24 ցանցը, իսկ firewall B-ն՝ 10.40.0.0/24-ը, երկու տրանզիտ հասցեները գտնվում են 192.0.2.0/24-ում։ Յուրաքանչյուր LAN հոսթ պահում է իր տեղական firewall-ը որպես դարպաս, ուստի միակ նոր վիճակը յուրաքանչյուր կողմում մեկ երթուղին է։ Linux-ի վրա հիմնված firewall-ում նույն պլանը այսպիսի տեսք ունի, և փոխանցումը պետք է միացված լինի, այլապես երթուղին կլուծվի, մինչ փաթեթը կգցվի։
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
Զտումը առանձին պահեք թարգմանությունից
Երթուղավորումը և քաղաքականությունը տարբեր կառավարիչներ են, և հենց երկրորդում են իրականում ձախողվում երթուղավորված նախագծերի մեծ մասը։ Թույլատրեք կոնկրետ աղբյուրները, նպատակակետերն ու ծառայությունները մուտքի սահմանին, որն իրականում հատում են փաթեթները, և հիշեք, որ WAN-ի նման միջերեսի պիտակը անուն է, ոչ թե վստահության մասին հայտարարություն։ Մասնավոր երթևեկություն կրող տրանզիտ պորտը կարող է դեռ լռելյայն միացված ունենալ մասնավոր հասցեների արգելափակումը։
Ապա նայեք ելքային թարգմանությանը՝ նախքան եզրակացնելը, որ NAT տեղի չի ունենում։ Ավտոմատ ելքային կանոնները կարող են վերագրել երթևեկություն, որն երբեք թարգմանության համար չի նախատեսվել, և դա ոչնչացնում է աղբյուրի հասցեները, որոնք մյուս կողմին պետք են իր սեփական քաղաքականության և մատյանների համար։ Հաստատեք, որ ընտրված հոսքերը պահպանում են իրենց սկզբնական հասցեները, և ձեռք չտաք ինտերնետի թարգմանության կանոններին այն երթևեկության համար, որին դեռ պետք են դրանք։
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
Երբ NAT-ը ազնիվ պատասխանն է
Թարգմանությունն արժանանում է իր տեղին, երբ հասցեների միջակայքերը իսկապես համընկնում են և վերահամարակալումը հասանելի չէ, կամ երբ քաղաքականությունը պահանջում է, որ մի կողմը տեսնի մեկ հասցե՝ ենթացանցի փոխարեն։ Նման դեպքերում դիտավորյալ մեկ-ընդ-մեկ կամ պորտով սահմանափակված քարտեզագրումը հայտնի հետևանքներով նախագծային որոշում է, ոչ թե շրջանցում։
Հետևանքը, որը պետք է բարձրաձայն ասել, այն է, որ մյուս կողմն այլևս չի կարող տեսնել կամ զտել առանձին աղբյուրները։ Մատյանները թափվում են թարգմանող հասցեի վրա, հոսթով պայմանավորված քաղաքականությունը դադարում է աշխատել, և խնդիրների լուծումը վերածվում է որսի, թե որ ներքին հոսթն էր տիրում հոսքին տվյալ պահին։ Եթե այդ ամենը նշանակություն չունի տվյալ երթևեկության համար, NAT-ը լավ է։
Երբ տրանզիտն ինքն է սխալ ենթադրությունը
Եթե ընդհանուր հատվածն անցնում է մատակարարի, ընդհանուր կոմուտացիոն գործվածքի կամ ցանկացած ուղու միջով, որտեղ մեկ այլ կողմ կարող էր կարդալ երթևեկությունը, միայն երթուղավորումը ամբողջական պատասխան չէ։ Երկու firewall-ների միջև թունելը ձեզ տալիս է գաղտնիություն և գործընկերոջ նույնականացում, և դրա ներսում գտնվող երթուղիների աղյուսակը նույն աղյուսակն է, որը դուք կգրեիք տրանզիտի վրա։
Որոշեք դա առաջին բաժնի վստահության հարցից, ոչ թե սովորությունից, թե VPN-ները ավելի ապահով են։ Արդեն մասնավոր հատվածի վրա թունելը ավելացնում է գործառնական ծախս և ևս մեկ խափանման եղանակ՝ առանց օգուտի, մինչդեռ անվստահելի հատվածի վրա երթուղավորումը գաղտնիությունը փոխանակում է պարզության հետ, որը դուք չեք կարող թույլ տալ։ Գրեք, թե երեք պայմաններից որն է առաջնորդել ընտրությունը, և հաջորդ ինժեներին պետք չի լինի նորից քննարկել այն։