Pi VPN մի քանի երթուղիչով. ամեն երթուղին դրեք այն սարքի վրա, որը որոշում է
Հոսանքից ներքև գտնվող երթուղիչը ավելացնում է երկրորդ հաճախորդական ենթացանց, և չորս սարքերից յուրաքանչյուրն ունի մեկ որոշում։ Տեղադրեք երթուղիները, ստուգեք աղբյուրը, ապա փորձարկեք իրական հաճախորդից։
Pi-ի հետևում Wi-Fi տուփ տեղադրելը մեկ երթուղավորման որոշումը դարձնում է չորս, և պլանը կոտրվում է, երբ բոլոր չորսը կայացվում են մեկ սարքում։ Առաջին հարցը չէ, թե որ երթուղին ավելացնել։ Հարցն այն է՝ նոր տուփը կամուրջ է կազմում, թե երթուղավորում է, որովհետև այդ պատասխանը որոշում է, թե քանի ենթացանց կա և որ սարքերը պետք է իմանան դրանց մասին։ Նախ ընտրեք միացման մոդելը. ամեն երթուղի բխում է դրանից։
Կամուրջ, թե երթուղավորում. ընտրություն, որը որոշում է քանակը
Կամուրջը նոր հաճախորդներին դնում է նույն ենթացանցում, որը Pi-ն արդեն սպասարկում է։ Մեկ ենթացանց, մեկ DHCP իշխանություն և ոչ մի փոխանցում երթուղավորման համար։ Սա ավելի պարզ դասավորությունն է և ճիշտը, երբ առանձին հաճախորդական ցանցը երբեք պահանջ չի եղել։ Երթուղավորված կապը այլ ձևավորում է. տուփը պահում է իր ենթացանցը, և այդ նախածանցը պետք է տարվի ամենուր, ուր գնում է երթևեկությունը։
Պլանի մնացած մասը պահում է ստորին երթուղիչը և պահպանում հաճախորդների աղբյուրի հասցեները։ Նպատակը մեկ մասնավոր VPN ցանց է, ոչ թե ամբողջական ինտերնետ ելք։ Գրեք մոդելը հասցեներից առաջ, որովհետև ներքևի ցանկը միայն երթուղավորված միացման օրինակ է։
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Ով ինչ է որոշում
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Ամեն սարք մեկ որոշում է կայացնում, և ոչ մեկը չի կարող ուրիշի որոշումը կայացնել նրա փոխարեն։ Pi-ին պետք է երկու գրառում, ոչ թե մեկ, և վերադարձի ուղին այն է, ինչ մարդիկ մոռանում են։ Փոխանցված երթևեկությունը ճիշտ հասնում է մասնավոր ցանց և հետո մահանում է վերադարձի ճանապարհին, որովհետև Pi-ն գաղափար չունի, թե որտեղ է ապրում 10.41.0.0/24-ը։ Դա նման է հրապատի խնդրի և իրականում բացակայող երթուղի է։
Հեռավոր կողմը նույնպես իր երթուղին է պետք։ Եթե հեռավոր ծայրի ծառայությունը չգիտի, որ 10.41.0.0/24-ը հասանելի է ձեր թունելով, պատասխանները կանգ են առնում առաջին ցատկում, որը պատասխան չունի։ Ավելացրեք երկու ուղղությունները նախքան փաթեթների զտիչները կարդալը։
Հաջորդ ցատկերը գալիս են միացումից
Հաջորդ ցատկը պետք է լինի հասցե ցանցում, որին սարքը իրոք կարող է հասնել։ VPN գործընկերոջ հանրային հասցեն հաջորդ ցատկը չէ մասնավոր ենթացանցի համար, և հեռավոր ծառայության ցանցը ամենևին հաջորդ ցատկ չէ։ Անհասանելի դարպասին տանող երթուղին ցանկում ճիշտ է երևում և գցում է ամեն փաթեթ։ Ստուգեք, որ դարպասը պատասխանում է, նախքան նպատակակետին մեղադրելը։
Պահեք Pi-ի արտաքին VPN գործընկերոջը հասանելի իր իսկ ստորին երթուղով։ Այդ գրառումը առանձին է բեռնվածքի երթուղիներից, և դրանց խառնումը տալիս է թունել, որը չի կարող վերականգնվել ուղու փոփոխությունից հետո։
Ստատիկ երթուղիների փաստաթղթերը պարզ են դարձնում նպատակակետի և դարպասի տարբերությունը, թեև ամեն հարթակ իր ընտրացանկերը տարբեր կերպ է անվանում։ Կարդացեք ձեր առջևի սարքի փաստաթղթերը՝ փոխարենը ուրիշ արտադրողի էկրանը պատճենելու։ Ներքևի հրամանները ցույց են տալիս գրառումների ձևը Linux-ում։
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Ինչ է անում թարգմանությունը աղբյուրի հետ
Եթե ստորին երթուղիչն արդեն թարգմանում է իր հաճախորդներին տրանզիտային հասցեի, Pi-ն տեսնում է մեկ թարգմանված աղբյուր ամեն հաճախորդի սեփական հասցեի փոխարեն։ Սա այլ ձևավորում է, քան վերևի աղբյուրը պահպանողը։ Այն փոխում է աղբյուրի վրա հիմնված քաղաքականությունը, գրանցումը և այն, թե որ կողմը կարող է սկսել միացումներ։ Երկու ձևավորումներն էլ աշխատում են. դրանք պատասխանում են տարբեր հարցերի։
Երբ վերին VPN ծառայությունը հրաժարվում է հաճախորդի նախածանցը հետ երթուղավորել, Pi-ի թունելի ելքի մոտ նեղ թարգմանությունը կարող է օրինական ժամանակավոր լուծում լինել։ Սա ապացույց չէ, որ բացակայող երթուղին ավելորդ էր։ Գրանցեք, թե հեռավոր ցանցն իրականում որ հասցեն է տեսնում և ինչ վերադարձի ուղի է ստացվում։
Երթուղու ընտրությունը, փոխանցման թույլտվությունը և աղբյուրի թարգմանությունը մնում են երեք առանձին աշխատանք։ Ընդհանուր NAT շղթան դատարկելը կամ ամեն ինտերֆեյսին թույլտվություն տալը, որովհետև մեկ լարային հաճախորդ աշխատում է, այն ձևն է, որով աշխատող թեստը դառնում է բաց փոխանցիչ։
Ապացուցեք դա հաճախորդական մեքենայից
Ուղարկեք հարցում ստորին LAN-ի մեքենայից, ապա հետևեք նրա աղբյուրին դուրս և հետ։ Pi-ի ուղարկած ping-ը երբեք չի վարժեցնում ստորին վերադարձի երթուղին, դրա համար հաջող ping-ը ցույց է տալիս ավելի քիչ, քան թվում է։ Ավելացրեք երկրորդ թեստ լարային հաճախորդից Pi-ի սեփական LAN-ում, որպեսզի երկու ուղիները կարողանան համեմատվել։ Կրկնեք երկուսն էլ սարքերից որևէ մեկը վերագործարկելուց հետո։
Ձեռքով ավելացված երթուղիները և երբեք չպահված թարգմանությունները միասին անհետանում են։ Այն ժամանակ զույգը նոր խափանում է թվում, ոչ թե անավարտ աշխատանք։
Պահեք միացման մոդելը երթուղիների, թույլատրված մասնավոր ծառայության և ցանկացած թարգմանության հետ մեկ գրառման մեջ։ Այդ գրառումն է, որ խանգարում է հաջորդ մարդուն անլար տեղադրությունը երթուղային քաղաքականության հարց համարել։