Dva naslova storitve na enem odjemalcu OpenVPN: iroute in lo

Aplikacija odgovarja na svojem naslovu tunela, naslov, ki ste ga zanjo dokumentirali, pa ne vodi nikamor. Nič v dnevniku OpenVPN se ne pritožuje, partner se prikaže kot povezan, zvezdišče pa navaja natanko enega odjemalca. Vrzel je v tem, da sta drugi naslov na odjemalcu dve ločeni dejstvi: gostitelj ga mora imeti v lasti, zvezdišče pa mora vedeti, kateri partner ga ima. Rešite eno brez drugega in promet bodisi umre na zvezdišču bodisi prispe brez poti domov.

Vzdevek je lokalen, lastništvo je oddaljeno

O naslovu tunela se pogaja, zato ga oba konca spoznata med rokovanjem. O dodatnem naslovu storitve se sploh ne pogaja, zato njegova dodaja sama po sebi na zvezdišču nič ne spremeni. Odjemalec lahko naslov takoj ima, strežnik pa bo ta promet še vedno poslal po svoji privzeti poti ali pa ga zavrgel. Ustvariti je treba dva zapisa na dveh različnih mestih.

Na odjemalcu naslov pripada gostitelju, loopback pa je naravni dom za identiteto storitve, ki se nikoli ne bi smela pojaviti na fizični povezavi. Na zvezdišču je preslikava partnerja v predpono ločena izjava, ki jo bere samo strežnik. Noben zapis ne implicira drugega.

Oba obsega ohranite ločena tudi v svojih zapiskih. Naslovi v primeru so dokumentacijske vrednosti, njihovo prekrivanje z resničnim LAN-om pa je najhitrejša pot, da delujoča nastavitev izgleda pokvarjena.

Dodajte naslov na odjemalcu trajno

Postavite naslov storitve na loopback s predpono gostitelja, da ga gostitelj obravnava kot lokalni vhod in ne kot podomrežje, do katerega je treba priti. ip address add 10.66.0.10/32 dev lo to stori za en naslov, ponovitev ukaza za drugi naslov pa modelira dve storitvi.

Zaženite to kot enkratni test, nato premaknite v tisto, kar ima v lasti omrežno konfiguracijo gostitelja, ker dodatek med izvajanjem izgine ob ponovnem zagonu, dvojniki pa se kopičijo med ponovnimi povezavami. Enota systemd, razvrščena za omrežjem, je ena možnost, omrežni upravitelj distribucije pa druga. Karkoli izberete, naslov mora obstajati preden se aplikacija veže, sicer storitev vstane na napačnem vtiču. Preverite s ip address show dev lo po ponovnem zagonu in ne po ročnem ukazu.

Vezava je odločitev, ločena od naslavljanja. Aplikacija, ki posluša na vsakem naslovu, sprejema promet na vmesnikih, ki jih niste nikoli nameravali, zato jo usmerite na določen naslov storitve. Takrat ima lokalna vhodna politika kaj natančnega za ujemanje.

Zahtevajte jo v datoteki CCD, ki jo zvezdišče zares bere

Na strežniku izjava o lastništvu gre v datoteko posameznega odjemalca, ki jo izbere overjeno skupno ime, znotraj imenika, ki ga navaja client-config-dir. Vrstica je iroute 10.66.0.10 255.255.255.255, ena na naslov, in strežniku pove, kateri partner naj prejema promet za ta cilj.

Dve podrobnosti to tiho pokvarita. Ime datoteke se mora ujemati z imenom, ki ga strežnik zares uporablja, to pa se razlikuje, ko je v igri username-as-common-name. In iroute deluje le v načinu TUN z nastavljenim imenikom konfiguracije odjemalca, zato ista vrstica v mostni namestitvi ne naredi ničesar. Dodajajte vrstice obstoječi datoteki, namesto da jo zamenjate, saj lahko že nosi fiksni naslov ali možnosti push. Referenca OpenVPN 2.6 dokumentira imenik in direktivo o lastništvu.

Tudi lastno jedro zvezdišča potrebuje pot do teh ciljev, da lokalno ustvarjen promet vstopi v proces tunela. route 10.66.0.10 255.255.255.255 v konfiguraciji strežnika pokriva promet, ki ga ustvari strežnik sam, medtem ko drugi odjemalci potrebujejo push "route 10.66.0.10 255.255.255.255", da se cilja naučijo sami.

Usmerjanje in avtorizacija ostaneta ločena. Poslana pot odjemalcu pove, kam pošiljati pakete, in ničesar ne podeli; storitev mora klicatelja še vedno sprejeti pod svojimi pogoji.

Preverite vhodno politiko in povratno pot

Paket, naslovljen na vzdevek, prispe na gostitelja, ki ga ima v lasti, kot lokalni vhod, zato je vprašanje, ali lokalni požarni zid dovoljuje ta vir in vrata. Dovolite določena vrata storitve iz obsega virov VPN, namesto da odprete celoten naslov.

Odgovori potrebujejo pot nazaj do klicatelja. Za klicatelja v običajnem bazenu tunela ta pot že obstaja, ker jo nosi tunelska naprava. Klicatelj za drugim usmerjenim omrežjem potrebuje tudi povratno pot tega omrežja, in tu asimetrične nastavitve izgubljajo pakete.

Pazite na drugega poslušalca na istih vratih, vezanega na drug naslov, ker jedro dostavi tistemu vtiču, ki se ujema, in rezultati izgledajo naključni. Preverite s ss -lntp in potrdite, da je vezani naslov vzdevek storitve. Izvorni NAT tu ni potreben, njegova dodaja pa skrije identiteto klicatelja, od katere so odvisni vaši dnevniki.

Preizkusite naslove in lastništvo ločeno

Preizkusite v dveh korakih. Najprej potrdite, da gostitelj, ki ima naslov v lasti, doseže storitev na svojem vzdevku sam iz sebe, kar loči težave z vezavo in požarnim zidom od usmerjanja. Nato preizkusite s pravega klicatelja VPN z overjanjem same aplikacije. Ko prvi uspe in drugi ne, je manjkajoči del na strani zvezdišča.

Preverite tudi načine okvare, ki preživijo povezavo: vzdevek ostane dodeljen, ko je tunel spuščen, zvezdišče pa obdrži svojo pot, ko partnerja ni. Noben predmet sam ne dokazuje, da je storitev dosegljiva, zato dvostopenjski test premaga en sam ping s prenosnika.