Servi OpenVPN per TCP kaj UDP el unu gastiganto
Antaŭ 2.7 unu procezo ligas unu transporton. Komparu pontitan TAP-paron, du TUN-subretojn kaj komunan basenon, poste agordu ĉiun profilon al ĝia aŭskultanto.
Retoj, kiuj permesas nur TCP 443, kunekzistas kun retoj, kiuj senprobleme pasigas UDP, kaj unu servilo devas servi ambaŭ. Profilo kun proto udp respondas la duan grupon kaj malsukcesas ĉe la unua, kaj ŝanĝi la saman konfiguron por diri proto tcp ne kreas duan aŭskultanton. La direktivo elektas unu transporton por unu procezo. Ĉio alia sekvas el tiu limigo.
Aŭ vi funkciigas pli ol unu procezon, aŭ vi funkciigas version, kiu povas ligi plurajn soketojn samtempe.
Antaŭ 2.7 unu procezo ligas unu transporton
La komunuma versio de OpenVPN ligas la soketon, kiun proto priskribas, kaj tiu direktivo elektas ununuran transporton por la instanco. TCP kaj UDP estas apartaj stakoj, do la sama porthumero povas esti okupata de ambaŭ samtempe, sed ne de unu procezo. La linio 2.6 do donas al vi unu transporton por demono. OpenVPN 2.7 forigis tiun limigon por serviloj, kiuj povas ligi plurajn soketojn per pluraj --local en unu procezo.
Kontrolu la version antaŭ ol plani ĉirkaŭ iu ajn el la du respondoj, ĉar la aranĝo 2.7 estas alia operacia modelo kun propra konfigura sintakso. Gvidilo verkita por 2.6 priskribas du procezojn eĉ kiam ĝi ne diras tion.
Tri manieroj funkciigi du instancojn
Kun TAP-interfacoj, funkciigu unu instancon por transporto kaj pontu la du tap-aparatojn sur la gastiganto. Ambaŭ klientaroj finiĝas en la sama dissenda domajno, kio permesas al unu adresa baseno kovri ilin kaj tenas la dissendodependajn protokolojn funkciantaj. Kun TUN pontado ne disponeblas, do la plej simpla divido donas al ĉiu instanco sian propran subreton kaj lasas la enkursigon teni la du klientarojn aparte. Tria opcio tenas unu basenon per tio, ke ĉiu instanco vokas learn-address -skripton, kiu instalas /32-vojon por la kliento tra la aparato de tiu instanco.
Ĝuste tiu tria aranĝo estas tiu, kiun homoj petas, kaj tiu, kiu bezonas la plej grandan zorgon, ĉar la skripto fariĝas parto de la datenvojo kaj devas ĝuste pritrakti aldonajn, ĝisdatigajn kaj forigajn eventojn.
| 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 |
Tenu la du instancojn apartaj
Ĉiu instanco ankaŭ bezonas apartan pordon aŭ adreson, apartan statdosieron kaj apartan protokolan celon. Du demonoj aldonantaj al unu statdosiero produktas eligon, kiun oni ne povas legi dum incidento, kio estas ĝuste kiam vi bezonas ĝin. Se dua instanco ligas specifan adreson, tiu adreso devas ekzisti sur la gastiganto kiam la procezo startas; alie ĝi eliras per liga fiasko antaŭ ol diri ion pri ŝlosiloj.
Nomu la unuojn kaj la profilojn tiel, ke la transporto estu evidenta el la dosiernomo . La sekva operatoro ne devu malfermi konfiguron por lerni, kiu estas TCP.
Agordu la profilon al la aŭskultanto
Servilo funkciiganta proto tcp atendas klientan profilon kun proto tcp-client , kaj profilo ankoraŭ portanta proto udp kontraŭ tiu aŭskultanto tempolimas sen eraro, pri kiu la uzanto povas agi . Tenu du profilojn se la enkonduko ofertas ambaŭ transportojn, kaj etikedu ilin tiel, ke subteno povu vidi, kiu estis provita. La porthumero sola ne priskribas la transporton.
Fajroŝirmilaj reguloj sekvas la saman dividon: regulo por UDP 1194 diras nenion pri TCP 1194, kaj regulo por unu adreso ne kovras la alian aŭskultanton.
Unue legu la vidon de la servilo
Komencu per ss -lntup sur la servilo kaj konfirmu, ke aperas kaj TCP- kaj UDP-aŭskultanto. Poste konektu unu klienton de ĉiu speco kaj kontrolu la statusan eligon por du eroj kun malsamaj adresoj. Se la soketoj ekzistas kaj neniu kliento venas, la vojo aŭ la fajroŝirmilo rifuzas pakaĵojn antaŭ ol la demono vidas ilin.
Soketo, kiu neniam aperas, estas konfigura aŭ liga problemo, kaj soketo, kiu aperas sed neniam registras konekton, estas filtrada problemo. De la kliento ambaŭ aspektas idente, tial la vido de la servilo mem venas unue. Memoru, ke TCP portas blokadon ĉe la kapo de la vico, do proponi ĝin estas rimedo pri atingeblo, ne ĝisdatigo por klientoj kun pura UDP-vojo.