Strežnik in odjemalec OpenVPN na istem gostitelju: zakaj odjemalci odpadejo

Dodajte profil odjemalca v stroj, na katerem že teče strežnik VPN, in prva žrtev bo prvotna storitev. Novi tunel se morda nikoli ne vzpostavi, ali pa se dvigne, medtem ko obstoječi odjemalci strežnika tiho prenehajo prejemati odgovore. Dve koliziji dajeta oba izida: nabor tunelov, ki je že v uporabi, in privzeta pot, ki jo namesti nova polovica odjemalca in pokriva celotno tabelo. Nobena ne ustvari sporočila o napaki OpenVPN, zato se okvara bere kot težava strežnika.

En stroj, dve vlogi in dva nezdružljiva odgovora o tem, kam naj gredo odgovori.

Isti nabor, dva strežnika: kdo zmaga

Vsak primerek strežnika potrebuje svojo tunelsko podomrežje. Kopiranje vrstice, kot je server 10.8.0.0 255.255.255.0, v drugo konfiguracijo da obema primerkoma isto predpono, izid pa je bodisi zavrnitev zagona bodisi tiha tekma, v kateri odjemalci enega strežnika dobijo naslove, ki jih drugi prav tako šteje za svoje. Različna vrata UDP in različna imena naprav ne pomagajo, ker nobeno od obeh ne posega v naslovni prostor. Spremenite drugi nabor in ga spremenite povsod, kjer ga poti omenjajo.

Naštejte, kaj je aktivno, preden urejate: ip -4 addr show našteje tunelske naprave, ss -lunp našteje poslušalce, systemctl list-units pa poimenuje enote. En pogled na naslove tunelov odloči, ali se nabori prekrivajo.

Kaj profil odjemalca doda tabeli

Polovica odjemalca zapiše poti takoj po povezavi. redirect-gateway def1 razdeli privzeto pot na 0.0.0.0/1 plus 128.0.0.0/1, obe usmerjeni skozi novo napravo, skupaj s potjo do gostitelja oddaljenega strežnika, ki je namerno pripeta na fizični vmesnik. Ta pripetost obstaja zato, da tunel ohrani pot za svoj lastni promet. Vse ostalo, vključno z odgovori, ki jih lokalni strežnik dolguje svojim odjemalcem, zdaj sledi novi privzeti poti in odide skozi oddaljeno povezavo.

Druga kolizija torej ni pokvarjen tunel. To je delujoč tunel na napačnem mestu v tabeli.

Trije načini, kako vloge ločiti

Najmanj invazivna popravek obdrži privzeto pot zunaj profila odjemalca: route-nopull plus izrecne vrstice route za oddaljene predpone, tako da se lokalna tabela spremeni le tam, kjer ste zahtevali. Naslednji korak je pravilo politike, ki izvzame lokalno tunelsko podomrežje in odgovorom lokalnim odjemalcem omogoči, da odidejo skozi vmesnik, po katerem so prišli, tudi ko privzeta pot obstaja. Najbolj temeljito je ločeno imensko prostorstvo omrežja za vlogo odjemalca, ki skupno tabelo povsem odstrani in zahteva vzdrževanje drugega usmerjevalnega konteksta.

Ne glede na pot mora izjema poimenovati lokalno tunelsko podomrežje in ne LAN. Odgovor, ki ga pošlje lokalni strežnik, ima za cilj naslov tunela, zato se izjema v obliki LAN nikoli ne ujema z njim.

Kateri od obeh primerkov je kriv

Ustavite primerek odjemalca in znova preizkusite prvotne odjemalce. Takojšnja obnovitev pomeni usmerjanje, ne strežnik. Vrnite odjemalca in sledite enemu odgovoru s ip route get, ki mu daste tako izvorni kot ciljni naslov, kar pokaže pot, ki bi jo izbralo jedro, nato pa opazujte vmesnik, ki ga paketi zares uporabljajo, s tcpdump -ni any port 1194. Statusna datoteka strežnika, ki se piše vsakih nekaj sekund prek direktive status, vsebuje seznam povezanih odjemalcev in števce bajtov v obeh smereh.

Berite te števce enega proti drugemu. Promet, ki odide in se nikoli ne vrne, je odgovor o usmerjanju, ne težava s tresenjem rok.