Kin in WireGuard-klient gjin OpenVPN-klient berikke?

Beide tunnels ferbine, eltse klient berikt de gateway, en op it stuit dat ien it adres fan de oare probearret, ferdwine de pakketten. Oan gjin fan beide hânskuddings is wat ferkeard, en gjin einige werhelling fan kaaiien feroaret dat. De gateway draacht gewoane net-fersifere IP-pakketten tusken twa fan syn eigen ynterfaces, dus de protokollen hoege inoar nea te begripen; wat se nedich hawwe binne trije dingen dy't gjin hânskudding jout. Bestimmingsdekking op de oarsprongskliïnt, boarne-eigendom by de gateway en in weromwei oan de oare kant. It symptoom is itselde foar alle trije, dêrom wurde se tegearre diagnostisearre.

It symptoom mist ien stik tagelyk

Dit ûntwerp brûkt in WireGuard-pool fan 10.71.0.0/24 op wg1 en in OpenVPN-pool fan 10.72.0.0/24 op tun1, beide einigje op ien gateway. It fersyk ûnder test rint fan 10.71.0.5 nei HTTPS op 10.72.0.30. Eltse stap hjirûnder giet oer krekt dy iene stream. Eltse kontrôle hat in oare flaterhanttekening, ek al belibbet de brûker se itselde, en meastentiids mist der tagelyk mar ien fan de trije.

Begjin mei te befêstigjen dat beide pools wier op dizze gateway steane en dat trochstjoeren oan is yn de nammeromte dêr't de tunnels yn libje. In gateway dy't beide protokollen yn ferskillende nammeromten einigelet, stjoert neat tusken har troch, en dat is it wurdich út te sluten foar't jo hokker peer-konfiguraasje dan ek lêze.

Wreidzje de bestimmingsdekking fan de spiker út

Op de WireGuard-kliïnt moat de besteande peer-ynfier de gateway kieze foar de OpenVPN-bestimming, wat betsjut dat it bestimmingsprefiks yn de tastiene list fan dy peer stean moat. It tafoegjen makket gjin twadde tunnel; it feroaret hokker peer de klient kiest as er dat adres opsiket, en mei wg-quick folget de rûte de list normaal automatysk.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lit de echte kaai- en einpuntrigels ûnoantaaste, en tink derom dat in behearder dy't Table = off brûkt hielendal gjin rûte út dizze list nimt. Yn dat gefal moat itselde prefiks troch wa't it ek besit yn de rûtetabel fan it systeem ynstalleare wurde, en in ûntbrekkende rûte dêr liket krekt as in ûntbrekkend tastien prefiks.

Hâld boarne-eigendom by de gateway

De peer-ynfier fan dizze klient op de gateway moat noch altyd krekt it boarne-adres fan dy klient besitte. Tastiene adressen wurde yn beide rjochtingen kontrolearre: se kieze in peer foar útgeande ferkear en se falidearje dat de boarne fan in ynkommend pakket by de peer heart dy't it stjoerd hat. It OpenVPN-pool yn de ynfier fan de spiker sette om't de spiker it berikke wol, is de flater dy't ferkear nei de ferkearde dielnimmer stjoert.

AllowedIPs = 10.71.0.5/32

Lês dy ynfier as in ferklearring fan eigendom en net as in rûte-gemak. Al it oare dat de klient berikke moat heart by de bestimmingslist fan de klient, net by it byld dat de gateway hat fan wat dizze peer stjoere mei.

Jou de OpenVPN-kant in weromrûte

It doel hat no in rûte werom nei de WireGuard-boarne nedich, en foar klanten út in pool komt dy meastentiids as in treaune rûte fan de OpenVPN-tsjinner. Triuw dy allinnich nei klanten dy't him hawwe moatte, en befêstigje op de klient dat er akseptearre is ynstee fan oan te nimmen dat de rjochtline tapast is.

push "route 10.71.0.0 255.255.255.0"

Rûteferdieling is gjin autorisaasje. As it doel efter in oare OpenVPN-kliïnt sit ynstee fan yn de pool, komme it eigen LAN-eigendom fan dy klient en syn trochstjoer-easken by it ûntwerp, en de treaune rûte is mar de earste helte. Werformulearje de eask as in grafyk foar't jo rjochtlinen tafoegje: hokker knooppunt besit hokker prefiks, en hokker knooppunt stjoert dêr nei troch.

Stean allinnich de iene tsjinst ta dy't jo bedoelden ta te stean

Mei trochstjoeren oan en beide pools rûteber is de oerbliuwende fraach belied. Skriuw de regel foar de konkrete stream en net foar it ynterfacepear yn it algemien, besjoch him foar it tapassen en hâld it steatfolle werompaad sadat antwurden net as nije ferbiningen blokkearre wurde. In droege rin kostet neat en lit krekt sjen wat tafoege wurde soe.

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

Dit binne trochstjoerde regels, apart fan de harkregels fan de gateway foar de twa VPN-tsjinsten. De bûtenste UDP-poarten iepenje autorisearret it binnenste fersyk net, en it binnenste fersyk autorisearje freget gjin ûnbeheind SSH nei de gateway of in standerttastean by trochstjoeren. Ek de eigen firewall fan it doel en it harkadres moatte oerienkomme, om't in tsjinst bûn oan loopback it meast soarchfâldich rûte pakket noch wegert. Belied dat mar ien rjochting fan it petear dekt, mislearret meastentiids mei in slagge fersyk en in stil antwurd, wat de meast betiizjende útkomst fan de trije is.

Wjerskantsje rûtes betsjutte meastentiids dat gjin boarne-oersetting nedich is, wat it WireGuard-adres by it doel bewarret en logs lêsber makket. Foegje gjin algemiene masquerading ta om't der twa protokollen belutsen binne, en ferwiderje gjin besteande oersettingsregel sûnder te witten wat dêrfan ôfhinget. Ferifiearje dan de iene stream fan begjin oant ein, en test ek ien net-tastiene boarne of poarte: in wurkjende hânskudding oan eltse kant bewiist noch de kruse rûte noch de isolaasje.