Je, mteja wa WireGuard hawezi kumfikia mteja wa OpenVPN?

Mifereji yote miwili inaunganishwa, kila mteja anafikia lango, na wakati mmoja anajaribu anwani ya mwingine pakiti zinatoweka. Hakuna kitu kibaya katika yoyote ya mikono miwili ya salamu, na kutoa funguo upya hakuubadilishi huo. Lango hubeba pakiti za IP za kawaida zisizosimbwa kati ya miingiliano yake miwili, kwa hivyo itifaki hazihitaji kamwe kuelewana; zinachohitaji ni mambo matatu ambayo hakuna salamu ya mkono inayotoa. Ufikiaji wa lengwa kwenye mteja wa asili, umiliki wa chanzo kwenye lango na njia ya kurudi upande wa mbali. Dalili ni ile ile kwa yote matatu, ndiyo sababu huchunguzwa pamoja.

Dalili inakosa sehemu moja kwa wakati mmoja

Muundo huu unatumia bwawa la WireGuard 10.71.0.0/24 kwenye wg1 na bwawa la OpenVPN 10.72.0.0/24 kwenye tun1, yote mawili yanaishia kwenye lango moja. Ombi linalojaribiwa linaenda kutoka 10.71.0.5 hadi HTTPS kwenye 10.72.0.30. Kila hatua hapa chini inahusu mkondo huo mmoja. Kila ukaguzi una alama tofauti ya kushindwa ingawa mtumiaji anayapitia sawa, na kwa kawaida ni kimoja tu kati ya matatu kinachokosekana kwa wakati mmoja.

Anza kwa kuthibitisha kwamba mabwawa yote mawili yako kweli kwenye lango hili na kwamba upelekaji umewashwa katika nafasi ya majina ambapo mifereji inaishi. Lango linalomaliza itifaki zote mbili katika nafasi tofauti za majina halipeleki chochote kati yao, na inafaa kuondoa hilo kabla ya kusoma usanidi wowote wa mwenza.

Panua ufikiaji wa lengwa wa tawi

Kwenye mteja wa WireGuard, ingizo lililopo la mwenza lazima lichague lango kwa lengwa la OpenVPN, kumaanisha kiambishi cha lengwa lazima kionekane kwenye orodha inayoruhusiwa ya mwenza huyo. Kuiongeza hakuundi mfereji wa pili; hubadilisha ni mwenza gani mteja anachagua anapotafuta anwani hiyo, na kwa wg-quick njia kwa kawaida hufuata orodha kiotomatiki.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Acha mistari halisi ya ufunguo na kituo cha mwisho bila kuguswa, na kumbuka kwamba msimamizi anayetumia Table = off hachukui njia yoyote kutoka kwenye orodha hii. Katika hali hiyo kiambishi hicho hicho lazima kisakinishwe kwenye jedwali la njia la mfumo na yeye anayemiliki, na njia inayokosekana hapo inaonekana kama kiambishi kinachoruhusiwa kinachokosekana.

Hifadhi umiliki wa chanzo kwenye lango

Ingizo la mwenza la mteja huyu kwenye lango linapaswa kuendelea kumiliki anwani ya chanzo ya mteja huyo hasa. Anwani zinazoruhusiwa hukaguliwa katika pande zote mbili: huchagua mwenza kwa trafiki inayotoka na huthibitisha kwamba chanzo cha pakiti inayoingia ni cha mwenza aliyeituma. Kuweka bwawa la OpenVPN kwenye ingizo la tawi kwa sababu tawi linataka kulifikia ni kosa linaloelekeza trafiki kwa mshiriki asiye sahihi.

AllowedIPs = 10.71.0.5/32

Soma ingizo hilo kama tamko la umiliki na si kama urahisi wa njia. Kitu kingine chochote ambacho mteja anahitaji kufikia ni cha orodha ya malengo ya mteja, si cha fikra ya lango kuhusu kile mwenza huyu anaruhusiwa kutuma.

Ipe upande wa OpenVPN njia ya kurudi

Lengwa sasa linahitaji njia ya kurudi kwenye chanzo cha WireGuard, na kwa wateja wa bwawa kwa kawaida huja kama njia iliyosukuma kutoka kwa seva ya OpenVPN. Isukume kwa wateja tu wanaopaswa kuwa nayo, na uthibitishe kwenye mteja kwamba imekubaliwa badala ya kudhani kwamba maagizo yametumika.

push "route 10.71.0.0 255.255.255.0"

Usambazaji wa njia si idhini. Wakati lengwa liko nyuma ya mteja mwingine wa OpenVPN badala ya kuwa kwenye bwawa, umiliki wa LAN wa mteja huyo mwenyewe na mahitaji yake ya upelekaji hujiunga na muundo, na njia iliyosukumwa ni nusu ya kwanza tu. Andika upya hitaji kama grafu kabla ya kuongeza maagizo: fundo gani linamiliki kiambishi kipi, na fundo gani linapeleka kuelekea kwake.

Ruhusu huduma moja tu uliyokusudia kuiruhusu

Upelekaji ukiwa umewashwa na mabwawa yote mawili yakiwa na njia, swali linalobaki ni sera. Andika kanuni kwa mkondo maalum na si kwa jozi la miingiliano kwa ujumla, iangalie kabla ya kuitumia, na hifadhi njia ya kurudi yenye hali ili majibu yasizuiwe kama miunganisho mipya. Jaribio kavu haligharimu chochote na linaonyesha hasa nini kitaongezwa.

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

Hizi ni kanuni za trafiki inayopelekwa, tofauti na kanuni za kusikiliza za lango kwa huduma mbili za VPN. Kufungua bandari za nje za UDP hakuidhinishi ombi la ndani, na kuidhinisha ombi la ndani hakuhitaji SSH isiyo na kikomo kwa lango au ruhusa ya msingi kwenye upelekaji. Firewall ya lengwa yenyewe na anwani ya kusikiliza pia lazima zilingane, kwa sababu huduma iliyofungwa kwenye loopback hukataa hata pakiti iliyopewa njia kwa uangalifu zaidi. Sera inayofunika mwelekeo mmoja tu wa mazungumzo kwa kawaida hushindwa kwa ombi lililofanikiwa na jibu la kimya, ambalo ni tokeo la kuchanganya zaidi kati ya matatu.

Njia za pande zote kwa kawaida humaanisha kwamba tafsiri ya chanzo haihitajiki, ambayo huhifadhi anwani ya WireGuard kwenye lengwa na hufanya kumbukumbu zisomeke. Usiongeze masquerading ya jumla kwa sababu itifaki mbili zinahusika, na usiondoe kanuni iliyopo ya tafsiri bila kujua nini kinategemea juu yake. Kisha thibitisha mkondo huo mmoja kutoka mwanzo hadi mwisho, na ujaribu pia chanzo au bandari moja iliyokatazwa: salamu ya mkono inayofanya kazi kila upande haithibitishi njia ya kuvuka wala utengaji.