DD-WRT-ում OpenVPN 2.5-ի լսողը մեռե՞լ է. կարդացեք այն ստեղծած կոնֆիգը

DD-WRT-ում մեռած լսողը սովորաբար նշանակում է, որ դեմոնը դուրս է եկել իր կոնֆիգը վերլուծելիս, ոչ թե որ firewall-ի կանոնն արգելափակել է պորտը։ OpenVPN 2.5-ը խստացրեց մի քանի լռելյայն արժեքներ, որոնց վրա հենվում էին հին կոնֆիգները, և հին կառուցվածքում աշխատած ստեղծված կոնֆիգը կարող է մերժվել նախքան socket-ի բացվելը։ Պատճառը երթուղիչի սեփական մատյանում է, իսկ մուտքը՝ ստեղծված ֆայլում։ Երկուսն այդ հերթականությամբ կարդալն ավելի արագ է, քան ցանկացած փաթեթի որսում։

Դեմոնը firewall-ը չէ

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

Առանձնացրեք դրանք երկու ստուգմամբ՝ նախքան որևէ բան փոխելը, որովհետև մեռած դեմոնի վրա firewall-ի խմբագրումը միայն երկրորդ փոփոխական է ավելացնում։

Կարդացեք DD-WRT-ի ստեղծած կոնֆիգը

DD-WRT-ը OpenVPN-ին չի տալիս այն տեքստը, որը դուք մուտքագրել եք վեբ ինտերֆեյսում։ Այն ստեղծված կոնֆիգ է գրում /tmp/openvpn/openvpn.conf-ում և դեմոնը գործարկում է այդ ֆայլով, ուստի ինտերֆեյսի դաշտերը և Additional Config-ի ցանկացած տեքստ միաձուլվում են նախքան OpenVPN-ը դրանք կտեսնի։ Եթե վրիպազերծում եք ձևը, այլ ոչ ստեղծված ֆայլը, կարդում եք մտադրություն, ոչ իրական մուտք։ Պատճենեք այդ ֆայլը մշտական տեղ, նախքան վերագործարկումը /tmp կմաքրի։

Համեմատեք ստեղծված ֆայլը նրա հետ, ինչ նախատեսել էիք, հատկապես այնտեղ, որտեղ ինտերֆեյսը գրում է հրահանգ, որը երբեք չեք ընտրել։ Ծերացած ընտրանք արտանետող բացվող ցանկը ձևում անտեսանելի է և դեմոնի համար մահացու։

Եթե ստեղծված ֆայլը դատարկ է կամ բացակայում է, դեմոնը նույնիսկ չի հասել գործարկմանը, և խնդիրը OpenVPN-ից վերև է։

Ինչը OpenVPN 2.5-ը դադարեց ընդունել

OpenVPN 2.5-ը փոխարինեց ncp-ciphers-ը data-ciphers-ով, և լռելյայն նվազագույն TLS տարբերակը բարձրացրեց 1.2-ի։ Այն նաև փոխեց սեղմման մշակումը, այնպես որ սեղմում առաջարկող գործընկերը մերժվում է, եթե կոնֆիգը բացահայտ չի թույլատրում, և հայտարարեց հնացած այնպիսի ընտրանքների անուններ, ինչպիսին է ns-cert-type-ը՝ ի օգուտ remote-cert-tls-ի։ Այս փոփոխություններից յուրաքանչյուրը նախկինում աշխատող կոնֆիգը դարձնում է վերլուծության կամ բանակցության խափանում։

Խափանման եղանակը կախված է հրահանգից։ Անհայտ կամ հեռացված ընտրանքը կանգնեցնում է դեմոնը գործարկման պահին, դա ձեր մեռած լսողն է։ Բանակցության անհամապատասխանությունը թողնում է դեմոնը աշխատի և մերժում հաճախորդներին, ինչը հաճախորդի կողմից firewall-ի խնդրի տեսք ունի։

Կարդացեք մատյանի առաջին սխալը, ոչ վերջինը։ Վերլուծությունը կանգ է առնում առաջին վատ հրահանգի վրա, և դրանից հետո ամեն ինչ անջատման աղմուկ է։

Broadcom-ին հատուկ նախապայմանները

Broadcom-ի կառուցվածքներում թունելային սարքը պետք է գոյություն ունենա նախքան դեմոնը կօգտագործի այն։ Ստուգեք, որ tun մոդուլը բեռնված է և որ /dev/net/tun առկա է, որովհետև բացակայող սարքը առաջացնում է գործարկման խափանում, որը որևէ կապ չունի վկայագրերի հետ։ Նույնը վերաբերում է DD-WRT-ի՝ երթուղիների և DNS-ի համար ստեղծած օժանդակ սկրիպտներին. եթե դրանք բացակայում են կամ գործարկելի չեն, դեմոնը կարող է սկսել և այդուամենայնիվ չավարտել իր կարգավորումը։

Գործարկեք դեմոնը առաջին պլանում ավելի մեծ մանրամասնությամբ՝ ստեղծված կոնֆիգի վրա, երբ իրական հաղորդագրության կարիք ունեք։ Առաջին պլանի գործարկումը տպում է այն վերլուծության սխալը, որը կուլ էր տվել init սկրիպտը։

Այնուհետև վերականգնեք սովորական ծառայությունը, որովհետև առաջին պլանի դեմոնը և init սկրիպտը կվիճեն պորտի համար։

Ապացուցեք, որ լսողը գոյություն ունի, նախքան հաճախորդների վրիպազերծումը

Առանձին հաստատեք գործընթացը և socket-ը. մեկ հրաման աշխատող դեմոնի համար, մյուսը՝ սպասվող հասցեում կապված UDP պորտի համար։ Առանց socket-ի գործընթացը նշանակում է, որ այն դեռ կարգավորման մեջ է կամ կապված է սխալ ինտերֆեյսին։ Զույգը օգտակար փորձարկում է հենց այն պատճառով, որ մի կեսը չի կարող ճիշտ լինել առանց մյուսի։

Հաճախորդի կողմի վրիպազերծումը իմաստ ունի միայն լսողի գոյությունից հետո։ Այնուհետև ստուգեք, որ հաճախորդի ծածկագրման և TLS կարգավորումները համապատասխանում են սերվերի data-ciphers ցանկին և նվազագույն տարբերակին, և որ պորտն իսկապես փոխանցվում է երթուղիչին։

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