Dvije servisne adrese na jednom OpenVPN klijentu: iroute i lo

Aplikacija odgovara na svojoj adresi tunela, a adresa koju ste za nju dokumentirali ne vodi nikamo. Ništa se u dnevniku OpenVPN ne žali, peer se prikazuje kao povezan, a hub navodi točno jednog klijenta. Praznina je u tome što su druga adresa na klijentu dvije odvojene činjenice: host je mora posjedovati, a hub mora znati koji je peer posjeduje. Riješite jedno bez drugoga i promet ili umire na hubu ili stiže bez puta kući.

Alias je lokalan, vlasništvo je udaljeno

Adresa tunela se pregovara, pa je oba kraja nauče tijekom rukovanja. Dodatna servisna adresa uopće se ne pregovara, zato njezino dodavanje samo po sebi ništa ne mijenja na hubu. Klijent može odmah posjedovati adresu, a poslužitelj će taj promet ipak poslati svojim zadanim putem ili ga odbaciti. Moraju se stvoriti dva zapisa, na dva različita mjesta.

Na klijentu adresa pripada hostu, a loopback je prirodni dom za servisni identitet koji se nikada ne bi trebao pojaviti na fizičkoj vezi. Na hubu je mapiranje peera na prefiks zasebna deklaracija koju čita samo poslužitelj. Nijedan zapis ne podrazumijeva drugi.

Držite dva raspona odvojena i u svojim bilješkama. Adrese u primjeru su dokumentacijske vrijednosti, a njihovo preklapanje sa stvarnim LAN-om najbrži je način da radna postavka izgleda pokvareno.

Dodajte adresu na klijent trajno

Postavite servisnu adresu na loopback s prefiksom hosta, da bi je host tretirao kao lokalni ulaz, a ne kao podmrežu kojoj treba pristupiti. ip address add 10.66.0.10/32 dev lo to radi za jednu adresu, a ponavljanje naredbe za drugu adresu modelira dvije usluge.

Pokrenite to kao jednokratni test, pa premjestite u ono što posjeduje mrežnu konfiguraciju hosta, jer dodatak u vrijeme rada nestaje nakon ponovnog pokretanja, a duplikati se nakupljaju između ponovnih povezivanja. systemd jedinica poredana nakon mreže jedna je opcija, a mrežni upravitelj distribucije druga. Što god odaberete, adresa mora postojati prije nego što se aplikacija veže, inače usluga izlazi na pogrešnom socketu. Provjerite pomoću ip address show dev lo nakon ponovnog pokretanja, a ne nakon ručne naredbe.

Vezivanje je odvojena odluka od adresiranja. Aplikacija koja sluša na svakoj adresi prihvaća promet na sučeljima koja nikada niste namjeravali, zato je usmjerite na konkretnu servisnu adresu. Tada lokalna politika ulaza ima s čime precizno se poklopiti.

Zatražite je u CCD datoteci koju hub zaista čita

Na poslužitelju deklaracija vlasništva ide u datoteku pojedinog klijenta koju bira autentificirano uobičajeno ime, unutar direktorija navedenog pomoću client-config-dir. Redak je iroute 10.66.0.10 255.255.255.255, jedan po adresi, i govori poslužitelju koji peer treba primati promet za to odredište.

Dva detalja to tiho kvare. Ime datoteke mora odgovarati imenu koje poslužitelj zaista koristi, a ono se razlikuje kada je u igri username-as-common-name. I iroute djeluje samo u TUN načinu rada s konfiguriranim direktorijem konfiguracije klijenta, pa isti redak ne radi ništa u mostovnoj implementaciji. Dodajte retke postojećoj datoteci umjesto da je zamijenite, jer ona već može nositi fiksnu adresu ili push opcije. OpenVPN 2.6 referenca dokumentira i direktorij i direktivu vlasništva.

Hubovo vlastito jezgro također treba put do tih odredišta da bi lokalno generirani promet ušao u proces tunela. route 10.66.0.10 255.255.255.255 u konfiguraciji poslužitelja pokriva promet koji poslužitelj stvara, dok drugi klijenti trebaju push "route 10.66.0.10 255.255.255.255" da sami nauče odredište.

Usmjeravanje i autorizacija ostaju odvojeni. Poslana ruta govori klijentu kamo slati pakete i ništa ne daje; usluga i dalje mora prihvatiti pozivatelja pod svojim uvjetima.

Provjerite politiku ulaza i povratni put

Paket upućen aliasu stiže na host koji ga posjeduje kao lokalni ulaz, pa je pitanje dopušta li lokalni firewall taj izvor i port. Dopustite konkretni servisni port iz VPN raspona izvora umjesto da otvorite cijelu adresu.

Odgovori trebaju put natrag do pozivatelja. Za pozivatelja unutar uobičajenog tunelskog bazena taj put već postoji, jer ga nosi tunelski uređaj. Pozivatelj iza druge usmjerene mreže treba i povratnu rutu te mreže, i tu asimetrične postavke gube pakete.

Pazite na drugog slušatelja na istom portu vezanog na drugu adresu, jer jezgra dostavlja onom socketu koji se poklopi i rezultati izgledaju slučajno. Provjerite pomoću ss -lntp i potvrdite da je vezana adresa servisni alias. Izvorni NAT ovdje nije potreban, a njegovo dodavanje skriva identitet pozivatelja o kojem ovise vaši dnevnici.

Testirajte adrese i vlasništvo odvojeno

Testirajte u dva koraka. Prvo potvrdite da host koji posjeduje adresu može dosegnuti uslugu na svom aliasu sa sebe, što odvaja probleme vezivanja i firewala od usmjeravanja. Zatim testirajte s pravog VPN pozivatelja koristeći autentikaciju same aplikacije. Kada prvi prođe a drugi ne, nedostajući dio je na strani huba.

Provjerite i načine kvara koji nadžive vezu: alias ostaje dodijeljen kada je tunel pao, a hub zadržava svoju rutu kada peer nije prisutan. Nijedan objekt sam ne dokazuje da je usluga dostupna, zato dvostepeni test pobjeđuje jedan ping s prijenosnog računala.