OpenVPN TUN և TAP՝ երեք պայման, որոնք որոշում են

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

Գործնականում երեք պայման է որոշում։ Անցեք դրանք հերթականությամբ, քանի որ առաջինը սովորաբար ավարտում է քննարկումը։

Ինչ է իրականում տեղափոխում յուրաքանչյուր ինտերֆեյս

TUN սարքը 3-րդ շերտի կետ-կետ ինտերֆեյս է, որին միջուկը IP փաթեթներ է տալիս, և թունելը դրանք տանում է զուգընկերոջ հասցե։ TAP սարքը 2-րդ շերտի ինտերֆեյս է, որը տեղափոխում է Ethernet կադրեր, և հենց դա է ընդհանրապես հնարավոր դարձնում կամրջումը, ինչպես նկարագրում է միջուկի փաստաթղթերը։ Դրանցից ոչ մեկը չի փոխում, թե ինչպես է գաղտնագրվում բեռը, և ոչ մեկը ուժի կարգավորում չէ։ Ընտրությունը վերաբերում է նրան, ինչ ծայրերը պետք է փոխանակեն, ոչ թե նրան, թե որքան լավ է պաշտպանված երթևեկությունը։

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

Առաջին պայման՝ արդյո՞ք ինչ-որ բան պետք է երկրորդ շերտ։

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

Փորձարկումը կոնկրետ է՝ նշեք հավելվածը, որը ձախողվում է երթուղավորված թունելում, և ասեք ինչու։ Եթե պատասխանն այն է, որ դրան հեռարձակում է պետք, երկրորդ շերտը ազնիվ պատասխանն է։ Եթե պատասխանն այն է, որ ինչ-որ մեկը չի հասել մեկ սերվերի, պահանջը երթուղի է կամ ֆայրվոլի կանոն։

Երկրորդ պայման՝ կարո՞ղ են հաճախորդները։

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

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

Երրորդ պայման՝ արդյո՞ք սա իսկապես ինտերֆեյսի հարց է։

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

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

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

Հարցը չէ, թե որ տարբերակն է ավելի ուժեղ։ Հարցն այն է, թե որն է իրականում պետք երթևեկությանը։