Kann e WireGuard-Client keen OpenVPN-Client erreechen?

Déi zwou Tunnellen verbannen, all Client erreecht de Gateway, an an deem Abléck wou ee probéiert d'Adress vum aneren, verschwannen d'Paketen. Un deenen zwou Handshakes ass näischt falsch, an et ännert och näischt, wéi dacks een d'Schlëssele erëm erausgëtt. De Gateway dréit gewéinlech onverschlësselt IP-Paketen tëscht zwee vu sengen eegene Schnëttstellen, dofir mussen d'Protokoller sech ni verstoen; si brauchen dräi Saachen, déi keen Handshake liwwert. Zilofdeckung um Ursprongsclient, Quelleproprietéit beim Gateway an en Retourwee op der anerer Säit. D'Symptom ass fir all dräi datselwecht, dofir ginn si zesummen diagnostizéiert.

Dem Symptom feelt ëmmer ee Stéck op eemol

Dësen Design benotzt e WireGuard-Pool vun 10.71.0.0/24 op wg1 an e OpenVPN-Pool vun 10.72.0.0/24 op tun1, déi zwou enneren op engem Gateway. D'Ufro ënner Test geet vun 10.71.0.5 op HTTPS op 10.72.0.30. All Schrëtt hei drënner geet ëm genau deen een Floss. All Iwwerpréiwung huet eng aner Feeler-Signatur, obwuel de Benotzer se datselwecht erlieft, an et feelt meeschtens just eng vun den dräi gläichzäiteg.

Fänkt domat un ze bestätegen, datt déi zwou Pools wierklech op dësem Gateway sinn an datt d'Weiderleedung an deem Nameraum ageschalt ass, wou d'Tunnellen dra liewen. E Gateway, deen déi zwou Protokoller an ënnerschiddlechen Namräim ofschléisst, leet näischt tëscht hinnen weider, an dat ass et wäert auszeschléissen, ier een eng Peer-Konfiguratioun liest.

Erweidert d'Zilofdeckung vum Speeche

Um WireGuard-Client muss de besteeënde Peer-Andrag de Gateway fir d'OpenVPN-Zil auswielen, dat heescht de Zielpräfix muss an der erlaabter Lëscht vun deem Peer stoen. En derbäizemaachen schaaf keng zwee Tunnellen; et ännert, wéi ee Peer de Client wielt, wann en déi Adress sicht, a mat wg-quick follegt de Wee normalerweis automatesch der Lëscht.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Loosst déi richteg Schlëssel- an Endpunkt-Zeilen onberéiert a denkt drun, datt e Verwalter, deen Table = off benotzt, guer keng Route aus dëser Lëscht hëlt. An deem Fall muss deeselwechte Präfix vun deem, deen en huet, an d'Routentabell vum System installéiert ginn, an eng Route, déi do feelt, gesäit genee aus wéi e fehlende erlaabte Präfix.

Halt d'Quelleproprietéit beim Gateway

Den Peer-Andrag vun dësem Client um Gateway soll weiderhi genee d'Quelladress vun deem Client besëtzen. Erlaabt Adresse ginn a béid Richtungen iwwerpréift: si wielen e Peer fir de gänglechen Trafic aus, a si validéieren, datt d'Quell vun engem erakommende Paket zu deem Peer gehéiert, deen en ofgeschéckt huet. Den OpenVPN-Pool an den Andrag vum Speeche setzen, well de Speechen en erreeche wëll, ass dee Feeler, dee den Trafic an déi falsch Richtung schéckt.

AllowedIPs = 10.71.0.5/32

Liest deen Andrag als Proprietéitserklärung an net als Routing-Bequemlechkeet. Alles anescht, wat de Client mussi erreechen, gehéiert an d'Zillëscht vum Client, net an d'Virstellung vum Gateway dovun, wat dësem Peer erlaabt ass ze schécken.

Gitt der OpenVPN-Säit e Retourwee

D'Zil brauch elo eng Route zréck zu der WireGuard-Quell, an a Pool-Cliente kënnt si meeschtens als gedréckte Wee vum OpenVPN-Server. Dréckt se just un d'Clienten, déi se solle hunn, a bestätegt um Client, datt se ugeholl gouf, amplaz unzehuelen, datt d'Instruktioun ugewand gouf.

push "route 10.71.0.0 255.255.255.0"

D'Verdeele vu Weeër ass keng Autorisatioun. Wann d'Zil hannert engem aneren OpenVPN-Client läit an net am Pool, kommen d'Proprietéit vun deem Client iwwer säi eegene LAN a seng Weiderleedungs-Ufuerderungen an den Design, an de gedréckte Wee ass just d'éischt Halschent. Formuléiert d'Ufuerderung als Graf nei, ier Dir Instruktiounen derbäi setzt: wéi en Node wéi ee Präfix besitzt a wéi en Node dohi weiderleet.

Erlaabt just deen een Déngscht, deen Dir wëllt erlaaben

Mat ageschaltem Weiderleeden an deenen zwou routbare Pools ass d'Fro déi eenzeg Politik. Schreift d'Reegel fir de konkrete Floss an net fir d'Schnëttstellepaar allgemeng, kuckt se virum Uwenden un, a behält de zoustännegen Retourwee, sou datt Äntwerten net als nei Verbindungen blockéiert ginn. En Testlaf kascht näischt a weist genee, wat derbäi gesat gëtt.

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

Dëst si Regele fir weidergeleeden Trafic, getrennt vun den Nolauschter-Regele vum Gateway fir déi zwou VPN-Déngschter. Déi baussenzeg UDP-Porten opzemaachen autoriséiert déi bannenzeg Ufro net, an d'bannenzeg Ufro ze autoriséieren erfuerdert weder onbeschränkten SSH op de Gateway nach eng Standard-Erlaabnis um Weiderleeden. Och d'Firewall vum Zil an seng Nolauschteradress musse mateneen iwwerenee kommen, well en Déngscht, deen un loopback gebonnen ass, och nach dat suergfältegst geroutent Paket ofweist. Eng Politik, déi just eng Richtung vum Gespréich deckt, versoeit meeschtens mat enger erfolgreicher Ufro an enger stommer Äntwert, wat dat verwirrendst vun den dräi Resultater ass.

Wiesselwäiteg Weeër heescht meeschtens, datt keng Quell-Iwwersetzung noutwenneg ass, wat d'WireGuard-Adress um Zil erhält an d'Logbicher liesbar mécht. Setzt keng allgemeng Masquerading derbäi well zwee Protokoller bedeelegt sinn, a läscht keng bestoeend Iwwersetzungsreegel, ouni ze wëssen, wat dovu ofhängeg ass. Iwwerpréift duerno deen eenzege Floss vun Ufank bis Enn, a testt och eng net erlaabt Quell oder e Port: en Handshake, deen op béide Säiten funktionéiert, beweist weder de gekräizte Wee nach d'Isolatioun.