OpenVPN TCP eta UDP bidez ostalari bakar batetik zerbitzatzea
2.7 baino lehen prozesu bakoitzak garraio bat lotzen du. Konparatu zubiratutako TAP pare bat, bi TUN azpisare eta partekatutako pool bat, eta egokitu profil bakoitza bere entzuleari.
TCP 443 soilik onartzen duten sareak UDP erraz igarotzen duten sareekin bizi dira, eta zerbitzari bakar batek biak zerbitzatu behar ditu. proto udp duen profilak bigarren taldeari erantzuten dio eta lehenengoan huts egiten du, eta konfigurazio bera proto tcp esateko aldatzeak ez du bigarren entzulerik sortzen. Zuzentarauak garraio bakarra aukeratzen du prozesu baterako. Gainerako guztia murrizketa horretatik dator.
Edo prozesu bat baino gehiago exekutatzen dituzu, edo socket batzuk aldi berean lotu ditzakeen bertsioa exekutatzen duzu.
2.7 baino lehen prozesu batek garraio bat lotzen du
Komunitate-bertsioak OpenVPN socket-a lotzen du, proto -k deskribatzen duena, eta zuzentarau horrek garraio bakarra aukeratzen du instantziarako. TCP eta UDP pila bereiziak dira, beraz portu-zenbaki bera biek aldi berean har dezakete, baina ez prozesu bakar batek. Beraz, 2.6 lerroak garraio bat ematen dizu daemon bakoitzeko. OpenVPN 2.7-k muga hori kendu zuen zerbitzarientzat, prozesu bakarrean hainbat socket --local anitzen bidez lotu ditzaketenak.
Egiaztatu bertsioa bi erantzunetakoren baten inguruan diseinatu aurretik, 2.7-ko antolamendua bere konfigurazio-sintaxia duen funtzionamendu-eredu desberdina baita. 2.6rako idatzitako gidak bi prozesu deskribatzen ditu, hala esaten ez duenean ere.
Bi instantzia exekutatzeko hiru modu
TAP interfazeekin, exekutatu instantzia bat garraio bakoitzeko eta zubiratu hosteko bi tap gailuak. Bi bezero-multzoak difusio-domeinu berean gelditzen dira, eta horrek helbide-pool bakar batek estaltzea ahalbidetzen du eta difusioaren mendeko protokoloak martxan mantentzen ditu. TUN-ekin zubiratzea ez dago erabilgarri, beraz banaketa sinpleenak instantzia bakoitzari bere azpisarea ematen dio eta bideratzeak bi bezero-multzoak bereizita mantentzen ditu. Hirugarren aukerak pool bakarra mantentzen du instantzia bakoitzak learn-address script bat deituz, bezeroarentzat /32 bide bat instalatzen duena instantzia horren gailuaren bidez.
Hirugarren antolamendu hori da jendeak eskatzen duena eta arreta handiena behar duena, script-a datu-bidearen parte bihurtzen delako eta gehitu, eguneratu eta ezabatu gertaerak behar bezala kudeatu behar dituelako.
| 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 |
Eduki bi instantziak bereizita
Instantzia bakoitzak portu edo helbide bereizia, egoera-fitxategi bereizia eta log helmuga bereizia ere behar ditu. Egoera-fitxategi berdinera gehitzen duten bi daemonek istripu batean irakurri ezin den irteera sortzen dute, eta hori da hain zuzen behar duzun unea. Bigarren instantzia bate helbide zehatz bat lotzen badu, helbide horrek hostean egon behar du prozesua hastean; bestela lotze-hutsegitearekin irteten da gakoei buruz ezer esan aurretik.
Izendatu unitateak eta profilak, garraioa fitxategi-izenetik argi gera dadin . Hurrengo eragileak ez luke konfigurazio bat ireki behar jakiteko zein den TCP.
Egokitu profila entzuleari
proto tcp exekutatzen duen zerbitzari batek proto tcp-client duen bezero-profila espero du, eta oraindik proto udp daraman profilak entzule horren aurka denbora-muga gainditzen du erabiltzaileak jokatu dezakeen errorerik gabe . Mantendu bi profil hedapenak bi garraioak eskaintzen baditu, eta etiketatu zein probatu den euskarriak jakin dezan. Portu-zenbakiak bakarrik ez du garraioa deskribatzen.
Suhormaren arauek banaketa bera jarraitzen dute: UDP 1194rako arauak ez du ezer esaten TCP 1194ri buruz, eta helbide baterako arauak ez du beste entzulea estaltzen.
Irakurri lehenengo zerbitzariaren ikuspegia
Hasi zerbitzarian ss -lntup erabiliz eta egiaztatu TCP eta UDP entzuleak agertzen direla. Ondoren konektatu mota bakoitzeko bezero bat eta begiratu egoera-irteeran helbide desberdinetako bi sarrera daudela. Socketak badaude eta bezerorik iristen ez bada, bideak edo suhormak paketeak ukatzen ditu daemonak ikusi aurretik.
Inoiz agertzen ez den socket bat konfigurazio edo lotze arazoa da, eta agertzen den baina inoiz konexiorik erregistratzen ez duen socket bat iragazketa arazoa da. Bezeroaren aldetik biak berdinak dirudite, horregatik zerbitzariaren beraren ikuspegia dator lehenengo. Kontuan izan TCP-k lerro-buruko blokeoa daramala, beraz hura eskaintzea irisgarritasun-neurria da, ez bertsio-berritzea UDP bide garbia duten bezeroentzat.