En Pi, dve instanci OpenVPN: kaj bere vsaka enota
Dva demona OpenVPN na enem Pi bereta različne konfiguracijske datoteke in izhajata skozi različne kavlje. Preslikajte vsako instanco, nato ločeno preizkusite pot tovora.
Preštejte procese OpenVPN, preden se dotaknete profila. Pi, ki sprejema gostujoče uporabnike in hkrati kliče storitev na višji ravni, izvaja dva demona, in vsak od njiju bere konfiguracijsko datoteko, ki jo izbere ime instance, ki ste ga vtipkali. Predloge paketa nato vsakemu demonu dodelijo lastno delovno mapo, lastno datoteko stanja izvajanja in lastno tunelsko napravo. Če to delitev naredite napačno, boste večer preživeli ob spreminjanju pravilne nastavitve v datoteki, ki je tekoči proces nikoli ne odpre.
Vsako ime instance izbere svojo datoteko
V enotnih datotekah, ki jih prinaša OpenVPN 2.6, zagonski argumenti nosijo nadomestno mesto instance, ki se napolni z besedilom za znakom @. Predloga strežnika teče iz konfiguracijske mape strežnika in svoj argument razreši glede na tamkajšnji %i.conf, predloga odjemalca pa stori isto iz mape odjemalca. Zato [email protected] bere admits.conf v mapi strežnika, [email protected] pa bere uplink.conf v mapi odjemalca, in nobeno od teh imen nima nobenega pomena v drugi mapi.
Preverite preslikavo na samem stroju, namesto da predpostavljate, da je paket obdržal privzete vrednosti. Drop-in distribucije lahko povsem zamenja delovno mapo ali konfiguracijski argument.
systemctl cat [email protected]
systemctl cat [email protected]Preberite vrstico WorkingDirectory in konfiguracijski argument v tem izhodu, ker samo omogočena enota odloči, katera datoteka se naloži. Drop-in, ki doda --config k ExecStart, premaga predlogo tudi takrat, ko je pot predloge videti pravilna. Vprašajte za poti fragmentov in drop-inov, ko želite vedeti, ali je v igri lokalno prepisovanje. Če se obe vlogi razrešita v eno datoteko, imate en proces, ki poskuša biti strežnik in odjemalec hkrati, in poznejša možnost v tej datoteki tiho zmaga.
Lokalni prenos in posredovani tovor zadeneta različne kavlje
Šifrirana povezava strežnika z vsakim gostujočim uporabnikom se ustvari na samem Pi, zato njeni zunanji odgovori izhajajo skozi lokalni izhodni kavelj. Povezava odjemalca z njegovim partnerjem na višji ravni je prav tako lokalno ustvarjen izhod, čeprav doseže oddaljeno omrežje. Posredovani tovor je tretja kategorija, in jedro ga uskladi šele potem, ko je že izbralo izhodno napravo za paket.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Pravilo, ki se v forward verigi ujema z izhodnim vmesnikom, lahko dovoli ali zavrže paket, ki ga je usmerjanje že dodelilo temu vmesniku, vendar nikoli ne izbere vmesnika. Ko en gostitelj konča en tunel in začne drugega, sta politika, ki pošilja uporabniški tovor v tunel na višji ravni, in politika, ki ščiti lastne šifrirane odgovore Pi, dve ločeni odločitvi. Po naključju pristaneta na isti fizični NIC, zato ju zamenjujejo.
Ta razlika pojasnjuje pogosto polovično okvaro. Uporabniki se povežejo, rokovanje se dokonča, njihov promet pa vseeno odide po napačni poti, ker je bilo rokovanje lokalno, tovor pa posredovan in preizkušeno je bilo le eno od dveh.
Uvožena pot lahko pogoltne odgovore vašim uporabnikom
Varnostna nastavitev profila odjemalca odloči, kaj lahko višja raven potisne v usmerjevalno tabelo Pi, in široko preusmerjanje je možnost, ki delujočega gostitelja z dvojno vlogo spremeni v pokvarjenega. Če potisnjena pot pokriva javne naslove gostujočih uporabnikov, lahko odgovori, ki jih strežnik ustvari zanje, sledijo novi poti v tunel na višji ravni, namesto da bi izšli skozi spodnjo plast. Ljudje pogosto potrdijo, da tunel do ponudnika še deluje, in se tam ustavijo, ker je ta promet lastni prevoz tunela in teče naprej, medtem ko se vse drugo obnaša napačno.
Politika, ki temelji na viru ali oznaki mark, je način, kako dva toka ostaneta ločena. Možnost mark v Linuxu pri OpenVPN označi lastne šifrirane pakete demona z oznako požarnega zidu, ki jo lahko usmerjevalno pravilo nato pošlje v namensko tabelo. Izvorni naslovi delujejo prav tako dobro, ko zunanji odgovori strežnika vedno izhajajo z enega naslova spodnje plasti. Oba pristopa potrebujeta veljavne poti v tabeli, ki jo izbereta, in izjemo za končno točko ponudnika, sicer se sam tunel ne dvigne več.
Preden napišete katero koli pravilo, vprašajte jedro, po kateri poti bi odgovor zares šel. Naslovi spodaj so nadomestna mesta za naslov spodnje plasti Pi in javni naslov enega gostujočega uporabnika.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Preverite delitev, nato ustavite eno vlogo naenkrat
Preizkusite tri toke ločeno, ker uspešno rokovanje ne dokaže ničesar o drugih dveh. Sprejmite novo vhodno povezavo, pošljite eno dovoljeno aplikacijo skozi izhod na višji ravni in potrdite, da oba procesa še vedno dosežeta svoja partnerja.
Nato ustavite vlogo odjemalca in opazujte, kaj obdrži vloga strežnika. To je najcenejši način, da najdete pravilo poti ali oznake mark, ki je bilo namenjeno eni instanci in uporabljeno za obe.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerŽelite videti, da je poslušalec še vedno vezan, tunelska naprava še vedno prisotna in dnevnik brez novih napak, medtem ko je vloga odjemalca ustavljena. Če ustavitev odjemalca prekine tudi odgovore strežnika obstoječim uporabnikom, obe vlogi delita nekaj, kar bi moralo biti omejeno na eno od njiju. Zabeležite, katere instance, katere konfiguracijske datoteke in katerega lastnika toka se je dotaknila vsaka sprememba, ker bo sicer naslednja oseba, ki bo razhroščevala tega gostitelja, isto odkritje ponovila od začetka.