Հոսանքն ի վար կլիենտներ՝ վերևի VPN-ի հետևում․ երթուղի՞, թե՞ NAT

Մեկ դարպաս աշխատեցնում է WireGuard ձեր սեփական սարքերի համար և OpenVPN կլիենտ՝ ուրիշի ցանցի ուղղությամբ։ Փոխանցումը երկու ներքին ինտերֆեյսների միջև աշխատում է, և հեշտ է եզրակացնել, որ ներքևի ենթացանցն այժմ վերևի ծառայության մասն է։ Այդպես չէ։ Կլիենտի քաշած երթուղին ասում է ձեր դարպասին, թե ուր ուղարկել հարցումները․ այն ոչինչ չի ասում այն մասին, թե ինչպես է հեռավոր ցանցը երթևեկությունը վերադարձնում այն սարքերին, որոնց մասին երբեք չի լսել։ Ընտրեք վերադարձի այնպիսի մոդել, որն իսկապես աջակցում է վերևը, նախքան որևէ կանոն ավելացնելը։

Որոշեք վերադարձի մոդելը, նախքան երթուղմանը դիպչելը

Այս քայլերում ներքևի կլիենտներն օգտագործում են 10.90.0.0/24 ցանցը, դարպասին հատկացված վերևի թունելի հասցեն 10.80.0.6 է, իսկ հաստատված հեռավոր ռեսուրսը՝ 172.20.0.30։ Այս ձևին համապատասխանում են երկու մոդել․ պահել ներքևի աղբյուրը և ստիպել հեռավոր կողմին երթուղավորել այն, կամ թարգմանել աղբյուրը դարպասի սեփական թունելի հասցեին։ Այս որոշումից հետո ամեն ինչ մեխանիկական է, և որոշումն ինքնին պահանջում է ծառայության սեփականատիրոջը։ Վերևի տողերից մեկը երթուղային պայմանավորվածություն է հեռավոր կողմի հետ․ մյուսը տեղական քաղաքականության փոփոխություն է, որը կարող եք անել ինքներդ։ Հենց այս երկուսի շփոթումն է տասը րոպեի փոփոխությունը վերածում բանակցության։

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Ընտրեք մեկ տող և հաստատ մնացեք դրա վրա։ Տողերը այլընտրանքներ են, ոչ քայլեր, և դրանք խառնելը ստեղծում է նախագիծ, որը վերանայման ժամանակ ոչ ոք չի կարող բացատրել։

Երթուղավորված աղբյուրի պահպանում

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

Եթե պատասխանը այո է, տեղական կոնֆիգուրացիան փոքր է՝ փոխանցումը միացված, ներքևի տիրույթը ծածկող WireGuard peer-ի allowed-ips-երը, և հրային պատի քաղաքականություն, որը թույլ է տալիս անցումը երկու ուղղությամբ։

Դիտավոր աղբյուրի թարգմանություն

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

IPv6-ը պահանջում է իր սեփական նախագիծը․ IPv4-ի masquerade տողը պատճենելը ճարտարապետություն չէ։ Ստուգեք թարգմանված ուղին նոր կապով, ոչ թե քեշավորվածով։

Տեղական տվյալների ուղին դեռ պետք է աշխատի

Թարգմանությունը չի վերացնում տեղական աշխատանքը․ դարպասին դեռ պետք են երթուղի ներքևի նպատակակետերի համար, WireGuard peer-ի աղբյուրի ճիշտ սեփականություն, միացված փոխանցում և նեղ հրային պատի քաղաքականություն ինտերֆեյսների միջև։ Հենց դարպասի վրա ստեղծված հարցումը չի վարժեցնում այդ թույլտվություններից ոչ մեկը, դրա համար էլ դարպասի տեղական թեստերը անցնում են, իսկ ներքևի սարքերը դեռ ձախողվում են։

Ստուգեք իրական ներքևի սարքից, ոչ թե դարպասից։ Աղբյուրի հասցեն է այս վարժության ամբողջ իմաստը։

Մեկ աղբյուր նշանակում է մեկ սեսիայի ինքնություն

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

Գրեք այդ հաստատումը runbook-ում կանոնի կողքին, որովհետև հաջորդ վերանայողը կհարցնի՝ նախագիծը հաստատվա՞ծ էր, թե՞ պարզապես հարմար։

Սահմանեք անջատված վիճակը, ապա ստուգեք երեք հարցում

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

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