Jedan Pi, dvije OpenVPN instance: šta čita svaka jedinica
Dva OpenVPN demona na jednom Pi čitaju različite konfiguracijske datoteke i izlaze kroz različite kuke. Mapirajte svaku instancu, pa odvojeno testirajte putanju korisnog tereta.
Prebrojte procese OpenVPN prije nego što dirnete profil. Pi koji prima roaming korisnike i istovremeno se povezuje na upstream servis pokreće dva demona, a svaki od njih čita konfiguracijsku datoteku koju bira ime instance koje ste unijeli. Zatim pakirani predlošci daju svakom demonu vlastiti radni direktorij, vlastitu datoteku statusa izvršavanja i vlastiti tunelski uređaj. Ako to razdvajanje pogriješite, potrošit ćete večer mijenjajući ispravnu postavku u datoteci koju proces koji radi nikada ne otvara.
Svako ime instance bira vlastitu datoteku
U datotekama jedinica koje dolaze s OpenVPN 2.6, početni argumenti nose rezervirano mjesto za instancu koje se popunjava tekstom nakon znaka @. Predložak za server radi iz konfiguracijskog direktorija servera i svoj argument razrješava prema %i.conf tamo, dok predložak za klijenta čini isto iz klijentskog direktorija. Tako [email protected] čita admits.conf u direktoriju servera, a [email protected] čita uplink.conf u klijentskom direktoriju, i nijedno ime nema nikakvo značenje u drugom direktoriju.
Potvrdite mapiranje na samom stroju umjesto da pretpostavljate da je paket zadržao upstream zadane vrijednosti. Dopuna distribucije smije izravno zamijeniti radni direktorij ili argument konfiguracije.
systemctl cat [email protected]
systemctl cat [email protected]Pročitajte redak WorkingDirectory i argument konfiguracije u tom izlazu, jer omogućena jedinica je jedino što odlučuje koja se datoteka učitava. Dopuna koja dodaje --config na ExecStart pobjeđuje predložak čak i kada putanja predloška izgleda ispravno. Zatražite putanje fragmenta i dopune kada želite znati je li na snazi lokalno nadjačavanje. Ako se obje uloge razrješavaju u jednu datoteku, imate jedan proces koji pokušava biti i server i klijent, a kasnija opcija u toj datoteci tiho pobjeđuje.
Lokalni promet i proslijeđeni teret pogađaju različite kuke
Šifrirana veza servera sa svakim roaming korisnikom stvara se na samom Pi, pa njegovi vanjski odgovori izlaze kroz lokalnu izlaznu kuku. Veza klijenta s njegovim upstream parom također je lokalno stvoreni izlaz, iako doseže udaljenu mrežu. Proslijeđeni teret je treća kategorija, a kernel ga uspoređuje tek nakon što je već odabrao izlazni uređaj 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 koje uspoređuje izlazno sučelje unutar lanca prosljeđivanja može dopustiti ili odbaciti paket koji je usmjeravanje već dodijelilo tom sučelju, ali nikada ne bira sučelje. Kada jedan host završava jedan tunel i započinje drugi, politika koja šalje korisnički teret u upstream tunel i politika koja štiti vlastite šifrirane odgovore Pi zasebne su odluke. Slučajno završe na istoj fizičkoj mrežnoj kartici, zato se brkaju.
Ta razlika objašnjava čest poluneuspjeh. Korisnici se povežu, rukovanje se dovrši, a njihov promet ipak izlazi na pogrešnu stranu, jer je rukovanje bilo lokalno, a teret proslijeđen i samo je jedno od to dvoje ikada testirano.
Uvezena ruta može progutati odgovore vašim korisnicima
Sigurnosna postavka klijentskog profila odlučuje što upstream smije gurnuti u Pi-ovu tablicu usmjeravanja, a široko preusmjeravanje je opcija koja radni host s dvije uloge pretvara u pokvareni. Ako gurnuta ruta pokriva javne adrese roaming korisnika, odgovori koje server stvara prema njima mogu slijediti novu rutu u upstream tunel umjesto da izađu kroz donji sloj. Ljudi često potvrde da tunel do pružatelja još radi i tu stanu, jer je taj promet vlastiti transport tunela i nastavlja teći dok se sve ostalo ponaša pogrešno.
Politika temeljena na izvoru ili oznaci način je da dva toka ostanu odvojeni. OpenVPN-ova Linux opcija oznake označava vlastite šifrirane pakete demona vatrozidnom oznakom, koju pravilo usmjeravanja zatim može poslati u namjensku tablicu. Izvorne adrese rade jednako dobro kada vanjski odgovori servera uvijek izlaze s jedne adrese donjeg sloja. Svaki pristup treba valjane rute u tablici koju odabere i iznimku za krajnju točku pružatelja, inače se sam tunel prestaje podizati.
Pitajte kernel kojim bi putem odgovor stvarno išao prije nego što napišete bilo koje pravilo. Adrese u nastavku rezervirana su mjesta za adresu donjeg sloja Pi i javnu adresu jednog roaming korisnika.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Provjerite razdvajanje, pa zaustavite po jednu ulogu
Testirajte tri toka odvojeno, jer uspješno rukovanje ništa ne dokazuje o druga dva. Prihvatite novu dolaznu vezu, pošaljite jednu dopuštenu aplikaciju kroz upstream izlaz i potvrdite da oba procesa još uvijek dosežu svoje parove.
Zatim zaustavite klijentsku ulogu i promatrajte što serverska uloga zadržava. To je najjeftiniji način da pronađete pravilo rute ili oznake koje je bilo namijenjeno jednoj instanci, a primijenjeno na obje.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerOno što želite vidjeti je da je slušatelj još vezan, tunelski uređaj još prisutan i dnevnik bez novih pogrešaka dok je klijentska uloga isključena. Ako zaustavljanje klijenta presiječe i serverove odgovore postojećim korisnicima, dvije uloge dijele nešto što je trebalo biti ograničeno na jednu od njih. Zabilježite koja je instanca, koja konfiguracijska datoteka i koji vlasnik toka dotaknut svakom promjenom, jer će sljedeća osoba koja bude otklanjala pogreške na ovom hostu inače ponoviti isto otkriće od nule.