VPN պորտը բացելը չի տանում հաճախորդներին LAN

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

Երկու շղթա, երկու տարբեր նպատակակետ

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

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

Ինչ է իրականում թույլատրում լսորդի կանոնը

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

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

Փորձարկեք հաճախորդից, երբեք դարպասից

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

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Եթե հարցումը երևում է tun0-ի վրա, և ոչինչ չի հասնում նպատակակետին, փաթեթը դեն է նետվում ժամանելուց հետո, ինչը մատնանշում է փոխանցման կանոններին կամ նպատակակետի սեփական զտմանը։ Եթե tun0-ի վրա ընդհանրապես ոչինչ չի երևում, հաճախորդը այն նույնիսկ թունել չի ուղարկում, և խնդիրը հաճախորդի երթուղավորումն է, ոչ թե դարպասի քաղաքականությունը։ Համեմատեք դա ճիշտ դուրս եկող և ոչինչ չվերադարձնող հարցման հետ, ինչը վերադարձի ուղու դեպքն է։

Փոխանցումը պահանջում է երեք բան, ոչ թե մեկը

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

Փաստաթղթերում երկու կանոնների հավաքածուները պահեք առանձին

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

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

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