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 zatim odvojeno testirajte putanju korisnog tereta.
Prebrojite OpenVPN procese prije nego što dirnete profil. Pi koji prima roaming korisnike i istovremeno poziva uslugu na višem nivou pokreće dva demona, i svaki od njih čita konfiguracijsku datoteku koju bira ime instance koje ste upisali. Predlošci paketa zatim svakom demonu daju vlastiti radni direktorij, vlastitu datoteku stanja izvršavanja i vlastiti tunelski uređaj. Ako ovu podjelu napravite pogrešno, provest ć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, argumenti za pokretanje nose zamjensko mjesto instance koje se popunjava tekstom nakon znaka @. Predložak poslužitelja radi iz konfiguracijskog direktorija poslužitelja i rješava svoj argument prema tamošnjem %i.conf, dok predložak klijenta čini isto iz direktorija klijenta. Zato [email protected] čita admits.conf u direktoriju poslužitelja, a [email protected] čita uplink.conf u direktoriju klijenta, i nijedno od tih imena nema nikakvo značenje u drugom direktoriju.
Potvrdite mapiranje na samom stroju umjesto da pretpostavite da je paket zadržao zadane vrijednosti višeg nivoa. Drop-in distribucije smije u cijelosti zamijeniti radni direktorij ili konfiguracijski argument.
systemctl cat [email protected]
systemctl cat [email protected]Pročitajte redak WorkingDirectory i konfiguracijski argument u tom izlazu, jer samo omogućena jedinica odlučuje koja se datoteka učitava. Drop-in koji dodaje --config na ExecStart pobjeđuje predložak čak i kada putanja predloška izgleda ispravno. Zatražite putanje fragmenata i drop-inova kada želite znati je li na djelu lokalno prepisivanje. Ako se obje uloge rješavaju na jednu datoteku, imate jedan proces koji pokušava biti i poslužitelj i klijent, a kasnija opcija u toj datoteci tiho pobjeđuje.
Lokalni prijevoz i proslijeđeni teret pogađaju različite kuke
Šifrirana veza poslužitelja sa svakim roaming korisnikom stvara se na samom Pi, pa njegovi vanjski odgovori izlaze kroz lokalnu izlaznu kuku. Veza klijenta s njegovim partnerom na višem nivou također je lokalno stvoren izlaz, iako doseže udaljenu mrežu. Proslijeđeni korisni teret treća je kategorija, a jezgra ga uparuje tek nakon što je već odabrala 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 unutar forward lanca odgovara izlaznom sučelju može dopustiti ili odbaciti paket koji je usmjeravanje već dodijelilo tom sučelju, ali nikada ne bira sučelje. Kada jedan host završi jedan tunel i započne drugi, politika koja šalje korisnički teret u tunel višeg nivoa i politika koja štiti vlastite šifrirane odgovore Pi dvije su odvojene odluke. One slučajno završe na istoj fizičkoj NIC, zato se brkaju.
Ta razlika objašnjava čest polovični kvar. Korisnici se povežu, rukovanje se dovrši, a njihov promet i dalje izlazi pogrešnim putem, jer je rukovanje bilo lokalno, a teret proslijeđen i samo je jedno od dvoga ikada testirano.
Uvezena ruta može progutati odgovore vašim korisnicima
Sigurnosna postavka profila klijenta odlučuje što viši nivo smije ugurati u usmjerivačku tablicu Pi, a široko preusmjeravanje je opcija koja funkcionalni host s dvojnom ulogom pretvara u pokvareni. Ako ugurana ruta pokriva javne adrese roaming korisnika, odgovori koje poslužitelj stvara prema njima mogu slijediti novu rutu u tunel višeg nivoa umjesto da izađu kroz donji sloj. Ljudi često potvrde da tunel prema pružatelju još radi i zaustave se na tome, jer je taj promet vlastiti prijevoz tunela i nastavlja teći dok se sve ostalo ponaša pogrešno.
Politika temeljena na izvoru ili mark oznaci način je da dva toka ostanu odvojeni. OpenVPN-ova Linux mark opcija označava vlastite šifrirane pakete demona vatrozidnom oznakom, koju usmjerivačko pravilo zatim može poslati u namjensku tablicu. Izvorne adrese rade jednako dobro kada vanjski odgovori poslužitelja uvijek izlaze s jedne adrese donjeg sloja. Oba pristupa trebaju valjane rute u tablici koju odaberu i iznimku za endpoint pružatelja, inače se sam tunel više ne diže.
Pitajte jezgru kojim bi putem odgovor doista krenuo prije nego što napišete bilo koje pravilo. Adrese ispod zamjenska 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 podjelu, pa zaustavljajte jednu ulogu odjednom
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 izlaz višeg nivoa i potvrdite da oba procesa još dosežu svoje partnere.
Zatim zaustavite ulogu klijenta i promatrajte što uloga poslužitelja zadržava. To je najjeftiniji način da pronađete pravilo rute ili mark 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-pagerŽelite vidjeti da je slušatelj još vezan, tunelski uređaj još prisutan i dnevnik bez novih pogrešaka dok je uloga klijenta zaustavljena. Ako zaustavljanje klijenta prekine i odgovore poslužitelja postojećim korisnicima, dvije uloge dijele nešto što je trebalo biti ograničeno na jednu od njih. Zabilježite koju instancu, koju konfiguracijsku datoteku i kojeg vlasnika toka je svaka promjena dotakla, jer će inače sljedeća osoba koja otklanja pogreške na ovom hostu ponoviti isto otkriće od nule.