Shërbimi i OpenVPN përmes TCP dhe UDP nga një host i vetëm
Një proces lidh një transport para 2.7. Krahasoni një palë TAP të urëzuar, dy nënrryma TUN dhe një basen të përbashkët, pastaj përputhni çdo profil me dëgjuesin e tij.
Rrjetet që lejojnë vetëm TCP 443 bashkëjetojnë me rrjete që e kalojnë UDP pa problem, dhe një server duhet t'u shërbejë të dyjave. Një profil me proto udp i përgjigjet grupit të dytë dhe dështon në të parin, dhe redaktimi i të njëjtit konfigurim për të thënë proto tcp nuk krijon një dëgjues të dytë. Direktiva zgjedh një transport për një proces. Çdo gjë tjetër rrjedh nga ky kufizim.
Ose ekzekutoni më shumë se një proces, ose ekzekutoni një version që mund të lidhë disa soketa njëherësh.
Një proces lidh një transport para 2.7
OpenVPN i komunitetit lidh soketin që përshkruan proto, dhe ajo direktivë zgjedh një transport të vetëm për instancën. TCP dhe UDP janë pirgje të veçanta, kështu që i njëjti numër porte mund të zihet nga të dy njëkohësisht, por jo nga një proces. Prandaj rreshti 2.6 ju jep një transport për çdo daemon. OpenVPN 2.7 e hoqi atë kufizim për serverët, të cilët mund të lidhin disa soketa përmes disa deklaratave --local në një proces.
Kontrolloni versionin përpara se të projektoni rreth cilësdo përgjigje, sepse rregullimi 2.7 është një model tjetër operativ me sintaksën e vet të konfigurimit. Një udhëzues i shkruar për 2.6 përshkruan dy procese edhe kur nuk e thotë.
Tre mënyra për të ekzekutuar dy instanca
Me ndërfaqet TAP, ekzekutoni një instancë për transport dhe urëzoni dy pajisjet tap në host. Të dy grupet e klientëve përfundojnë në të njëjtin domen transmetimi, gjë që lejon një basen adresash t'i mbulojë dhe i mban protokollet e varura nga transmetimi duke punuar. Me TUN, urëzimi nuk është i disponueshëm, kështu që ndarja më e thjeshtë i jep çdo instance nënrrjetin e vet dhe rrugëtimi i mban dy grupet e klientëve të ndara. Një opsion i tretë mban një basen duke bërë çdo instancë të thërrasë një skript learn-address që instalon një rrugë /32 për klientin përmes pajisjes së asaj instance.
Ky rregullim i tretë është ai që njerëzit kërkojnë dhe ai që kërkon më shumë kujdes, sepse skripti bëhet pjesë e shtegut të të dhënave dhe duhet të trajtojë saktë ngjarjet e shtimit, përditësimit dhe fshirjes.
| 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 |
Mbajini të ndara dy instancat
Çdo instancë ka nevojë edhe për një port ose adresë të veçantë, një skedar statusi të veçantë dhe një destinacion të veçantë regjistri. Dy daemonë që shtojnë në të njëjtin skedar statusi prodhojnë dalje që nuk lexohet dot gjatë një incidenti, dhe pikërisht atëherë ju nevojitet. Nëse një instancë e dytë lidh një adresë të caktuar, ajo adresë duhet të ekzistojë në host kur procesi nis; përndryshe del me një dështim lidhjeje para se të thotë gjë për çelësat.
Emërtoni njësitë dhe profilet në mënyrë që transporti të jetë i qartë nga emri i skedarit. Operatori i radhës nuk duhet të hapë një konfigurim për të mësuar cili është TCP.
Përputhni profilin me dëgjuesin
Një server që ekzekuton proto tcp pret një profil klienti me proto tcp-client, dhe një profil që ende mban proto udp ndaj atij dëgjuesi skadon pa një gabim mbi të cilin përdoruesi mund të veprojë. Mbani dy profile nëse vendosja ofron të dy transportet, dhe etiketojini që mbështetja të dijë cili u provua. Vetëm numri i portës nuk e përshkruan transportin.
Rregullat e murit të zjarrit ndjekin të njëjtën ndarje: një rregull për UDP 1194 nuk thotë asgjë për TCP 1194, dhe një rregull për një adresë nuk mbulon dëgjuesin tjetër.
Lexoni së pari pamjen e serverit
Filloni me ss -lntup në server dhe konfirmoni se shfaqen si dëgjuesi TCP ashtu edhe ai UDP. Pastaj lidhni një klient të secilit lloj dhe kontrolloni daljen e statusit për dy zëra me adresa të dallueshme. Nëse soketat ekzistojnë dhe nuk vjen asnjë klient, shtegu ose muri i zjarrit po refuzojnë paketat para se daemoni t'i shohë.
Një soket që nuk shfaqet kurrë është problem konfigurimi ose lidhjeje, dhe një soket që shfaqet por nuk regjistron kurrë një lidhje është problem filtrimi. Të dy duken njësoj nga klienti, prandaj pamja e vetë serverit vjen e para. Mbani parasysh që TCP mbart bllokimin e kokës së radhës, kështu që ofrimi i tij është masë arritshmërie dhe jo një përmirësim për klientët me shteg UDP të pastër.