PiVPN-ի ձեռքսեղմումը աշխատում է, էջերը կանգ են առնում՝ ստուգեք MASQUERADE-ը

Ձեր հեռախոսը թունելը ցույց է տալիս որպես միացված, հաճախորդը հաղորդում է մասնավոր հասցե, իսկ առաջին էջը դեռ կախված է բեռնման կեսին։ Այդ համակցությունը մարդկանց մեծ մասին ուղարկում է գաղտնագրման կարգավորումներ և պրոցեսորի ջերմաստիճան, որտեղ իրականում ոչինչ սխալ չէ։ Թունելը բարձրացավ, այսինքն բանակցությունն ավարտվեց, և ձախողվեց հաջորդ քայլը, երբ սերվերը փորձում է հաճախորդի փաթեթները հանձնել ինտերնետին։ Անցեք նույն ճանապարհով, որով գնում են այդ փաթեթները, և անհամապատասխանությունը սովորաբար երևում է NAT աղյուսակի մեկ տողում։

Սկսեք նրանից, ինչին հաճախորդը կարող է հասնել և ինչին ոչ

Միացված հաճախորդից բեռնեք մի էջ, որը գտնվում է հանրային ինտերնետում, և նշեք՝ այն անմիջապես ձախողվում է, թե կանգ է առնում կեսին։ Ապա բացեք որևէ ռեսուրս VPN սերվերի սեփական մասնավոր հասցեով և համեմատեք երկու արդյունքը։

Թունելի այն հասցեն, որը պատասխանում է ping-ին, մինչ հանրային կայքերը ժամանակավարտվում են, վերափոխման կամ թարգմանության խնդրի նշան է, ոչ թե կոտրված ձեռքսեղմման։ Հաճախորդի սեփական կարգավիճակի վահանակը չի կարող տարբերել դրանք, որովհետև այն գիտի միայն, որ կառավարման ուղին բարձրացված է։ Սերվերի վրա ստուգեք թունելի ինտերֆեյսը այս հրամանով՝ ip -br addr show tun0 և հաստատեք, որ հաճախորդին տրված հասցեն ընկնում է ձեր կարգավորած լողավազանի մեջ։ Եթե լողավազանը և հաճախորդի հասցեն չեն համընկնում, սկզբում ուղղեք դա, քանի որ ներքևի յուրաքանչյուր կանոն համապատասխանում է լողավազանին։

Ապա հարցրեք սերվերին, թե որ ինտերֆեյսով նա կհասնի հանրային հասցեի։ ip route get 203.0.113.9 իր առաջին տողում տպում է ընտրված սարքը և աղբյուրը։ Գրեք այդ սարքի անունը, որովհետև հենց այդ արժեքը պետք է պարունակի NAT կանոնը։

Կարդացեք այն կանոնը, որը որոշում է՝ փաթեթները դուրս գա՞ն, թե ոչ

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

Թվարկեք կենդանի աղյուսակը և կարդացեք ելքային ինտերֆեյսի սյունը՝ փոխանակ պարզապես փնտրեք MASQUERADE բառը։ Ավելացման ձևի ելքը ավելի հեշտ է համեմատել, քան ձևավորված ցանկը՝

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Raspberry Pi-ի վրա, որը ժամանակին օգտագործել է Ethernet, իսկ այժմ՝ Wi-Fi, հնացած անունը գրեթե միշտ ամբողջ պատմությունն է։ Տեղադրիչը գրանցել է, թե որ սարքն էր ներկա տեղադրման պահին, և պահված կանոնների հավաքածուն այն վերարտադրում է ամեն բեռնարկման ժամանակ։ Նախքան որևէ այլ բան փոխելը համեմատեք երթուղու որոնումից ստացված սարքը կանոնում եղածի հետ։ Եթե դրանք համընկնում են, ինտերֆեյսը ձեր խնդիրը չէ, և դուք պետք է անցնեք վերջին բաժնի հաշվիչներին։ Եթե տարբերվում են, ուղղումը մեկ բառի խմբագրում է կայունության ֆայլում։

Ուղղեք պահված կանոնների հավաքածուն, ոչ միայն աշխատողը

Միայն կենդանի աղյուսակը խմբագրելը պահպանվում է մինչև հաջորդ վերագործարկումը, ինչը հենց այնքան երկար է, որքան պետք է ձեզ համոզելու, որ խնդիրը լուծված է։ Բեռնարկման ժամանակ վերադարձող կանոնները ապրում են մի ֆայլում, որը վերաբեռնում է հրապարակի կայունության փաթեթը։ Debian-ի վրա հիմնված Pi պատկերներում այդ ֆայլը սովորաբար /etc/iptables/rules.v4։

Մինչ դրան դիպչելը պատճեն վերցրեք, ապա MASQUERADE տողի ելքային ինտերֆեյսը փոխարինեք ձեր գրած սարքով, օրինակ՝ -o wlan0 փոխարեն -o eth0։ Թողեք աղբյուրի միջակայքը ինչպես կա, եթե ձեր հաճախորդների լողավազանը չի փոխվել։ Վերաբեռնեք և հաստատեք, որ կանոնն այժմ նշում է ճիշտ սարքը՝

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Երկու հարակից կարգավորում հեշտ է մոռանալ։ sysctl net.ipv4.ip_forward պետք է հաղորդի 1, և վերին երթուղիչը չպետք է ինքը զտի մասնավոր աղբյուրի հասցեները։

Ապացուցեք, որ կանոնը գործարկվում է, ապա մեկուսացրեք, թե ինչն է դեռ դանդաղ

Հաշվիչները միակ ազնիվ ապացույցն են, որ կանոնը համընկել է։ Գործարկեք մանրամասն ցանկը, սկսեք ներբեռնում հաճախորդի վրա և նորից գործարկեք։ Ձեր կանոնի կողքի փաթեթների և բայթերի սյուները պետք է աճեն, և զրոյի վրա մնացող կանոնը դեռ չի համընկնում։ Եթե հաշվիչները շարժվում են, բայց էջերը դեռ ձախողվում են, համեմատեք աղբյուրի միջակայքը փաստացի լողավազանի հետ այս հրամանով՝ grep -n "^server " /etc/openvpn/server.conf։ Եթե դրանք շարժվում են և էջերը բեռնվում են, բայց թողունակությունը վատ է, թարգմանությունն ավարտված է, և մնացած խնդիրը այլ տեղ է։

Համեմատեք նույն հաճախորդից երկու փոխանցում՝ մեկը տեղական ցանցի հոսթին, մյուսը թունելով նույն հոսթին։ Երկու դեպքում էլ դանդաղ լինելը մատնանշում է Pi-ի վերին կապուղին կամ Wi-Fi կապը, ոչ թե VPN-ը։ Միայն թունելով դանդաղ լինելը մատնանշում է MTU-ն և կրկնակի ուղարկումները, որոնք կարող եք զննել այս հրամանով՝ ip -s link show tun0 նախքան որևէ գաղտնագրման կարգավորում փոխելը։

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