Ինչ է իրականում bypass-dhcp-ը ավելացնում OpenVPN-ի երթուղային պլանին

redirect-gateway def1 bypass-dhcp պարունակող պրոֆիլը միավորում է IPv4 լռելյայն երթուղու փոխարինումը մեկ նեղ բացառության հետ։ Մարդիկ կարդում են վերջին բառը և սպասում բջջային կապերի ընդհանուր լուծման, ապա կես օր են անցկացնում DHCP տեսության վրա, որը դրոշը երբեք չի աջակցել։ Յուրաքանչյուր մաս մեկ գործ է անում, և բացառությունը շատ ավելի փոքր է իր համբավից։

Առանձնացրեք դրոշները նախքան միայն բջջային ցանցում առաջացող խափանումը հասցեների բաշխմանը վերագրելը։ Այդ տողի երկու կեսերը ոչ մի կապ չունեն միմյանց հետ։

Երկու դրոշ, երկու անկապ գործ

def1-ի դեպքում հաճախորդը ավելացնում է երկու IPv4 կիսալռելյայն երթուղի՝ արդեն գոյություն ունեցող լռելյայն երթուղին փոխարինելու փոխարեն։ 0.0.0.0/1-ը ծածկում է հասցեային տարածության ստորին կեսը, իսկ 128.0.0.0/1-ը՝ վերին կեսը, այնպես որ միասին հասնում են ցանկացած նպատակակետի, մինչդեռ յուրաքանչյուրը մնում է ավելի կոնկրետ, քան 0.0.0.0/0-ը։ Ուստի սկզբնական լռելյայն երթուղին մնում է աղյուսակում՝ չհաղթելով այդ որոնումներում, ինչը հին դարպասը հասանելի է պահում այն ամենի համար, ինչ հաճախորդը երթուղավորում է բացահայտ։ Այն նաև աղյուսակում թողնում է երկու համընկնող լռելյայն երթուղի, և դրա համար է, որ երթուղիների արտածումը կարող է ավելի տարօրինակ թվալ, քան պրոֆիլն է հուշում։

bypass-dhcp-ը առանձին է և ընդհանրապես չի դիպչում լռելյայն երթուղուն։ OpenVPN 2.6 ձեռնարկը նկարագրում է այն որպես ուղիղ երթուղի ավելացնել տեղական ենթացանցում չգտնվող DHCP սերվերին, որպեսզի վարձույթի թրաֆիկը դուրս գա թունելից, և նշում է, որ այս վարքը ներդրված է Windows հաճախորդներում և այլուր կարող է հասանելի չլինել։

Դրա գոյության պատճառը մեխանիկական է։ Երբ կիսալռելյայն երթուղիները գրավեն ելքային թրաֆիկը, ֆիզիկական ցանցի սերվերին ուղղված DHCP թարմացումը կուղղորդվի թունելի մեջ, եթե ինչ-որ բան այդ հասցեն չամրացնի իրական միջերեսին։ Դրոշն այն ամրացնում է։

Ինչի վրա է իրականում տարածվում բացառությունը

Հաջող միացումից հետո պատկերավոր աղյուսակը ցույց է տալիս ձևը՝ երկու կիսալռելյայն երթուղի թունելով, և մեկ հոսթ-երթուղի DHCP սերվերի համար ֆիզիկական դարպասով։ Կարդացեք այն որպես ձև, ոչ որպես ձեր սեփական հասցեներ։

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

Ստուգեք, թե հաճախորդն ինչ է իրականում տեղադրել

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

VPN-ի վերջնակետի երթուղին միաժամանակ օգտագործելի պահեք։ Այդ վերջնակետի բացառությունը տարբեր պահանջ է DHCP բացառությունից, և առանց դրա թունելը կարող է գրավել իրեն պահող տրանսպորտը։

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

Ուղու մնացած մասը այս դրոշում չէ

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

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

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