VPN դարպաս Raspberry Pi-ում՝ մեկ ցանցային քարտ կամ առանձին հաճախորդի պորտ
Pi-ի մեկ պորտը կարող է սպասարկել ընտրված հաճախորդների, կամ երկրորդ պորտը կարող է փակել սարքերը ներսում։ Ընտրեք սխեման ըստ մեկուսացման, հետադարձ քաղաքականության և այն բանի, թե ումն է DNS-ը։
Դուք ունեք մեկ Pi, մեկ աշխատող ելքային VPN պրոֆիլ և երկու սարք, որոնք պետք է ինտերնետ հասնեն դրա միջով։ Հարցը, որը որոշում է ամբողջ կառուցումը, այն չէ, թե որ ուղեցույցին հետևել, այլ այն, թե որքան մեկուսացում է ձեզ պետք։ Մեկ պորտը թույլ է տալիս, որ Pi-ն կանգնի այդ սարքերի կողքին երթուղղիչի LAN-ում և հանդես գա որպես լրացուցիչ դարպաս. երկրորդ պորտը թույլ է տալիս տեղադրել նրանց այն հատվածում, որտեղ Pi-ն միակ ելքն է։ Այդ ընտրությունից հետո ամեն ինչ՝ DHCP, firewall-ի ծավալը, DNS-ը, խափանման դեպքը, բխում է դրանից։
Ինչով են իրականում տարբերվում երկու սխեմաները
Երկու նախագծերն էլ երթուղավորում են։ Տարբերությունը այն է, թե ով էլ է կանգնած լարին և ինչ է լինում, երբ ձեր քաղաքականությունը սխալ է։
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Իսկական առանցքը մեկուսացումն է։ A սխեման խորհրդատվական է. սարքը, որը անտեսում է DHCP-ով տրված դարպասը և ընտրում է երթուղղիչը, դեռ աշխատում է, բայց առանց գաղտնագրման։ B սխեման պարտադրվում է տոպոլոգիայով, որովհետև ընտրելու այլ հաջորդ քայլ չկա։
A սխեմա. Pi-ն որպես լրացուցիչ դարպաս գոյություն ունեցող LAN-ում
Ենթադրենք ISP-ի երթուղղիչը 192.168.50.1 է, Pi-ն՝ 192.168.50.2, և ընտրված հաճախորդները ցույց են տալիս դեպի Pi։ Կարևորը այն է, որ երկու տարբեր փաթեթային հոսքեր կիսում են մեկ լարը։ Հաճախորդի ներքին փաթեթը հասնում է Pi-ին և պետք է դուրս գա թունելով. Pi-ի սեփական գաղտնագրված փաթեթը դեպի VPN զուգընկերը պետք է դուրս գա նույն լարով դեպի երթուղղիչը։ Նրանք շարժվում են հակառակ ուղղություններով նույն ինտերֆեյսով և տարբեր վերաբերմունքի կարիք ունեն։
Pi-ին տվեք իր հասցեն տեղադրված ցանցային կառավարչի միջոցով, ոչ թե հին ինտերֆեյսի ֆայլի բաղադրատոմսով, որը պայքարում է դրա հետ սարքի համար։ Ապա կարգավորեք հաճախորդներին՝ ստատիկ դարպաս մեկ սարքում, կամ DHCP ամրագրում, որը տալիս է 192.168.50.2-ը որպես երթուղղիչ։ Մի փոխեք երթուղղիչի ամբողջ DHCP տիրույթը երկու սարքի պատճառով, և մի ենթադրեք, որ հաճախորդը հարգում է այդ ընտրանքը՝ ստուգեք այն։
Թուլությունը կառուցվածքային է, ոչ վերականգնելի։ Այդ հատվածի ցանկացած հաճախորդ կարող է ցույց տալ 192.168.50.1-ին և դուրս գալ բաց տեքստով, իսկ երկրորդ ինտերֆեյսով կամ բջջային ռադիոյով սարքը լիովին լքում է ձեր պարտադրման ուղին։ Եթե այդ նախադասությունն անընդունելի է տվյալ սարքի համար, պատասխանն արդեն ունեք՝ օգտագործեք B սխեման։
B սխեմա. առանձին պորտը փակում է սարքերը ներսում
Այստեղ Pi-ն պահում է 192.168.50.2-ը վերին կապում 192.168.50.1 դարպասով, և երկրորդ ինտերֆեյսում վերցնում է 10.20.0.1/24 միացված սարքերի համար։ Այժմ Pi-ն երկու ցանցով երթուղղիչ է, և միացված հատվածն ունի ուղիղ մեկ ելք։
Ստուգեք տիրույթը մնացած ամեն ինչի դեմ նախքան պարտավորվելը՝ թունելի սեփական ենթացանցը, միջվայրային այլ նախածանցներ և այն ամենը, ինչ հասանելի է VPN-ով։ 10.20.0.0/24-ը, որը բախվում է հեռավոր LAN-ի հետ, տալիս է այն կիսագործող արդյունքը, որի ախտորոշումը տևում է մի ամբողջ երեկո։ Եթե երկրորդ պորտը USB ադապտեր է, հաստատեք, որ այն աջակցվում է, և ամրացրեք նրա անունը ցանցային կառավարչում, որպեսզի վերագործարկումից հետո վերադասավորումը չտեղափոխի ձեր LAN հասցեն։
Գործարկեք DHCP լսողը միայն այդ ինտերֆեյսում։ Վերին կապում պատասխանող սերվերը մրցում է ISP-ի երթուղղիչի հետ և ձեր հատվածի հասցեները տալիս է տան մնացած մասին։ Կապեք այն LAN ինտերֆեյսին, սահմանափակեք հայտարարված տիրույթով, և պահեք Pi-ի սեփական հասցեն լողավազանից դուրս։
Փոխանցում, թարգմանություն և խափանման դեպքում փակման կանոն
Չորս բան հաճախ նկարագրվում է որպես մեկ, և այդպես չէ։ Փոխանցումը միացնելը (net.ipv4.ip_forward=1) միայն ասում է միջուկին, որ այն կարող է փաթեթներ տեղափոխել ինտերֆեյսների միջև. ինքնին այն ոչինչ չի թույլատրում և ոչ մի ուղի չի երաշխավորում։ Ելքն ընտրելը երթուղավորման որոշում է։ Փաթեթը թույլատրելը forward շղթայում քաղաքականության որոշում է։ Դրա աղբյուրը վերաշարադրելը postrouting որոշում է։ Կառուցումը, որն անում է միայն առաջինը, տալիս է Pi, որը ուրախությամբ փոխանցում է հաճախորդի տրաֆիկը դուրս վերին կապով։
Սահմանափակեք թույլտվությունը նախատեսված աղբյուրներով և այն ինտերֆեյսով, որը տրաֆիկը պետք է օգտագործի, և ներառեք վերադարձի ուղին ու Pi-ի սեփական անհրաժեշտ նպատակակետերը։ Ապա թարգմանեք թունելի ելքում, եթե մատակարարը ձեր LAN նախածանցը հետ չի երթուղավորում դեպի ձեզ։ nftables-ի ձեռնարկը փոխանցումը, տեղական ելքը և աղբյուրի թարգմանությունը դիտարկում է որպես առանձին գործողություններ, ինչը այստեղ ճիշտ մտածողության մոդելն է։
Սովորական խափանումը լայն masquerade կանոնն է ֆիզիկական ինտերֆեյսում։ Այն ժամանակ տրաֆիկը հասնում է ինտերնետ ISP-ի ուղով, մինչդեռ հաճախորդի կողմից այն կարծես ճիշտ աշխատող VPN լինի։ Դա ոչինչ չի ապացուցում։ Պահեք թարգմանությունը կապված հայտարարված ելքի հետ, և պահեք ձեր կանոնները այն firewall-ում, որն օգտագործում է հենց հոսթը, փոխարենը ավելացնելու մրցակից կանոնների հավաքածու, որը դատարկում է ընդհանուր postrouting շղթան։
Ապա զբաղվեք թունելի բացակայությամբ։ Լայն լռելյայն ուղի տեղադրող հաճախորդի պրոֆիլը նաև նշանակում է, որ երբ թունելն ընկնում է, սովորական լռելյայնը կարող է վերադառնալ, և հաճախորդի տրաֆիկը լուռ վերադառնում է վերին կապ։ Այնտեղ, որտեղ բաց տեքստին հետադարձն անընդունելի է, forward քաղաքականությունը պետք է բացահայտորեն մերժի հաճախորդից վերին կապ տրաֆիկը, այն վիճակում, երբ VPN ուղին անհետացել է։ Գրեք դա որպես մերժման կանոն, ոչ որպես ենթադրություն։ Pi-ի սեփական գաղտնագրված տեղափոխումը դեպի VPN զուգընկեր առանձին local-output հոսք է և պետք է մնա թույլատրված, հակառակ դեպքում թունելը երբեք չի կարող վերադառնալ։
DNS-ը և IPv6-ը իրենց պատասխանի կարիքն ունեն
Եթե հաճախորդները Pi-ն օգտագործում են որպես լուծիչ, նրանք հանդիպում են տեղական լսողի, և Pi-ն սկսում է նոր հարցում։ Այդ վերին հարցումը հետևում է Pi-ի սեփական ուղուն, ոչ այն forward կանոնին, որը դուք գրել եք հաճախորդների համար, ուստի միայն թունելով գնացող հաճախորդի ուղին գումարած ուղղակիորեն դուրս եկող լուծիչը առանց որևէ սխալի հաղորդագրության արտահոսք է։ Որոշեք գիտակցաբար՝ թունելով հասանելի լուծիչ, թե տեղական, որը դուք ընդունում եք որպես ուղղակի, և համապատասխանեցրեք Pi-ի սեփական ելքային քաղաքականությունը այդ որոշմանը։
IPv6-ը կրկին առանձին դեպք է։ IPv4-ի forward կանոնը ոչինչ չի սահմանափակում IPv6-ի առումով, և վերին կապում երթուղղիչի հայտարարությունները կարող են Pi-ին, և դրա միջով միացված հատվածին, տալ երկրորդ լռելյայնը, որը շրջանցում է ձեր քաղաքականությունը։ Կամ նույն սկզբունքով IPv6-ին տվեք իր սեփական պաշտպանված ուղին, կամ բացահայտորեն սահմանափակեք այն հաճախորդի հատվածում և ասեք դա։
Փորձարկեք սահմանը նախքան վստահելը
Ընդունեք նախագիծը միայն չորս առանձին ստուգումներից հետո, որովհետև գայթակղիչ միակ փորձարկումը՝ բրաուզեր բացել մեկ հաճախորդում, անցնում է մի քանի կոտրված վիճակներում։
Հաստատեք, որ մեկ իրական հաճախորդ ինտերնետ հասնում է թունելով, ապա հաստատեք, որ նույն հաճախորդը չի կարող ինտերնետ հասնել թունելն անջատված լինելու դեպքում։ Հաստատեք, որ DNS լուծումը աշխատում է, և հարցումը դուրս է գալիս այնտեղից, որտեղ դուք նախատեսել եք։ Հաստատեք, որ Pi-ի սեփական տեղափոխումը դեռ աշխատում է թունելի վերագործարկումից հետո, և վերականգնումը մեքենայի վերագործարկում չի պահանջում։ Վերջում ստուգեք մի սարք, որը չեք ընտրել՝ A սխեմայում այն պետք է շարունակի նորմալ աշխատել, իսկ B սխեմայում այն ընդհանրապես չպետք է գոյություն ունենա այդ հատվածում։
- Երկու պորտ և մերժման կանոն տալիս են պարտադրում. մեկ պորտ և DHCP ընտրանք տալիս են խորհուրդ։
- Սխալ ինտերֆեյսում թարգմանությունը ստացվում է հաջողության տեսքով և այդպիսին չէ։
- Pi-ի սեփական տրաֆիկը, DNS-ը և IPv6-ը յուրաքանչյուրը որոշում է պահանջում, ոչ եզրակացություն։