OpenVPN-i bir hostdan TCP və UDP üzərində təqdim etmək
2.7-dən əvvəl hər proses bir nəqliyyat bağlayır. Körpülənmiş TAP cütünü, iki TUN alt şəbəkəsini və ortaq hovuzu müqayisə edin, sonra hər profili öz dinləyicisinə uyğunlaşdırın.
Yalnız TCP 443-ə icazə verən şəbəkələr UDP-ni rahat keçirən şəbəkələrlə birgə mövcuddur və bir server hər ikisinə xidmət etməlidir. proto udp olan profil ikinci qrupa cavab verir, birincidə isə uğursuz olur; eyni konfiqurasiyanı dəyişib proto tcp yazmaq ikinci dinləyici yaratmır. Direktiva bir proses üçün bir nəqliyyat seçir. Qalan hər şey bu məhdudiyyətdən irəli gəlir.
Ya birdən çox proses işlədirsiniz, ya da eyni anda bir neçə soket bağlaya bilən versiyanı işlədirsiniz.
2.7-dən əvvəl bir proses bir nəqliyyat bağlayır
İcma versiyası olan OpenVPN proto ilə təsvir olunan soketi bağlayır və həmin direktiva instans üçün tək bir nəqliyyat seçir. TCP və UDP ayrı yığınlardır, ona görə eyni port nömrəsi hər ikisi tərəfindən eyni vaxtda tutula bilər, amma bir proses tərəfindən tutula bilməz. Buna görə 2.6 xətti sizə hər daemon üçün bir nəqliyyat verir. OpenVPN 2.7 serverlər üçün bu məhdudiyyəti aradan qaldırdı; onlar bir prosesdə bir neçə --local ifadəsi ilə bir neçə soket bağlaya bilər.
Hər iki cavabdan hansının ətrafında dizayn etməzdən əvvəl versiyanı yoxlayın, çünki 2.7 quruluşu öz konfiqurasiya sintaksisi olan fərqli əməliyyat modelidir. 2.6 üçün yazılmış bələdçi bunu deməsə də iki prosesi təsvir edir.
İki instansı işlətməyin üç yolu
TAP interfeysləri ilə hər nəqliyyat üçün bir instans işlədin və hostdakı iki tap cihazını körpüləyin. Hər iki müştəri dəsti eyni yayım domeninə düşür, bu da bir ünvan hovuzunun onları əhatə etməsinə imkan verir və yayımdan asılı protokolları işlək saxlayır. TUN ilə körpüləmə mövcud deyil, ona görə ən sadə bölgü hər instansa öz alt şəbəkəsini verir və marşrutlaşdırma iki müştəri dəstini ayrı saxlayır. Üçüncü variant hər instansın learn-address skriptini çağırması ilə bir hovuz saxlayır; skript müştəri üçün həmin instansın cihazı vasitəsilə /32 marşrutu quraşdırır.
Bu üçüncü quruluş insanların istədiyi və ən çox diqqət tələb edən quruluşdur, çünki skript məlumat yolunun bir hissəsinə çevrilir və əlavə, yeniləmə və silmə hadisələrini düzgün emal etməlidir.
| 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 |
İki instansı ayrı saxlayın
Hər instans ayrıca port və ya ünvana, ayrıca status faylına və ayrıca jurnal hədəfinə də ehtiyac duyur. Tək status faylına əlavə edən iki daemon insident zamanı oxuna bilməyən çıxış yaradır, halbuki ona məhz o anda ehtiyacınız olur. İkinci instans müəyyən ünvan bağlayırsa, proses başlayanda həmin ünvan hostda mövcud olmalıdır; əks halda açarlar barədə heç nə deməzdən əvvəl bağlama xətası ilə çıxır.
Vahidləri və profilləri elə adlandırın ki, nəqliyyat fayl adından aydın olsun . Növbəti operator hansının TCP olduğunu öyrənmək üçün konfiqurasiya açmaq məcburiyyətində qalmamalıdır.
Profili dinləyiciyə uyğunlaşdırın
proto tcp işlədən server proto tcp-client olan müştəri profili gözləyir və hələ də proto udp daşıyan profil həmin dinləyiciyə qarşı istifadəçinin cavab verə biləcəyi xəta olmadan vaxt aşımına uğrayır . Yerləşdirmə hər iki nəqliyyatı təklif edirsə iki profil saxlayın və hansının sınandığını dəstəyin görə bilməsi üçün onları etiketləyin. Yalnız port nömrəsi nəqliyyatı təsvir etmir.
Firewall qaydaları eyni bölgüyə əməl edir: UDP 1194 üçün qayda TCP 1194 barədə heç nə demir və bir ünvan üçün qayda digər dinləyicini əhatə etmir.
Əvvəlcə serverin görünüşünü oxuyun
Serverdə ss -lntup ilə başlayın və həm TCP, həm də UDP dinləyicisinin göründüyünü təsdiqləyin. Sonra hər növdən bir müştəri qoşun və status çıxışında fərqli ünvanları olan iki girişi yoxlayın. Soketlər varsa və heç bir müştəri gəlmirsə, yol və ya firewall paketləri daemon onları görməzdən əvvəl rədd edir.
Heç vaxt görünməyən soket konfiqurasiya və ya bağlama problemidir, görünən amma heç bir bağlantı qeyd etməyən soket isə filtrləmə problemidir. Bu ikisi müştəri tərəfindən eyni görünür, buna görə serverin öz görünüşü birinci gəlir. Yadda saxlayın ki, TCP sıra başının bloklanmasını daşıyır, ona görə onu təklif etmək təmiz UDP yolu olan müştərilər üçün yüksəltmə deyil, əlçatanlıq tədbiridir.