DD-WRT-ի PPTP հաճախորդները միմյանց չեն հասնում. հինգ ստուգում

Երկու նոթբուք զանգահարում են DD-WRT սարքի PPTP սերվեր, ամեն մեկը հասցե է ստանում, և ոչ մեկը չի կարող ping անել մյուսին։ Համօգտագործվող պանակները երբեք չեն հայտնվում, և առաջին միտքն այն է, որ երթուղիչի տվող 255.255.255.255 դիմակը պետք է սխալ լինի։ Դա պատճառը չէ, և փոխելը ոչ մի նոր հարևան չի ստեղծի։ Կատարեք ստորև բերված հինգ ստուգումները հերթականությամբ և կանգ առեք հենց որ մեկը ձախողվի, որովհետև ամեն մեկն ունի տարբեր բուժում։

Առաջին ստուգում. /32-ը սխալը չէ

PPTP-ն կրում է PPP, և PPP կապը միացնում է ուղիղ երկու վերջնակետ՝ ձեր հաճախորդը և սերվերը։ Ցանցի դիմակը նկարագրում է, թե որ հասցեներն են կիսում տեղական հատվածը, իսկ այստեղ հատված չկա, միայն զույգը մեկ լարի մյուս ծայրին։ Բոլորը մեկից բաղկացած դիմակը հենց դա է ասում, ուստի DD-WRT-ն տալիս է այդ կապի տեսակի համար ճիշտ արժեքը։ Հասցեն զույգի հասցե է, ոչ թե LAN-ի ինտերֆեյսի հասցե։

255.255.255.0 դիմակը տեղ ունի հարյուրավոր սարքերով ընդհանուր միջավայրում, և այն PPP ինտերֆեյսի վրա դնելը թունելի մյուս կողմին հարևան չի դարձնի։

Երկրորդ ստուգում. կարդացեք PPTP սերվերի էջի արժեքները

Բոլոր կարևոր կարգավորումները Ծառայություններ, VPN, PPTP սերվեր բաժնում են։ Միացրեք սերվերը, սահմանեք սերվերի հասցեն երթուղիչի LAN հասցեն, և հաճախորդների տիրույթը պահեք DHCP լողավազանից դուրս, որպեսզի զանգահարող հաճախորդն ու մալուխով մեքենան նույն հասցեն չստանան։ CHAP-Secrets-ի տակ ավելացրեք մեկ տող յուրաքանչյուր հաշվի համար username * password * տեսքով, առանց բացատների անվան մեջ։ Կիրառեք, ապա միացեք պրոֆիլով, որը նշում է երթուղիչը և այդ հաշիվներից մեկը։

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

Երրորդ ստուգում. փնտրեք երթուղի երկու զույգերի միջև

Երթուղիչի վրա ավարտվող յուրաքանչյուր թունել իր ինտերֆեյսն ունի, սովորաբար ppp0, ppp1 և այլն։ Մի հաճախորդից մյուսը երթևեկությունը պետք է երթուղավորվի այդ ինտերֆեյսների միջև, և երթուղիչը պետք է պատրաստ լինի այն փոխանցել։ Երթուղիչի վրա գործարկեք ip route և փնտրեք հոսթի երթուղի յուրաքանչյուր միացած զույգի համար, որը ցույց է տալիս համապատասխան PPP ինտերֆեյսին։ Եթե զույգին երթուղի է պակասում, թունելը ամբողջությամբ վերև չէ, ինչ էլ որ պնդի հաճախորդի կարգավիճակի էկրանը։

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

Չորրորդ ստուգում. նայեք FORWARD շղթային, ոչ INPUT-ին

Հաճախորդների միջև երթևեկությունը փոխանցվում է, ոչ թե տեղում ընդունվում, ուստի INPUT շղթան սխալ տեղ է։ Գործարկեք iptables -L FORWARD -v -n և փնտրեք drop կանոն, որը բռնում է PPP ինտերֆեյսները, ինչպես նաև փաթեթների հաշվիչները, որոնք ցույց են տալիս՝ ընդհանրապես ինչ-որ բան հասնում է շղթային։ Առանց թունելի երթևեկության ընդունման կանոնի լռելյայն drop քաղաքականությունը ստեղծում է հենց այն ախտանիշը, որով սկսել եք. ամեն հաճախորդ առանձին լավ է, միասին նրանք անտեսանելի են միմյանց համար։

Եթե փոքր ping-երը աշխատում են, իսկ մեծ փոխանցումները կանգ են առնում, թունելը մասնատվում է, ոչ թե արգելափակվում։ PPP-ի վրայի PPTP-ն սովորաբար ուզում է MTU և MRU մոտ 1450, և դրանք 1500-ի վրա թողնելը տալիս է կապ, որն անցնում է ձեռքսեղմումները և ձախողվում իրական բեռների վրա։

Հինգերորդ ստուգում. որոշեք, թե ինչ պետք է անի ինտերնետ հասանելիությունը

Գրասենյակով զննարկելու համար նախատեսված հաճախորդներին պետք է աղբյուրի հասցեի թարգմանություն դեպի WAN ինտերֆեյս։ Նրանք, ովքեր պետք է հասնեն միայն LAN, պետք է երթուղի և ոչինչ ավելին։ Դրանք տարբեր մտադրություններ են տարբեր կանոնների հավաքածուներով, և դիմակի հարցը լիովին թաքցնում է այս երկրորդ որոշումը։ Գրի առեք, թե ինչ վարք էիք ուզում, նախքան գեթ մեկ կանոն ավելացնելը, որովհետև անսպասելիորեն գրասենյակի գծով դուրս եկող հաճախորդը անակնկալ է, որը ի հայտ է գալիս ժողովում, ոչ թե մատյանում։

Վերջին նշում, որ կապ չունի շտկման հետ. PPTP-ն հնացած է, և նրա նույնականացումը տարիներ շարունակ կոտրված է։ Վերևի ցանկը դեռ բացատրում է, թե ինչ է անում PPP կապը, և նույն տրամաբանությունը գործում է, եթե հետագայում հաճախորդներին տեղափոխեք ժամանակակից թունել։