Ներմուծված VPN երթուղիները տարբերվու՞մ են աշխատող հաճախորդից։ Համեմատեք երկուսն էլ

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

Պահված կոնֆիգուրացիան ցանցի փաստացի վիճակի հետ համեմատելու համար պահանջվում է երեք հրաման, և այն պատասխանում է այն հարցին, որին փորձում էին պատասխանել գուշակությունները։

Սկզբում պահված պրոֆիլը, հետո փաստացի վիճակը

Ներմուծված OpenVPN միացումը դառնում է առանձին NetworkManager պրոֆիլ։ .ovpn ֆայլը, որտեղից այն եկել է, դադարում է ճշմարտության աղբյուր լինելուց ներմուծման ավարտի պահին, ուստի այդ ֆայլի հետագա խմբագրումը ոչինչ չի փոխում ձեր օգտագործած միացման մեջ։ Սա առաջին տեղն է, որտեղ համեմատությունը սխալ է գնում, և սխալ է գնում լուռ։

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

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

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

ip -4 rule show
ip -4 route show table all

Երկու նպատակակետ, մեկ համեմատություն

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

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

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

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

Որտեղ երկու հաճախորդները օրինական կերպով տարբերվում են

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

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

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

Պահեք համեմատությունը մաքուր

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

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

NetworkManager-ի IPv4 կարգավորումների տեղեկագիրքը ճշգրիտ սահմանում է never-default-ը և պահված երթուղու հատկությունները, ինչը արժե կարդալ նախքան կառավարվող արժեքը փոխելը։ Եվ հիշեք այս համեմատության շրջանակը․ այն ընդգրկում է IPv4-ը և ոչինչ չի ասում համապատասխան IPv6 քաղաքականության մասին, որն ունի իր լռելյայնները և ձեզ զարմացնելու իր ձևը։