Cleient WireGuard yn methu cyrraedd cleient OpenVPN?
Mae’r ddau dwnnel yn codi ac mae’r ping croes yn marw. Trwsiwch orchudd y cyrchfan, perchnogaeth y ffynhonnell a’r llwybr dychwelyd heb bontio’r protocolau.
Mae’r ddau dwnnel yn cysylltu, gall pob cleient gyrraedd y porth, a’r munud y mae un yn ceisio cyfeiriad y llall mae’r pecynnau’n diflannu. Nid oes dim o’i le ar y naill na’r llall o’r ysgydwadau llaw, ac nid yw ailgyhoeddi allweddi yn newid hynny. Mae’r porth yn cario pecynnau IP cyffredin heb eu hamgryptio rhwng dau o’i ryngwynebau ei hun, felly nid oes angen i’r protocolau ddeall ei gilydd byth; yr hyn sydd ei angen yw tri pheth nad yw unrhyw ysgydwad llaw yn eu rhoi. Gorchudd y cyrchfan ar y cleient sy’n tarddu, perchnogaeth y ffynhonnell wrth y porth, a llwybr dychwelyd ar yr ochr bellaf. Mae’r symptom yr un fath ar gyfer y tri, a dyna pam y cânt eu diagnosio gyda’i gilydd.
Mae un darn ar goll ar y tro yn y symptom
Mae’r dyluniad hwn yn defnyddio pwll WireGuard 10.71.0.0/24 ar wg1 a phwll OpenVPN 10.72.0.0/24 ar tun1, y ddau yn gorffen ar un porth. Mae’r cais dan brawf yn mynd o 10.71.0.5 i HTTPS ar 10.72.0.30. Mae pob cam isod yn ymwneud â’r un llif hwnnw. Mae gan bob gwiriad nod beddrod gwahanol er bod y defnyddiwr yn eu profi’n union yr un fath, a’r rhan fwyaf o’r amser dim ond un o’r tri sydd ar goll ar y tro.
Dechreuwch drwy gadarnhau bod y ddau bwll mewn gwirionedd ar y porth hwn a bod anfon ymlaen wedi’i alluogi yn y namespace lle mae’r twneli’n byw. Nid yw porth sy’n gorffen y ddau brotocol mewn gwahanol namespaceau yn anfon dim rhyngddynt, ac mae’n werth diystyru hynny cyn darllen unrhyw ffurfweddiad cymar.
Estynnwch orchudd cyrchfan y pelydryn
Ar y cleient WireGuard, rhaid i’r cofnod cymar presennol ddewis y porth ar gyfer cyrchfan OpenVPN, sy’n golygu bod rhaid i ragddodiad y cyrchfan ymddangos yn rhestr a ganiateir y cymar hwnnw. Nid yw ei ychwanegu yn creu ail dwnnel; mae’n newid pa gymar y mae’r cleient yn ei ddewis pan fydd yn chwilio am y cyfeiriad hwnnw, a chyda wg-quick mae’r llwybr fel arfer yn dilyn y rhestr yn awtomatig.
AllowedIPs = 10.71.0.0/24, 10.72.0.0/24
Gadewch y llinellau allwedd a diweddbwynt go iawn heb eu cyffwrdd, a chofiwch nad yw rheolwr sy’n defnyddio Table = off yn cymryd unrhyw lwybr o’r rhestr hon o gwbl. Yn yr achos hwnnw rhaid i’r un rhagddodiad gael ei osod yn nhabl llwybrau’r system gan bwy bynnag sy’n berchen arno, ac mae llwybr ar goll yno yn edrych yn union fel rhagddodiad a ganiateir ar goll.
Cadwch berchnogaeth y ffynhonnell wrth y porth
Dylai cofnod cymar y cleient hwn ar y porth barhau i fod yn berchen ar gyfeiriad ffynhonnell y cleient hwnnw’n union. Mae cyfeiriadau a ganiateir yn cael eu gwirio i’r ddau gyfeiriad: maent yn dewis cymar ar gyfer traffig allan ac yn gwirio bod ffynhonnell pecyn sy’n dod i mewn yn perthyn i’r cymar a’i gyrhaeddodd. Rhoi pwll OpenVPN yng nghofnod y pelydryn am fod y pelydryn eisiau cyrraedd ato yw’r camgymeriad sy’n gyrru traffig tuag at y cyfranogwr anghywir.
AllowedIPs = 10.71.0.5/32
Darllenwch y cofnod hwnnw fel datganiad o berchnogaeth yn hytrach na chyfleustra llwybro. Mae unrhyw beth arall y mae angen i’r cleient gyrraedd ato yn perthyn i restr cyrchfannau’r cleient, nid i syniad y porth o’r hyn y caniateir i’r cymar hwn ei anfon.
Rhowch lwybr dychwelyd i ochr OpenVPN
Mae angen llwybr yn ôl i ffynhonnell WireGuard ar y targed nawr, ac ar gyfer cleientiaid o bwll mae hynny fel arfer yn cyrraedd fel llwybr a wthiwyd o weinydd OpenVPN. Gwthiwch ef yn unig at gleientiaid y dylai fod ganddynt, a chadarnhewch ar y cleient ei fod wedi’i dderbyn yn hytrach na chymryd yn ganiataol fod y gyfarwyddeb wedi’i chymhwyso.
push "route 10.71.0.0 255.255.255.0"
Nid yw dosbarthu llwybrau yn awdurdodiad. Pan fydd y cyrchfan y tu ôl i gleient OpenVPN arall yn lle yn y pwll, mae perchnogaeth LAN y cleient hwnnw ei hun a’i ofynion anfon ymlaen yn ymuno â’r dyluniad, a’r llwybr a wthiwyd yw dim ond yr hanner cyntaf. Ail-fframiwch y gofyniad fel graff cyn ychwanegu cyfarwyddebau: pa nod sy’n berchen ar ba ragddodiad, a pha nod sy’n anfon tuag ato.
Caniatáu’r un gwasanaeth yr oeddech yn bwriadu ei ganiatáu
Gydag anfon ymlaen wedi’i alluogi a’r ddau bwll yn llwybradwy, y cwestiwn sy’n weddill yw polisi. Ysgrifennwch y rheol ar gyfer y llif penodol yn hytrach nag ar gyfer y pâr rhyngwyneb yn gyffredinol, rhagolwgwch hi cyn ei chymhwyso, a chadwch y llwybr dychwelyd â chyflwr fel nad yw atebion yn cael eu blocio fel cysylltiadau newydd. Nid yw prawf sych yn costio dim ac mae’n dangos yn union beth fyddai’n cael ei ychwanegu.
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
Rheolau a anfonir ymlaen yw’r rhain, yn wahanol i reolau gwrando’r porth ar gyfer y ddwy wasanaeth VPN. Nid yw agor y porthladdoedd UDP allanol yn awdurdodi’r cais mewnol, ac nid yw awdurdodi’r cais mewnol yn gofyn am SSH heb gyfyngiad i’r porth nac am ganiatâd diofyn ar anfon ymlaen. Rhaid i firewall y targed ei hun a’r cyfeiriad gwrando gytuno hefyd, gan fod gwasanaeth sydd wedi’i rwymo i loopback yn gwrthod y pecyn mwyaf gofalus ei lwybro. Mae polisi sy’n gorchuddio un cyfeiriad yn unig o’r sgwrs yn tueddu i fethu â chais llwyddiannus ac ateb distaw, sef y canlyniad mwyaf dryslyd o’r tri.
Mae llwybrau cilyddol fel arfer yn golygu nad oes angen cyfieithu ffynhonnell, sy’n cadw cyfeiriad WireGuard yn y targed ac yn gwneud logiau’n ddarllenadwy. Peidiwch ag ychwanegu masquerading blanced am fod dau brotocol dan sylw, a pheidiwch â dileu rheol cyfieithu bresennol heb wybod beth sy’n dibynnu arni. Yna gwiriwch yr un llif o’r dechrau i’r diwedd, a phrofwch un ffynhonnell neu borthladd a waherddir hefyd: nid yw ysgydwad llaw sy’n gweithio ar bob ochr yn profi’r llwybr croes nac ynysu.