Synology-ում OpenVPN-ի ձեռքսեղմումը ձախողվո՞ւմ է. Ստուգեք LAN-ի փոխանցումը

Ձեր նոթբուքը հաղորդում է, որ TLS ձեռքսեղմումը ձախողվել է, ուստի գայթակղությունը վկայականները վերակառուցելն է։ Նախքան դա, տվեք ավելի ձանձրալի հարց՝ Synology-ն իրականում ո՞ր Ethernet պորտում է լսում։ Երկու LAN պորտով NAS-ն ունի երկու հասցե, և DSM-ի VPN Server փաթեթը իր OpenVPN լսիչը կապում է դրանցից մեկին։ Երբ երթուղիչը 1194-ը փոխանցում է մյուս հասցեին, ոչ մի փաթեթ երբեք չի հասնում ծառայությանը, և հաճախորդը բանակցելու ոչինչ չունի։

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

Գտեք այն հասցեն, որին կապված է լսիչը

DSM-ն իր պորտերը կոչում է LAN 1 և LAN 2, և յուրաքանչյուրը կրում է առանձին հասցե և ենթացանց։ Բացեք VPN Server-ը, կարդացեք OpenVPN ներդիրում նշված ինտերֆեյսը, ապա բացեք Կառավարման վահանակը և գրի առեք այն IPv4 հասցեն, որը DSM-ն ունի նույն ինտերֆեյսում։ Փոխանցումը պետք է անվանի հենց այդ երկու արժեքները, ոչ թե NAS-ի հոսթի անունը։

Երկրորդ միացված մալուխը երկրորդ լսիչ չի ստեղծում։ Երկու կապերն էլ կարող են միացված երևալ, մինչդեռ միայն մեկ հասցե է ընդունում երթևեկությունը, և երբ երկու ինտերֆեյսները նույն ենթացանցում են, երկու հասցեները տարբերվում են մեկ նիշով, որը ոչ ոք նորից չի կարդում կանոնը պահելուց առաջ։

Նայեք հենց սոքեթին SSH-ի միջով, որովհետև սա միակ տեղն է, որը ցույց է տալիս, թե ինչին է դեմոնը իրականում կապվել, այլ ոչ թե ինչ է նախատեսում կարգավորումների էջը։

sudo netstat -anp | grep 1194

Խմբագրեք գոյություն ունեցող փոխանցումը, փոխարենը նորը ավելացնելու

Մեկ արտաքին պորտի համար երկու կանոն երթուղիչին ազատություն է տալիս ընտրելու, և թե որն ընտրի, կարող է փոխվել որոնվածքի թարմացումից կամ վերագործարկումից հետո։ Բացեք արդեն գոյություն ունեցող կանոնը, փոխեք նրա ներքին հասցեն, պահեք, ապա նորից բացեք և կարդացեք արժեքը։ Կանոնը ծառայության անունով կոչելը օգնում է, որովհետև հինգ նույնական փոխանցումների ցանկն է այն ձևը, որով սխալը գոյատևում է։

external 1194/udp  ->  192.0.2.20:1194/udp

Ներքին պորտը հավասար պահեք լսելու պորտին, և արձանագրությունը պահեք հետևողական։ UDP 1194-ը լռելյայն լսիչն է, մինչդեռ TCP պրոֆիլին անհրաժեշտ է իր սեփական լսիչը փաթեթի կողմում և համապատասխան փոխանցում երթուղիչում։ TCP-ն այն ծառայությանը փոխանցելը, որը լսում է միայն UDP-ով, լռություն է տալիս, ոչ թե սխալ։

Եթե NAS-ի հասցեն գալիս է DHCP-ից, ամրագրեք այն նախքան կանոնը պահելը։ Վարձակալության ավարտը նորից նշանակում է հասցեն, փոխանցումը շարունակում է ցույց տալ հին արժեքին, և ձեռքսեղմումը սկսում է ձախողվել մի օր, երբ ոչ ոք չի դիպել NAS-ին։ NAS-ի կողմի ստատիկ կարգավորումը լուծում է նույն խնդիրը, պայմանով, որ հասցեն գտնվում է երթուղիչի DHCP տիրույթից դուրս։

Ապացուցեք՝ արդյոք փաթեթները ընդհանրապես հասնում են

Նախ սկսեք գրավում NAS-ում, ապա միացեք հաճախորդից և կարդացեք աղբյուրի հասցեն արտածման մեջ։ Ձախողումից հետո սկսված գրավումը ոչինչ չի ցույց տալիս և ոչինչ չի ապացուցում։

sudo tcpdump -i any -n udp port 1194

Լռությունը նշանակում է, որ երթևեկությունը մահացել է ծառայությունից առաջ՝ սխալ ներքին հասցե, փակ պորտ DSM-ի ֆայրվոլում, կամ ինտերֆեյս, որը վարչականորեն անջատված է։ Արտածման մեջ փաթեթները նշանակում են, որ փոխանցումը աշխատում է, և մնացած խափանումը գտնվում է ցանցային շերտից վեր, ինչը շատ ավելի փոքր որոնման տարածք է։

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

Երբ փաթեթները հասնում են, դադարեք մեղադրել փոխանցմանը

Պրոֆիլը հաջորդ կասկածյալն է, և սովորական պատճառը տարիքն է։ Արտահանված .ovpn ֆայլը պարունակում է իշխանությունը և նյութը արտահանման պահից, ուստի փաթեթը, որի վկայականը հետագայում փոխարինվել է, կմերժի հաճախորդին, որը դեռ կրում է հին պատճենը։

Փոխադրումը մյուս անհամապատասխանությունն է, որն արժե բացահայտ ստուգել, որովհետև պրոֆիլը և փաթեթը խմբագրվում են տարբեր տեղերում։ Պրոֆիլը UDP-ից TCP փոխելը առանց փաթեթը փոխարկելու թողնում է հաճախորդին սպասելու լսիչի, որը գոյություն չունի, և հաճախորդը հաղորդում է նույն ընդհանուր ձեռքսեղմման տեքստը, որը հաղորդում է մնացած ամեն ինչի համար։ Կարդացեք ֆայլի proto տողը, ապա նայեք սերվերի էջում ընտրված արձանագրությանը, և միայն դրանից հետո եզրակացրեք, որ դրանք համընկնում են։ DSM-ի ֆայրվոլի կանոնները կարդալը երրորդ ստուգումն է. այն կանոնը, որը թույլ է տալիս պորտը տեղական ենթացանցից, բայց ոչ ինտերնետից, հեշտ է թողնել փորձարկումից հետո, և այն տալիս է կապ, որն աշխատում է խոհանոցից և ձախողվում է բոլոր այլ տեղերից։

Փորձարկեք այն ուղին, որով հեռավոր օգտատերն իրականում անցնում է

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

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