Du servaj adresoj sur unu OpenVPN-kliento: iroute kaj lo

La aplikaĵo respondas sur sia tunela adreso, kaj la adreso, kiun vi dokumentis por ĝi, iras nenie. Nenio en la protokolo de OpenVPN plendas, la kunulo montriĝas konektita, kaj la hubo listigas precize unu klienton. La manko estas, ke dua adreso sur kliento estas du apartaj faktoj: la gastiganto devas posedi ĝin, kaj la hubo devas scii, kiu kunulo posedas ĝin. Traktu unu sen la alia kaj la trafiko aŭ mortas ĉe la hubo aŭ alvenas sen itinero hejmen.

La kaŝnomo estas loka, la posedo estas malproksima

Tunela adreso estas interkonsentata, do ambaŭ flankoj lernas ĝin dum la manpremo. Plia serva adreso tute ne estas interkonsentata, kaj tial aldoni ĝin mem ne ŝanĝas ion ĉe la hubo. La kliento povas posedi la adreson tuj, kaj la servilo ankoraŭ sendos tiun trafikon laŭ sia defaŭlta vojo aŭ forĵetos ĝin. Du rikordoj devas esti kreitaj, en du malsamaj lokoj.

Ĉe la kliento la adreso apartenas al la gastiganto, kaj loopback estas la natura hejmo por serva identeco, kiu neniam aperu sur fizika ligo. Ĉe la hubo la kunulo-al-prefiksa mapado estas aparta deklaro, kiun legas nur la servilo. Neniu rikordo implicas la alian.

Tenu la du intervalojn apartaj ankaŭ en viaj notoj. Adresoj en ekzemplo estas dokumentaj valoroj, kaj koincidigi ilin kun reala LAN estas la plej rapida maniero igi funkciantan agordon aspekti rompita.

Aldonu la adreson ĉe la kliento daŭre

Metu la servan adreson sur loopback kun gastiganta prefikso, por ke la gastiganto traktu ĝin kiel lokan enigon anstataŭ kiel subreton por atingi. ip address add 10.66.0.10/32 dev lo faras tion por unu adreso, kaj ripeti la komandon por dua adreso modeligas du servojn.

Rulu tion kiel unufojan teston, poste movu ĝin en tion, kio posedas la retan agordon de la gastiganto, ĉar aldono dum plenumo malaperas ĉe restartigo kaj duplikatoj amasiĝas inter rekonektoj. systemd-unuo ordigita post la reto estas unu eblo, kaj distribua retadministrilo estas alia. Kion ajn vi elektas, la adreso devas ekzisti antaŭ ol la aplikaĵo ligiĝas, alie la servo ekfunkcias sur la malĝusta ingo. Kontrolu per ip address show dev lo post restartigo anstataŭ post la mana komando.

Ligado estas decido aparta de adresado. Aplikaĵo, kiu aŭskultas ĉiun adreson, akceptas trafikon sur interfacoj, kiujn vi neniam intencis, do direktu ĝin al la specifa serva adreso. Tiam la loka eniga politiko havas ion precizan por kongrui.

Postulu ĝin en la CCD-dosiero, kiun la hubo efektive legas

Ĉe la servilo la poseddeklaro iras en la dosieron por kliento elektitan de la aŭtentikigita komuna nomo, ene de la dosierujo nomita de client-config-dir. La linio estas iroute 10.66.0.10 255.255.255.255, po unu por adreso, kaj ĝi diras al la servilo, kiu kunulo ricevu trafikon por tiu celo.

Du detaloj rompas tion silente. La dosiernomo devas kongrui kun la nomo, kiun la servilo efektive uzas, kiu malsamas kiam username-as-common-name estas en ludo. Kaj iroute efikas nur en TUN-reĝimo kun agordita klienta agorda dosierujo, do la sama linio faras nenion en ponta deplojo. Aldonu liniojn al la ekzistanta dosiero anstataŭ anstataŭigi ĝin, ĉar ĝi eble jam portas fiksan adreson aŭ push-opciojn. La OpenVPN 2.6 referenco dokumentas kaj la dosierujon kaj la posedan direktivon.

La propra kerno de la hubo ankaŭ bezonas vojon al tiuj celoj, por ke loke generita trafiko eniru la tunelan procezon. route 10.66.0.10 255.255.255.255 en la servila agordo kovras trafikon, kiun la servilo mem originas, dum aliaj klientoj bezonas push "route 10.66.0.10 255.255.255.255" por mem lerni la celon.

Itinera kaj aŭtoriga administrado restas apartaj. Puŝita itinero diras al kliento, kien sendi pakaĵojn, kaj donas nenion; la servo ankoraŭ devas akcepti la alvokanton laŭ siaj propraj kondiĉoj.

Kontrolu la enigan politikon kaj la respondon vojon

Pakaĵo adresita al la kaŝnomo alvenas al la posedanta gastiganto kiel loka enigo, do la demando estas, ĉu la loka fajroŝirmilo permesas tiun fonton kaj pordon. Permesu la specifan servan pordon el la VPN-fonta intervalo anstataŭ malfermi la tutan adreson.

Respondoj bezonas vojon reen al la alvokanto. Por alvokanto en la normala tunela naĝejo tiu vojo jam ekzistas, ĉar la tunela aparato portas ĝin. Alvokanto malantaŭ alia itinera reto bezonas ankaŭ la returnan itineron de tiu reto, kaj ĉi tie malsimetriaj agordoj perdas pakaĵojn.

Atentu duan aŭskultanton sur la sama pordo ligitan al alia adreso, ĉar la kerno liveras al kiu ajn ingo kongruas, kaj la rezultoj aspektas hazardaj. Kontrolu per ss -lntp kaj konfirmu, ke la ligita adreso estas la serva kaŝnomo. Fonto-NAT ne necesas ĉi tie, kaj aldoni ĝin kaŝas la identecon de la alvokanto, de kiu viaj protokoloj dependas.

Testu adresojn kaj posedon aparte

Testu en du paŝoj. Unue konfirmu, ke la posedanta gastiganto povas atingi la servon sur sia kaŝnomo de si mem, kio apartigas ligadajn kaj fajroŝirmilajn problemojn de itinumado. Poste testu de reala VPN-alvokanto uzante la propran aŭtentikigon de la aplikaĵo. Kiam la unua sukcesas kaj la dua malsukcesas, la mankanta peco estas ĉe la huba flanko.

Kontrolu ankaŭ la malsukcesajn reĝimojn, kiuj postvivas konekton: la kaŝnomo restas asignita kiam la tunelo estas malsupre, kaj la hubo konservas sian itineron kiam la kunulo forestas. Neniu objekto sola pruvas, ke la servo estas atingebla, kaj tial la dupaŝa testo venkas unu pingon de tekkomputilo.