OpenVPN:n tarjoaminen TCP:n ja UDP:n yli yhdeltä isännältä
Ennen versiota 2.7 yksi prosessi sitoo yhden kuljetuksen. Vertaa sillattua TAP-paria, kahta TUN-aliverkkoa ja jaettua allasta ja sovita sitten jokainen profiili kuuntelijaansa.
Verkot, jotka sallivat vain TCP 443:n, ovat olemassa rinnakkain verkkojen kanssa, jotka päästävät UDP:n helposti läpi, ja yhden palvelimen on palveltava molempia. Profiili, jossa on proto udp , vastaa toiselle ryhmälle ja epäonnistuu ensimmäisessä, eikä saman kokoonpanon muuttaminen sanomaan proto tcp luo toista kuuntelijaa. Direktiivi valitsee yhden kuljetuksen yhdelle prosessille. Kaikki muu seuraa tästä rajoituksesta.
Joko ajat useampaa kuin yhtä prosessia tai ajat versiota, joka voi sitoa useita pistokkeita kerralla.
Ennen 2.7:ää yksi prosessi sitoo yhden kuljetuksen
Yhteisöversion OpenVPN sitoo pistokkeen, jonka proto kuvaa, ja tämä direktiivi valitsee yhden kuljetuksen instanssille. TCP ja UDP ovat erillisiä pinoja, joten sama porttinumero voi olla molempien käytössä samaan aikaan, mutta ei yhden prosessin. Siksi 2.6-sarja antaa yhden kuljetuksen demonia kohden. OpenVPN 2.7 poisti tämän rajoituksen palvelimilta, jotka voivat sitoa useita pistokkeita useiden --local kautta yhdessä prosessissa.
Tarkista versio ennen kuin suunnittelet kummankaan vastauksen varaan, koska 2.7:n järjestely on erilainen toimintamalli, jolla on oma kokoonpanosyntaksinsa. Versiolle 2.6 kirjoitettu opas kuvaa kaksi prosessia, vaikka ei sanoisi sitä.
Kolme tapaa ajaa kahta instanssia
TAP-rajapinnoilla aja yksi instanssi kuljetusta kohden ja sillaa isännän kaksi tap-laitetta. Molemmat asiakasjoukot päätyvät samaan lähetysalueeseen, mikä antaa yhden osoitealtaan kattaa ne ja pitää lähetyksestä riippuvat protokollat toiminnassa. TUN:n kanssa sillausta ei ole, joten yksinkertaisin jako antaa kullekin instanssille oman aliverkkonsa ja jättää reitityksen pitämään kaksi asiakasjoukkoa erillään. Kolmas vaihtoehto säilyttää yhden altaan siten, että kukin instanssi kutsuu learn-address -skriptiä, joka asentaa asiakkaalle /32-reitin kyseisen instanssin laitteen kautta.
Juuri tätä kolmatta järjestelyä ihmiset pyytävät ja juuri se vaatii eniten huolellisuutta, koska skriptistä tulee osa datapolkua ja sen on käsiteltävä lisäys-, päivitys- ja poistotapahtumat oikein.
| 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 |
Pidä kaksi instanssia erillään
Kukin instanssi tarvitsee myös erillisen portin tai osoitteen, erillisen tilatiedoston ja erillisen lokikohteen. Kaksi demonia, jotka kirjoittavat samaan tilatiedostoon, tuottavat tulosteen, jota ei voi lukea häiriön aikana, ja juuri silloin sitä tarvitset. Jos toinen instanssi sitoo tietyn osoitteen, sen osoitteen on oltava isännässä prosessin käynnistyessä; muuten se poistuu sidontavirheeseen ennen kuin sanoo mitään avaimista.
Nimeä yksiköt ja profiilit niin, että kuljetus näkyy tiedostonimestä . Seuraavan operaattorin ei pitäisi joutua avaamaan kokoonpanoa selvittääkseen, kumpi on TCP.
Sovita profiili kuuntelijaan
Palvelin, joka ajaa proto tcp , odottaa asiakasprofiilia, jossa on proto tcp-client , ja profiili, joka yhä kantaa proto udp , törmää tähän kuuntelijaan aikakatkaisulla ilman virhettä, johon käyttäjä voisi reagoida . Pidä kaksi profiilia, jos käyttöönotto tarjoaa molemmat kuljetukset, ja merkitse ne niin, että tuki näkee, kumpaa kokeiltiin. Pelkkä porttinumero ei kuvaa kuljetusta.
Palomuurin säännöt noudattavat samaa jakoa: UDP 1194:n sääntö ei kerro mitään TCP 1194:stä, eikä yhden osoitteen sääntö kata toista kuuntelijaa.
Lue ensin palvelimen näkymä
Aloita palvelimella komennolla ss -lntup ja varmista, että sekä TCP- että UDP-kuuntelija ilmestyvät. Yhdistä sitten yksi asiakas kumpaakin lajia ja tarkista tilarivi kahdesta eri osoitteella olevasta merkinnästä. Jos pistokkeet ovat olemassa eikä asiakas saavu, polku tai palomuuri hylkii paketteja ennen kuin demoni näkee ne.
Pistoke, joka ei koskaan ilmesty, on kokoonpano- tai sidontaongelma, ja pistoke, joka ilmestyy mutta ei koskaan kirjaa yhteyttä, on suodatusongelma. Asiakkaan puolelta ne näyttävät samoilta, siksi palvelimen oma näkymä tulee ensin. Muista, että TCP kantaa jonon pään estoa, joten sen tarjoaminen on tavoitettavuustoimi, ei päivitys asiakkaille, joilla on puhdas UDP-polku.