Dvije servisne adrese na jednom OpenVPN klijentu: iroute i lo

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

Alijas je lokalni, vlasništvo je udaljeno

Adresa tunela se pregovara, pa je oba kraja nauče tokom rukovanja. Dodatna servisna adresa se uopće ne pregovara, zato njeno dodavanje samo po sebi ništa ne mijenja na hubu. Klijent može odmah posjedovati adresu, a server ć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 nikada ne bi trebao da se pojavi na fizičkoj vezi. Na hubu je mapiranje peera na prefiks zasebna deklaracija koju čita samo server. Nijedan zapis ne podrazumijeva drugi.

Držite dva opsega 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 menadžer distribucije druga. Šta god odaberete, adresa mora postojati prije nego što se aplikacija veže, inače usluga izlazi na pogrešnom soketu. 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 prihvata promet na interfejsima koje nikada niste namjeravali, zato je usmjerite na konkretnu servisnu adresu. Tada lokalna politika ulaza ima s čime precizno da se poklopi.

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

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

Dva detalja to tiho kvare. Ime datoteke mora odgovarati imenu koje server zaista koristi, a ono se razlikuje kada je u igri username-as-common-name. I iroute djeluje samo u TUN režimu s konfiguriranim direktorijem konfiguracije klijenta, pa isti red ne radi ništa u mostovnoj implementaciji. Dodajte redove 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 servera pokriva promet koji server stvara, dok drugi klijenti trebaju push "route 10.66.0.10 255.255.255.255" da sami nauče odredište.

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

Provjerite politiku ulaza i povratni put

Paket upućen alijasu 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 pozivaoca. Za pozivaoca unutar uobičajenog tunelskog bazena taj put već postoji, jer ga nosi tunelski uređaj. Pozivalac iza druge rutirane mreže treba i povratnu rutu te mreže, i tu asimetrične postavke gube pakete.

Pazite na drugog slušaoca na istom portu vezanog na drugu adresu, jer jezgro dostavlja onom soketu koji se poklopi i rezultati izgledaju slučajno. Provjerite pomoću ss -lntp i potvrdite da je vezana adresa servisni alijas. Izvorni NAT ovdje nije potreban, a njegovo dodavanje skriva identitet pozivaoca 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 alijasu sa sebe, što odvaja probleme vezivanja i firewala od rutiranja. Zatim testirajte s pravog VPN pozivaoca 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: alijas 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 laptopa.