OpenVPN-ը TCP-ով և UDP-ով մեկ հոսթից սպասարկելը
Մեկ գործընթացը 2.7-ից առաջ կապում է մեկ տրանսպորտ։ Համեմատեք կամուրջով միացված TAP զույգը, երկու TUN ենթացանցերը և ընդհանուր լողավազանը, ապա յուրաքանչյուր պրոֆիլը համապատասխանեցրեք իր լսողին։
Ցանցերը, որոնք թույլ են տալիս միայն TCP 443, գոյակցում են այն ցանցերի հետ, որոնք UDP-ն անարգել անցկացնում են, և մեկ սերվերը պետք է սպասարկի երկուսին էլ։ proto udp-ով պրոֆիլը պատասխանում է երկրորդ խմբին և ձախողվում առաջինի դեպքում, իսկ նույն կոնֆիգուրացիան proto tcp ասելու համար խմբագրելը երկրորդ լսող չի ստեղծում։ Հրահանգը մեկ գործընթացի համար ընտրում է մեկ տրանսպորտ։ Մնացած ամեն ինչ բխում է այդ սահմանափակումից։
Կամ գործարկում եք մեկից ավելի գործընթաց, կամ գործարկում եք տարբերակ, որը կարող է միաժամանակ մի քանի սոքեթ կապել։
Մեկ գործընթացը 2.7-ից առաջ կապում է մեկ տրանսպորտ
Համայնքային OpenVPN-ը կապում է այն սոքեթը, որը նկարագրում է proto-ը, և այդ հրահանգը օրինակի համար ընտրում է մեկ տրանսպորտ։ TCP-ն և UDP-ն առանձին կույտեր են, ուստի նույն պորտի համարը կարող են զբաղեցնել երկուսը միաժամանակ, բայց ոչ մեկ գործընթաց։ Այդ պատճառով 2.6 շարքը տալիս է մեկ տրանսպորտ մեկ դեմոնի համար։ OpenVPN 2.7-ը հանեց այդ սահմանափակումը սերվերների համար, որոնք կարող են մի քանի սոքեթ կապել մեկ գործընթացում մի քանի --local հայտարարությունների միջոցով։
Նախքան պատասխաններից որևէ մեկի շուրջ ձևավորելը ստուգեք տարբերակը, քանի որ 2.7-ի դասավորությունը տարբեր գործառնական մոդել է՝ իր կոնֆիգուրացիայի շարահյուսությամբ։ 2.6-ի համար գրված ուղեցույցը նկարագրում է երկու գործընթաց, նույնիսկ երբ դա չի ասում։
Երկու օրինակ գործարկելու երեք եղանակ
TAP ինտերֆեյսների դեպքում գործարկեք մեկ օրինակ յուրաքանչյուր տրանսպորտի համար և կամուրջով միացրեք երկու tap սարքերը հոսթի վրա։ Երկու հաճախորդների հավաքածուները հայտնվում են նույն հեռարձակման տիրույթում, ինչը թույլ է տալիս մեկ հասցեների լողավազանի ծածկել նրանց և պահպանում է հեռարձակումից կախված արձանագրությունների աշխատանքը։ TUN-ի դեպքում կամուրջը հասանելի չէ, ուստի ամենապարզ բաժանումը յուրաքանչյուր օրինակի տալիս է իր ենթացանցը և երթուղավորումը առանձին է պահում երկու հաճախորդների հավաքածուները։ Երրորդ տարբերակը պահպանում է մեկ լողավազան՝ ստիպելով յուրաքանչյուր օրինակին կանչել learn-address սկրիպտ, որը /32 երթուղի է տեղադրում հաճախորդի համար այդ օրինակի սարքի միջով։
Այդ երրորդ դասավորությունն այն է, ինչ մարդիկ խնդրում են և որն ամենաշատ խնամքն է պահանջում, քանի որ սկրիպտը դառնում է տվյալների ուղու մաս և պետք է ճիշտ մշակի ավելացման, թարմացման և ջնջման իրադարձությունները։
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Առանձին պահեք երկու օրինակները
Յուրաքանչյուր օրինակի նաև պետք է առանձին պորտ կամ հասցե, առանձին կարգավիճակի ֆայլ և առանձին մատյանային նպատակակետ։ Մեկ կարգավիճակի ֆայլին ավելացնող երկու դեմոն ստեղծում են ելք, որը հնարավոր չէ կարդալ միջադեպի ընթացքում, և հենց այդ ժամանակ է այն ձեզ պետք։ Եթե երկրորդ օրինակը կապում է կոնկրետ հասցե, ապա այդ հասցեն պետք է գոյություն ունենա հոսթի վրա, երբ գործընթացը սկսվում է. հակառակ դեպքում այն դուրս է գալիս կապման խափանումով՝ նախքան բանալիների մասին որևէ բան ասելը։
Անվանեք միավորներն ու պրոֆիլներն այնպես, որ տրանսպորտը ակնհայտ լինի ֆայլի անունից։ Հաջորդ օպերատորը չպետք է բացի կոնֆիգուրացիա՝ իմանալու, թե որն է TCP։
Պրոֆիլը համապատասխանեցրեք լսողին
proto tcp գործարկող սերվերը սպասում է proto tcp-client-ով հաճախորդի պրոֆիլ, իսկ դեռ proto udp կրող պրոֆիլը այդ լսողի դեմ ժամկետանց է լինում առանց սխալի, որի վրա օգտատերը կարող է գործել։ Պահեք երկու պրոֆիլ, եթե տեղակայումը առաջարկում է երկու տրանսպորտները, և պիտակավորեք դրանք այնպես, որ աջակցությունը իմանա, թե որն է փորձվել։ Միայն պորտի համարը չի նկարագրում տրանսպորտը։
Հրդեհային պատի կանոնները հետևում են նույն բաժանմանը. UDP 1194-ի կանոնը ոչինչ չի ասում TCP 1194-ի մասին, և մեկ հասցեի կանոնը չի ծածկում մյուս լսողին։
Նախ կարդացեք սերվերի տեսքը
Սկսեք սերվերի վրա ss -lntup-ով և հաստատեք, որ երևում են և՛ TCP, և՛ UDP լսող։ Այնուհետև միացրեք յուրաքանչյուր տեսակից մեկ հաճախորդ և ստուգեք կարգավիճակի ելքը՝ տարբեր հասցեներով երկու գրառման համար։ Եթե սոքեթները կան, բայց հաճախորդ չի գալիս, ուղին կամ հրդեհային պատը մերժում են փաթեթները՝ նախքան դեմոնը կտեսնի դրանք։
Երբեք չհայտնվող սոքեթը կոնֆիգուրացիայի կամ կապման խնդիր է, իսկ հայտնվող, բայց երբեք միացում չգրանցող սոքեթը՝ զտման խնդիր։ Հաճախորդի կողմից երկուսը նույն տեսքն ունեն, դրա համար էլ սերվերի սեփական տեսքը առաջինն է։ Նկատի ունեցեք, որ TCP-ն կրում է հերթի գլխի արգելափակում, ուստի այն առաջարկելը հասանելիության միջոց է, այլ ոչ թե բարելավում մաքուր UDP ուղի ունեցող հաճախորդների համար։