OpenVPN սերվեր և կլիենտ մեկ հոսթի վրա. ինչու են կլիենտները կորչում

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

Մեկ մեքենա, երկու դեր և երկու անհամատեղելի պատասխան այն մասին, թե ուր պետք է գնան պատասխանները։

Նույն ավազանը, երկու սերվեր. ով է հաղթում

Յուրաքանչյուր սերվերի օրինակի պետք է իր սեփական թունելային ենթացանցը։ server 10.8.0.0 255.255.255.0-ի նման տողը երկրորդ կոնֆիգուրացիայի մեջ պատճենելը երկու օրինակներին տալիս է նույն նախածանցը, և արդյունքը կա՛մ մեկնարկելու մերժումն է, կա՛մ լուռ մրցակցություն, որտեղ մի սերվերի կլիենտները ստանում են հասցեներ, որոնք մյուսը նույնպես իրենն է համարում։ Տարբեր UDP պորտերը և տարբեր սարքերի անունները չեն օգնում, քանի որ ոչ մեկը չի դիպչում հասցեային տարածությանը։ Փոխեք երկրորդ ավազանը և փոխեք այն ամենուր, որտեղ երթուղիները հիշատակում են այն։

Թվարկեք, թե ինչ է ակտիվ խմբագրելուց առաջ։ ip -4 addr show-ը թվարկում է թունելային սարքերը, ss -lunp-ը՝ լսողներին, իսկ systemctl list-units-ը անվանում է միավորները։ Թունելային հասցեներին մեկ հայացքը որոշում է՝ արդյոք ավազանները բախվում են։

Ինչ է ավելացնում կլիենտի պրոֆիլը աղյուսակին

Կլիենտ-կեսը երթուղիներ է գրում հենց միանալուն պես։ redirect-gateway def1-ը լռելյայն երթուղին բաժանում է 0.0.0.0/1 գումարած 128.0.0.0/1-ի, երկուսն էլ երթուղվում են նոր սարքի միջով, հեռու սերվերին տանող հոսթ-երթուղու հետ միասին, որը դիտավորյալ ամրացված է ֆիզիկական ինտերֆեյսին։ Այդ ամրացումը կա, որպեսզի թունելը պահի իր սեփական տրանսպորտի ուղին։ Մնացած ամեն ինչ, ներառյալ այն պատասխանները, որ տեղական սերվերը պարտք է իր իսկ կլիենտներին, այժմ հետևում է նոր լռելյայնին և դուրս գալիս հեռավոր կապով։

Այսպիսով, երկրորդ բախումը կոտրված թունել չէ։ Դա աշխատող թունել է աղյուսակի սխալ տեղում։

Դերերը իրարից հեռու պահելու երեք եղանակ

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

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

Երկու օրինակներից ով է մեղավոր

Կանգնեցրեք կլիենտի օրինակը և նորից փորձարկեք սկզբնական կլիենտներին։ Ակնթարթային վերականգնումը նշանակում է երթուղավորում, ոչ թե սերվեր։ Վերադարձրեք կլիենտը և հետևեք մեկ պատասխանի ip route get-ով, որին տրվել են և՛ աղբյուրի, և՛ նպատակակետի հասցեներ, ինչը ցույց է տալիս այն ուղին, որը կընտրեր միջուկը, ապա դիտեք, թե փաթեթներն իրականում որ ինտերֆեյսն են օգտագործում tcpdump -ni any port 1194-ով։ Սերվերի կարգավիճակի ֆայլը, որը գրվում է ամեն մի քանի վայրկյանը մեկ status հրահանգով, պարունակում է միացած կլիենտների ցանկը և բայթերի հաշվիչներ երկու ուղղություններով։

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