Ĉu WireGuard-kliento ne povas atingi OpenVPN-klienton?

Ambaŭ tuneloj konektiĝas, ĉiu kliento povas atingi la pordegon, kaj en la momento, kiam unu provas la adreson de la alia, la pakaĵoj malaperas. Nenio malĝustas en iu ajn el la du manpremoj, kaj neniu kvanto da reeldonitaj ŝlosiloj tion ŝanĝas. La pordego portas ordinarajn neĉifritajn IP-pakaĵojn inter du el siaj propraj interfacoj, do la protokoloj neniam bezonas kompreni unu la alian; kion ili bezonas, estas tri aferoj, kiujn neniu manpremo donas. Cela kovrado ĉe la origina kliento, fonta posedo ĉe la pordego kaj reena vojo ĉe la malproksima flanko. La simptomo samas por ĉiuj tri, kaj tial ili diagnoziĝas kune.

La simptomo mankas unu pecon samtempe

Ĉi tiu dezajno uzas WireGuard-basenon 10.71.0.0/24 sur wg1 kaj OpenVPN-basenon 10.72.0.0/24 sur tun1, ambaŭ finiĝantaj ĉe unu pordego. La peto sub testo iras de 10.71.0.5 al HTTPS ĉe 10.72.0.30. Ĉiu paŝo sube temas pri tiu sola fluo. Ĉiu kontrolo havas malsaman malsukcesan subskribon, kvankam la uzanto spertas ilin same, kaj kutime mankas nur unu el la tri samtempe.

Komencu per konfirmo, ke ambaŭ basenoj vere estas sur ĉi tiu pordego kaj ke plusendado estas ŝaltita en la nomspaco, kie loĝas la tuneloj. Pordego, kiu finas ambaŭ protokolojn en malsamaj nomspacoj, plusendas nenion inter ili, kaj indas ekskludi tion antaŭ ol legi ajnan agordon de samtavolo.

Etendu la celan kovradon de la spoko

Ĉe la WireGuard-kliento, la ekzistanta samtavola ero devas elekti la pordegon por la OpenVPN-celo, kio signifas, ke la cela prefikso devas aperi en la permesita listo de tiu samtavolo. Aldoni ĝin ne kreas duan tunelon; ĝi ŝanĝas, kiun samtavolon la kliento elektas, kiam ĝi serĉas tiun adreson, kaj kun wg-quick la vojo kutime sekvas la liston aŭtomate.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lasu la verajn liniojn de ŝlosilo kaj finpunkto netuŝitaj, kaj memoru, ke administranto uzanta Table = off tute ne prenas vojon el ĉi tiu listo. En tiu kazo la sama prefikso devas esti instalita en la sistema voj-tabelo de tiu, kiu posedas ĝin, kaj mankanta vojo tie aspektas precize kiel mankanta permesita prefikso.

Konservu la fontan posedon ĉe la pordego

La samtavola ero de ĉi tiu kliento ĉe la pordego devus plu posedi precize la fontan adreson de tiu kliento. Permesitaj adresoj kontroliĝas en ambaŭ direktoj: ili elektas samtavolon por elira trafiko kaj ili validigas, ke la fonto de envenanta pakaĵo apartenas al la samtavolo, kiu sendis ĝin. Meti la OpenVPN-basenon en la eron de la spoko, ĉar la spoko volas atingi ĝin, estas la eraro, kiu direktas trafikon al la malĝusta partoprenanto.

AllowedIPs = 10.71.0.5/32

Legu tiun eron kiel deklaron pri posedo, ne kiel vojigan komforton. Ĉio alia, kion la kliento devas atingi, apartenas al la cela listo de la kliento, ne al la imago de la pordego pri tio, kion ĉi tiu samtavolo rajtas sendi.

Donu al la OpenVPN-flanko revenan vojon

La celo nun bezonas vojon reen al la WireGuard-fonto, kaj por klientoj el baseno tio kutime alvenas kiel puŝita vojo de la OpenVPN-servilo. Puŝu ĝin nur al klientoj, kiuj devus havi ĝin, kaj konfirmu ĉe la kliento, ke ĝi estis akceptita, anstataŭ supozi, ke la direktivo aplikiĝis.

push "route 10.71.0.0 255.255.255.0"

Vojdisvastigo ne estas rajtigo. Kiam la celo staras malantaŭ alia OpenVPN-kliento anstataŭ en la baseno, la propra LAN-posedo de tiu kliento kaj ĝiaj plusendaj postuloj aliĝas al la dezajno, kaj la puŝita vojo estas nur la unua duono. Reformulu la postulon kiel grafeon antaŭ ol aldoni direktivojn: kiu nodo posedas kiun prefikson, kaj kiu nodo plusendas al ĝi.

Permesu ĝuste tiun servon, kiun vi intencis permesi

Kun ŝaltita plusendado kaj ambaŭ basenoj vojigeblaj, la resto estas demando pri politiko. Skribu la regulon por la konkreta fluo anstataŭ por la interfaca paro ĝenerale, antaŭrigardu ĝin antaŭ ol apliki ĝin, kaj konservu la statan revenan vojon, por ke respondoj ne blokiĝu kiel novaj konektoj. Seka rulo kostas nenion kaj montras precize, kio aldoniĝus.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Ĉi tiuj estas plusendaj reguloj, apartaj de la aŭskultaj reguloj de la pordego por la du VPN-servoj. Malfermi la eksterajn UDP-pordojn ne rajtigas la internan peton, kaj rajtigi la internan peton ne postulas senliman SSH al la pordego nek defaŭltan permeson ĉe plusendado. Ankaŭ la propra fajroŝirmilo de la celo kaj ĝia aŭskulta adreso devas kongrui, ĉar servo ligita al loopback rifuzas eĉ la plej zorgeme vojigitan pakaĵon. Politiko, kiu kovras nur unu direkton de la interparolo, kutime malsukcesas per sukcesa peto kaj silenta respondo, kio estas la plej konfuza el la tri rezultoj.

Reciprokaj vojoj kutime signifas, ke fonta traduko ne necesas, kio konservas la WireGuard-adreson ĉe la celo kaj igas protokolojn legeblaj. Ne aldonu tutan maskadon ĉar du protokoloj estas implikitaj, kaj ne forigu ekzistantan tradukan regulon sen scii, kio dependas de ĝi. Poste kontrolu la unuopan fluon de fino al fino, kaj testu ankaŭ unu malpermesitan fonton aŭ pordon: funkcianta manpremo ĉe ĉiu flanko pruvas nek la krucan vojon nek la izoladon.