Yksi Pi, kaksi OpenVPN-instanssia: mitä kukin yksikkö lukee

Laske OpenVPN-prosessit ennen kuin kosket profiiliin. Pi, joka ottaa vastaan roaming-käyttäjiä ja soittaa myös ylävirran palveluun, ajaa kahta demoneja, ja kukin niistä lukee asetustiedoston, jonka valitsee kirjoittamasi instanssin nimi. Sen jälkeen paketoidut mallit antavat kullekin demonille oman työhakemistonsa, oman ajonaikaisen tilatiedostonsa ja oman tunnelilaitteensa. Jos jaat tämän väärin, vietät illan muuttaen oikeaa asetusta tiedostossa, jota käynnissä oleva prosessi ei koskaan avaa.

Jokainen instanssin nimi valitsee oman tiedostonsa

OpenVPN:n 2.6:n mukana toimitetuissa yksikkötiedostoissa käynnistysargumentit sisältävät instanssin paikkamerkin, joka täytetään merkin @ jälkeisellä tekstillä. Palvelinmalli toimii palvelimen asetushakemistosta ja ratkaisee argumenttinsa %i.conf vasten, kun taas asiakasmalli tekee saman asiakashakemistosta. Niinpä [email protected] lukee admits.conf palvelimen hakemistossa ja [email protected] lukee uplink.conf asiakkaan hakemistossa, eikä kummallakaan nimellä ole merkitystä toisessa hakemistossa.

Vahvista vastaavuus koneella sen sijaan, että olettaisit paketin säilyttäneen ylävirran oletukset. Jakelun lisäosa saa korvata työhakemiston tai asetusargumentin suoraan.

systemctl cat [email protected]
systemctl cat [email protected]

Lue rivi WorkingDirectory ja asetusargumentti siitä tulosteesta, koska käytössä oleva yksikkö on ainoa asia, joka päättää, mikä tiedosto latautuu. Lisäosa, joka liittää --config kohtaan ExecStart, voittaa mallin, vaikka mallin polku näyttäisi oikealta. Kysy fragmentin ja lisäosan polut, kun haluat tietää, onko paikallinen ohitus pelissä. Jos molemmat roolit ratkeavat yhteen tiedostoon, sinulla on yksi prosessi, joka yrittää olla sekä palvelin että asiakas, ja tuon tiedoston myöhempi vaihtoehto voittaa hiljaa.

Paikallinen kuljetus ja edelleen lähetetty hyötykuorma osuvat eri koukkuihin

Palvelimen salattu yhteys jokaiseen roaming-käyttäjään luodaan itse Pi:llä, joten sen ulkoiset vastaukset poistuvat paikallisen lähtökoukun kautta. Asiakkaan yhteys ylävirran vertaiseensa on myös paikallisesti luotu lähtö, vaikka se saavuttaa etäverkon. Edelleen lähetetty hyötykuorma on kolmas luokka, ja ydin sovittaa sen vasta valittuaan paketille lähtevän laitteen.

Sääntö, joka vastaa lähtevää liitäntää edelleenlähetysketjun sisällä, voi sallia tai pudottaa paketin, jonka reititys on jo osoittanut sille liitännälle, mutta se ei koskaan valitse liitäntää. Kun yksi isäntä lopettaa yhden tunnelin ja aloittaa toisen, käyttäjän hyötykuorman ylävirran tunneliin lähettävä käytäntö ja Pi:n omia salattuja vastauksia suojaava käytäntö ovat erillisiä päätöksiä. Ne sattuvat laskeutumaan samalle fyysiselle verkkokortille, minkä vuoksi ne sekoitetaan.

Tämä ero selittää yleisen puolittaisen epäonnistumisen. Käyttäjät yhdistävät, kättely valmistuu, ja liikenne lähtee silti väärään suuntaan, koska kättely oli paikallinen ja hyötykuorma edelleen lähetetty ja vain toista kahdesta oli koskaan testattu.

Tuotu reitti voi niellä vastaukset käyttäjillesi

Asiakasprofiilin turva-asetus päättää, mitä ylävirta saa työntää Pi:n reititystauluun, ja laaja uudelleenohjaus on vaihtoehto, joka muuttaa toimivan kaksoisrooli-isännän rikkinäiseksi. Jos työnnetty reitti kattaa roaming-käyttäjien julkiset osoitteet, palvelimen heille luomat vastaukset voivat seurata uutta reittiä ylävirran tunneliin sen sijaan, että ne poistuisivat aluskerroksen kautta. Ihmiset vahvistavat usein, että tunneli palveluntarjoajalle toimii edelleen, ja pysähtyvät siihen, koska tuo liikenne on tunnelin oma kuljetus ja se jatkaa virtaamistaan, kun kaikki muu käyttäytyy väärin.

Lähde- tai merkkipohjainen käytäntö pitää kaksi virtaa erillään. OpenVPN:n Linuxin merkkivaihtoehto leimaa demonin omat salatut paketit palomuurimerkillä, jonka reitityssääntö voi sitten lähettää omistettuun tauluun. Lähdeosoitteet toimivat yhtä hyvin, kun palvelimen ulkoiset vastaukset lähtevät aina yhdestä aluskerroksen osoitteesta. Kumpikin lähestymistapa tarvitsee kelvolliset reitit valitsemassaan taulussa ja poikkeuksen palveluntarjoajan päätepisteelle, muuten itse tunneli lakkaa nousemasta.

Kysy ytimeltä, minkä polun vastaus todella ottaisi, ennen kuin kirjoitat mitään sääntöä. Alla olevat osoitteet ovat paikkamerkkejä Pi:n aluskerroksen osoitteelle ja yhden roaming-käyttäjän julkiselle osoitteelle.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Vahvista jako ja pysäytä sitten yksi rooli kerrallaan

Testaa kolmea virtaa erikseen, koska toimiva kättely ei todista mitään kahdesta muusta. Ota vastaan uusi saapuva yhteys, lähetä yksi sallittu sovellus ylävirran ulosmenon kautta ja vahvista, että molemmat prosessit saavuttavat edelleen omat vertaisensa.

Pysäytä sitten asiakasrooli ja katso, mitä palvelinrooli säilyttää. Tämä on halvin tapa löytää reitti- tai merkkisääntö, joka oli tarkoitettu yhdelle instanssille ja sovellettiin molempiin.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Haluat nähdä kuuntelijan yhä sidottuna, tunnelilaitteen yhä läsnä ja lokin vapaana uusista virheistä, kun asiakasrooli on alhaalla. Jos asiakkaan pysäyttäminen katkaisee myös palvelimen vastaukset nykyisille käyttäjille, kaksi roolia jakavat jotain, joka olisi pitänyt rajata yhteen niistä. Kirjaa, mitä instanssia, mitä asetustiedostoa ja mitä virran omistajaa kukin muutos koski, koska seuraava tämän isännän virheenkorjaaja toistaa muuten saman löydön nollasta.