Kiel doni al unu testa LAN propran WireGuard-eliron

Tri dezajnoj solvas la saman laboratorian problemon: malgranda LAN devas eliri tra WireGuard-partnero, dum la kluzo mem konservas sian kutiman suprenligon. La tentiga fuŝvojo estas movi la defaŭltan itineron de la enkursigilo en la tunelon, sed tio rompas la proprajn administrajn vojojn de la skatolo kaj ĉion alian, kion ĝi plusendas. La interesa opcio estas politika enkursigado limigita al unu interfaco kaj unu prefikso. Elektu inter ili respondante tri demandojn pri la maŝino, kiun vi vere havas.

Decidu, kie loĝas la eliro

Unua demando: ĉu tiu ĉi gastiganto plusendas por io alia? Dediĉita laboratoria kluzo povas vivi kun plusenda politiko, kiu defaŭlte forĵetas. Enkursigilo kun produktadaj devoj ne povas, kaj meti konkurantan regulon aron super administrata fajroŝirmilo estas ĝuste la maniero, kiel la paneoj estas planataj. Dua: ĉu vi povas posedi du politikajn objektojn kaj ilian ordon trans restarigoj? Tria: ĉu la partnero, kiun vi havas, rajtigas la fontan adreson de via tunelo kaj proponas interretan eliron? Partnero, kiu elmetas nur privatan reton estas alia produkto, kaj neniu loka enkursiga ŝanĝo tion riparas. Se iu ajn respondo estas ne, metu la eliron anstataŭe en nomspacon aŭ en forĵetindan virtualan maŝinon.

Nomspaco aŭ VM kostas memoron kaj donas al vi puran eksplodradiuson. Politika enkursigado kostas du regulojn kaj lasas al vi unu skatolon por sencimigi.

Elektu la eliron, kiu rajtigas vian fonton

Plej multaj fiaskoj en tiu ĉi laboratorio okazas antaŭ ol ekzistas eĉ unu fajroŝirmila regulo. La operatoro de la eliro devas akcepti la fontan adreson, kiun viaj pakoj portas post tradukado, kio en tiu ĉi dezajno estas la tunela adreso anstataŭ la LAN-prefikso. Tial maskado apartenas al la dezajno de la komenco, ne kiel malfrua aldono.

Konfirmu tri aferojn ĉe la operatoro: la partnero rajtigas vian tunelan adreson, ĝi plusendas IPv4 anstataŭ finiĝi ĉe si mem, kaj ĝi aplikas eliran NAT. Sen la unua viaj pakoj alvenas kaj malaperas. Sen la tria ili eliras kun privata fonto kaj mortas ĉe la sekva salto. Poste kontrolu, ke wg-quick ne instalas sian propran defaŭltan itineron, kion malhelpas Table = off; tiu agordo subpremas itineran kreadon, ne la kontrolojn de AllowedIPs de la partnero nek ĝian DNS-traktadon.

Du politikaj objektoj faras la direktadon

Direktado bezonas tabelon kaj regulon. La tabelo tenas du itinerojn: la LAN-prefikson el la LAN-interfaco kaj defaŭltan el la tunelo. La regulo sendas trafikon, kiu alvenas sur la LAN-interfacon kaj portas tiun prefikson, en la tabelon. Uzu la elektilon iif kune kun la fonta kongruo, ĉar la propraj WireGuard-pakoj de la kluzo originas loke kaj neniam kongruas kun envenanta interfaco.

La gardanto venas antaŭ la serĉo, ne post ĝi. Tiu ordo estas la tuta sekureca eco de la dezajno.

La gardanto estas dua regulo sur la sama elektilo, kies verdikto estas unreachable. Donu al ĝi pli altan nombran prioritaton, por ke la serĉo ankoraŭ venku dum la tunelo estas supren. Kiam la tunela itinero malaperas, la serĉo revenas nenion kaj la gardanto haltigas la serĉadon anstataŭ lasi ĝin fali al la WAN-defaŭlto en la ĉefa tabelo.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Fermu la falfoson antaŭ ol malfermi ĝin

Instalu unue la gardanton kaj poste la serĉon. Fari ĝin inverse lasas fenestron da sekundoj, en kiu la trafiko de testa kliento povas atingi la suprenligon.

La filtrilo kompletigas la bildon. En la hoko forward akceptu la direkton de LAN al tunelo por la testa prefikso kaj la establitan returnan direkton, poste forĵetu ĉion alian; la NAT por tiu prefikso sur la tunelan interfacon iras en postrouting. Ĝuste lasi policy drop sur la plusenda ĉeno estas tio, kio igas mankan itineron silento anstataŭ liko. Inversa voja filtrado bezonas malstreĉan reĝimon sur la tunela interfaco, ĉar publika fonto alvenanta malenkapsuligita havas sian plej bonan inversan itineron ĉe la WAN-flanko. Linux prenas la pli altan el la valoroj all kaj por-interfaca, do agordi la tunelan interfacon ne samas kiel malfortigi validigon ĉie.

Pruvu ĝin per la fiaska kazo

Demandu la kernon precize, nomante la fontan adreson de la kliento kaj la interfacon, sur kiu ĝi alvenas. Serĉo sen ambaŭ respondas alian demandon kaj aspektos ĝusta en ambaŭ kazoj. Poste rigardu la fajroŝirmilajn nombrilojn, la transigan staton de la partnero kaj la propran servon de la kliento.

Testu la forigon konvene. Haltigu la tunelon lasante la regulon kaj la filtrilon en la loko: la kliento devus halteti kaj la propra trafiko de la kluzo devus daŭre funkcii. Poste haltigu la partneron sen tuŝi la lokan interfacon, kaj tiu estas la kazo, kiu kaptas dezajnojn fidantajn nur al la ĉeesto de la itinero. Fine restarigu kaj rekontrolu la regulan ordon, ĉar malfara hoko, kiu forigas la gardanton, redonas la tutan dezajnon al la ĉefa tabelo. Notu la tabelan numeron, la prioritatojn kaj la interfacajn nomojn sur la ŝanĝbileto, ĉar la sekva persono, kiu aldonos regulon, estas tiu, kiu rompos tion.