pfSense OpenVPN. այլ երթուղիչի հետևում գտնվող ցանցին հասնելը

Ձեր նոթբուքը VPN-ի միջոցով հասնում է pfSense-ի LAN-ին և այնուամենայնիվ չի կարողանում հասնել ևս երկու թռիչք ներս գտնվող ծառայության, և տարբերությունը յուրաքանչյուր սեփականատիրոջ համար մեկ երթուղային որոշում է։ Փաթեթը իր հետադարձ ուղևորությունը ավարտելուց առաջ երեք սարք պետք է համաձայնության գան՝ հաճախորդը, հրակայուն պատը և այն երթուղիչը, որն իրականում տիրապետում է նպատակակետ ցանցին։ Բաց թողեք դրանցից որևէ մեկը, և ախտանիշը նույն տեսքը կունենա։

Նախքան կանոն փոխելը հետևեք մեկ փաթեթի այդ երեք որոշումների միջով, որովհետև յուրաքանչյուր սեփականատեր ունի տարբեր վերահսկողություն և տարբեր ձախողման ձև։

Մեկ փաթեթ, երեք երթուղային որոշում

Հաճախորդը որոշում է՝ նպատակակետը պատկանում է թունելին, և կարող է որոշել միայն այն ամենից, ինչ գիտի՝ հրող երթուղուց, տեղական երթուղուց կամ արդեն ամեն ինչ ընդգրկող լռելյայնից։ pfSense-ը որոշում է, թե ուր ուղարկել փաթեթը հաջորդիվ, ինչը այլ երթուղիչի հետևում գտնվող ցանցի համար նշանակում է ստատիկ երթուղի ճիշտ ինտերֆեյսում հասանելի դարպասի միջով։ Ստորին երթուղիչը որոշում է՝ արդյոք գիտի ճանապարհ դեպի VPN լողավազան, և եթե չգիտի, պատասխանը դեն է նետվում կամ ուղարկվում անօգուտ տեղ։ Յուրաքանչյուր որոշում անկախ է մյուս երկուսից։

Դրանցից որևէ մեկի ձախողումը տալիս է նույն օգտվողական հաշվետվությունը։ Այդ պատճառով վրիպազերծման հերթականությունն ավելի կարևոր է, քան գործիքները։

Տվեք հաճախորդին նախածանց, ոչ թե ենթադրություն

pfSense SSL/TLS սերվերի վրա, որի IPv4 թունելային ցանցը մեծ է /30-ից, IPv4 Local network(s) դաշտը միանալիս երթուղիներ է բաշխում հաճախորդներին։ Ավելացրեք ստորին նախածանցը այնտեղ՝ փոխարենը հույս դնելով, որ հաճախորդը ինքը մեկը կհնարի։ Այնուհետև միանալուց հետո կարդացեք հաճախորդի իրական աղյուսակը, որովհետև route-nopull-ով պրոֆիլը կամ երթուղու զտիչը կարող է անտեսել այն, ինչ ուղարկել է սերվերը։ Սերվերը կարող է լիովին ճիշտ լինել, մինչ հաճախորդը ոչինչ չի տեղադրում։

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

Ուղղեք pfSense-ը դեպի ներքին երթուղիչ

pfSense-ում ստատիկ երթուղուն պետք է սահմանված և հասանելի դարպաս, և այդ դարպասի համար ընտրված ինտերֆեյսը պետք է լինի այն, որն իրականում հասնում է նրան, ինչպես նկարագրում է Netgate-ի ստատիկ երթուղիների ուղեցույցը։ Օրինակելի դասավորության մեջ տրանզիտ կապը 192.168.77.1-ն է հրակայուն պատի վրա և 192.168.77.2-ը՝ ներքին երթուղիչի վրա, իսկ ծառայության ցանցը՝ 172.16.30.0/25-ը դրա հետևում։ Այնուհետև երթուղին անվանում է նախածանցն ու հաջորդ թռիչքը, ոչ թե ծառայության հասցեն։ Հեռավոր ցանցից հասցեն որպես դարպաս օգտագործելը սովորական ձև է կառուցելու երթուղի, որը ճիշտ է թվում և ոչ մի տեղ չի փոխանցում։

Ինտերֆեյսին անուն տալը չի նկարագրում դրա հետևում գտնվող ցանցերը։ Ստատիկ երթուղին այդ նկարագրությունն է։

Հեռավոր կողմը պետք է իմանա լողավազանը

Ստորին երթուղիչին պետք է վերադարձի երթուղի դեպի լողավազան, այս օրինակում՝ 10.55.0.0/24 192.168.77.1-ով, եթե լռելյայն երթուղին կամ դինամիկ արձանագրությունն արդեն մեկը չի ապահովում։ Ծառայության հոսթի սեփական դարպասը պետք է տանի այդ երթուղիչի ուղղությամբ, ինչը սովորաբար ճիշտ է, երբ երթուղիչը նրա լռելյայն դարպասն է, և սխալ, երբ հոսթը ձեռքով է կարգավորվել։ Հրակայուն պատի քաղաքականությամբ երթուղավորումը նույնպես կարող է շրջանցել աղյուսակը կոնկրետ տրաֆիկի համար, ուստի նախքան եզրակացնելը, որ երթուղին սխալ է, ստուգեք՝ արդյոք կանոնը այլ դարպաս է ընտրում։

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

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

Պահպանեք երեք սեփականատերերի պլանը թույլատրված հավելվածի կողքին, որպեսզի հաջորդ ադմինիստրատորը կարողանա վերականգնել ուղին՝ այն նորից չհայտնաբերելու փոխարեն։