MikroTik-ի PPTP-ն անջատվում է? Ուղղեք դեպի սերվեր տանող երթուղին

RouterOS-ի PPTP հաճախորդը միանում է, փոքր ինչ երթևեկություն փոխանցում և հետո դադարում, և մատյանը նման է հավատարմագրերի կամ սերվերի խնդրի։ Սովորաբար ոչ մեկն էլ չէ։ Թունելը կրում է իր սեփական տրանսպորտային փաթեթները, քանի որ դեպի սերվեր տանող երթուղին համընկնում է նաև թունելի տեղադրած երթուղու հետ։ Հակառակ կողմը դադարում է լսել երթուղիչին, և նստաշրջանը մահանում է, մինչ ինտերֆեյսը դեռ պնդում է, որ ակտիվ է։

Ուղղումը մեկ երթուղի է կամ մեկ կարգավորում, որը սերվերը հասանելի է պահում ֆիզիկական WAN-ի միջոցով։ Որն է պետք, կախված է նրանից՝ երթուղիչը պետք է լինի ամբողջական թունելի դարպաս թե ոչ։

Ախտանիշը՝ միանում է, երթևեկություն փոխանցում, մահանում է

Օրինաչափությունը կրկնվում է յուրաքանչյուր վերամիացման ժամանակ, և դա առաջին օգտակար հուշն է։ Մերժված գաղտնաբառը ձախողվում է նախքան ինտերֆեյսի բարձրանալը, հրային պատի սխալ կարգավորումը սովորաբար արգելափակում է մեկ ուղղություն, իսկ երթուղային օղակը թույլ է տալիս ինտերֆեյսին կայանալ և հետո խեղդում է այն։ Նայեք հաշվիչներին՝ թունելը ցույց է տալիս սկզբնական փաթեթների պոռթկում և հետո ոչինչ, մինչ WAN ինտերֆեյսը շարունակում է ուղարկել փաթաթված պատճեններ։ Սա երթուղիչ է, որը իր ելքը նորից իր մեջ է լցնում։

PPTP-ն դա հեշտ է հրահրում, քանի որ տրանսպորտը սերվերի հասցեին ուղղված պարզ IP է, ոչ թե թունել, որի հեռավոր ծայրը այլ ենթացանցում է։ Ամեն ինչ, որ վերահասցեավորում է այդ հասցեն, վերահասցեավորում է նաև տրանսպորտը։

Ինչու թունելը կուլ է տալիս իր իսկ փաթեթները

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

Սարքեր արտադրողները հաճախ ինքնաշխատ ավելացնում են հոսթի երթուղի իրենց սերվերի համար, հենց դա խուսափելու համար։ RouterOS-ը դա չի ենթադրում, ուստի օպերատորը պետք է արտահայտի բացառությունը կամ ի սկզբանե խուսափի լռելյայն երթուղուց։

Ամրացրեք սերվերի հասցեն WAN-ին

Ավելացրեք ամենանեղ հնարավոր երթուղին՝ /32 սերվերի հանրային հասցեի համար, մատակարարի դարպասով որպես հաջորդ ցատկ, այն ինտերֆեյսի վրա, որը հասնում է ինտերնետ։ /32-ը նախածանցի երկարությամբ հաղթում է ցանկացած լռելյայնի, և ավելի փոքր հեռավորությունը հաղթում է, եթե նույն նախածանցի համար արդեն կա այլ երթուղի։ Հետո նորից միացեք և հաստատեք, որ երթուղին ակտիվ է, ոչ թե պարզապես ցանկում առկա։

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

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

Կամ թույլ մի տվեք թունելին հավակնել լռելյայնին

Մեկ հեռավոր LAN-ի կարիք ունեցող մասնաճյուղը պետք է PPTP պրոֆիլը լռելյայն երթուղուց լիովին հեռու պահի։ Անջատեք այդ ընտրանքը հաճախորդի պրոֆիլում և փոխարենը հեռավոր նախածանցի համար կոնկրետ երթուղի ավելացրեք թունելի ինտերֆեյսով։ Սովորական երթևեկությունը մնում է WAN-ի վրա, թունելի սեփական տրանսպորտը պահպանում է իր բնական ուղին, և երթուղային աղյուսակը դառնում է ավելի հեշտ բացատրելի։ Սա ավելի լավ նախագիծ է մեկ ենթացանց պահանջող մասնաճյուղի համար, ոչ այն երթուղիչի, որը պետք է լինի կայքի ելքը։

Ամբողջական թունելն ունի իր պահանջները՝ քաղաքականության վրա հիմնված երթուղում ընտրված աղբյուրների համար, վերադարձվող երթևեկության պլան և որոշում, թե ինչ է լինում, երբ թունելն ընկնում է։ Դրանցից ոչ մեկը չի լուծում հոսթի երթուղին, որը միայն կենդանի է պահում տրանսպորտը։

Ստուգեք շերտերով, ապա փակեք կառավարման անցքը

Փորձարկեք շերտերով՝ միանալուց առաջ ping արեք սերվերի հանրային հասցեին, միանալուց հետո՝ հեռավոր դարպասին, ապա՝ հեռավոր LAN-ի հոսթին։ Ավելացրեք masquerade թունելի ինտերֆեյսին, եթե երթուղիչի հետևի հոսթերը պատասխանները դրա միջով վերադարձնելու կարիք ունեն։

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Ապա վերագործարկեք երթուղիչը կամ պարտադրեք WAN-ի վերամիացում և կրկնեք երեք ping-երը, որովհետև միայն ընթացիկ կոնֆիգուրացիայում գոյություն ունեցող երթուղին չի գոյատևի։ Պահուստային ֆայլ արտահանված և ավելի ուշ վերականգնված կոնֆիգուրացիան այն մյուս տեղն է, որտեղ սա կոտրվում է, քանի որ երթուղին կարող է բացակայել արտահանումից, եթե ավելացվել է աշխատանքի ընթացքում։

Վերջապես, սահմանափակեք Winbox-ը և վեբ կառավարումը հայտնի աղբյուր հասցեներով նախքան որևէ VPN կամ երթուղու փոփոխություն հրապարակելը։ Թունելներ ավարտող երթուղիչը կառավարման թիրախ է, և ամբողջ աշխարհի համար բաց 80 պորտը ավելի մեծ հայտնագործություն է, քան ձեր նոր ուղղած երթուղին։