Rhagddodiad cyhoeddus drwy OpenVPN: trwsio’r llwybr dychwelyd

Gwyliwch y twnnel yn codi a’r cleient yn pingio’r ochr draw, ac yna cyfeiriad cyhoeddus sy’n perthyn y tu ôl i’r VPN yn ateb o rywle arall, neu ddim o gwbl. Nid yw’r symptom hwn fel arfer yn ymwneud â’r seiffr na’r tystysgrifau. Mae rhagddodiad a gyfeirir gan y darparwr yn cael ei ddanfon fel llwybr IP, ac mae ei gario drwy OpenVPN yn golygu ailgynhyrchu’r llwybr hwnnw ar ddau lefel a chadw’r cyfeiriad ffynhonnell ar y llwybr dychwelyd. Nid oes angen pontio’r WAN, ac nid yw ychwanegu’r cyfeiriad at ryngwyneb yn creu’r llwybr uwch.

Rhaid cyfeirio’r rhagddodiad atoch chi yn gyntaf

Gofynnwch i’r darparwr sut mae’r bloc yn cael ei ddanfon. Mae rhagddodiad a gyfeirir at brif gyfeiriad eich gweinydd yn beth gwahanol i gyfeiriadau y mae’r darparwr yn disgwyl eu cyrraedd yn uniongyrchol ar segment WAN. Dim ond y model cyntaf sy’n gweithio gyda’r dyluniad yma.

Os yw’r darparwr yn cyfeirio 198.51.100.64/28 at eich gweinydd mynediad, mae pecynnau ar gyfer yr amrediad hwnnw’n cyrraedd y gweinydd ac yn stopio yno oni bai eich bod yn eu hanfon ymlaen. Os yw’r darparwr yn lle hynny’n pontio’r amrediad ar eich uplink, rhaid i’r gweinydd ateb ARP ar ei gyfer, sy’n broblem wahanol.

Profwch y model danfon cyn cyffwrdd ag OpenVPN: o’r tu allan, pingiwch gyfeiriad yn y bloc a gwyliwch pa ryngwyneb sy’n ei dderbyn. Os nad oes dim yn cyrraedd, ni fydd unrhyw ffurfweddiad twnnel yn helpu. Os yw’r cyfeiriad yn ateb yn uniongyrchol ar y WAN, mae’r darparwr yn pontio yn hytrach na chyfeirio, ac nid yw’r dyluniad isod yn berthnasol.

Dwy lefel gyfeirio: llwybr y cnewyllyn ac iroute

Mae OpenVPN angen y rhagddodiad mewn dau le. Rhaid i’r cnewyllyn wybod bod y rhagddodiad yn perthyn i ddyfais y twnnel, fel bod pecynnau a anfonir ymlaen yn mynd i mewn i OpenVPN yn lle’r llwybr diofyn. Rhaid i OpenVPN hefyd wybod pa gleient dilys sy’n berchen ar y rhagddodiad, sef y cofnod iroute yn y cyfeiriadur sy’n benodol i’r cleient.

Mae llwybr ochr y gweinydd yn edrych fel hyn, gyda’r rhagddodiad a’r mwgwd yn cyfateb i’r dyraniad:

ip route add 198.51.100.64/28 dev tun0

Mae’r ffurfweddiad sy’n benodol i’r cleient yn dynodi perchnogaeth. Rhowch ef yn y ffeil CCD a enwir ar ôl enw cyffredin tystysgrif y cleient, a chadarnhewch mai’r cyfeiriadur hwnnw yw’r un y mae’r gweinydd yn ei ddarllen mewn gwirionedd:

iroute 198.51.100.64 255.255.255.240

Mae dogfennaeth OpenVPN ar rwydweithiau wedi’u cyfeirio yn disgrifio’r ddwy lefel a pham eu bod yn ar wahân. Mae llwybr cnewyllyn heb iroute yn anfon pecynnau i’r twnnel heb berchennog, ac mae OpenVPN yn eu gollwng. Mae iroute heb lwybr y cnewyllyn yn gadael pecynnau ar lwybr diofyn y gweinydd. Mae’r ddau gamgymeriad yn edrych fel twnnel wedi torri o ochr y cleient.

Lle mae’r cyfeiriad gwasanaeth yn byw

Nid yw’r rhagddodiad dirprwyedig yr un peth â chyfeiriadau’r twnnel ei hun. Rhifwch y cyswllt o’r gofod preifat os hoffech, a rhowch y cyfeiriad gwasanaeth cyhoeddus lle mae’r gwasanaeth yn rhedeg mewn gwirionedd.

Ar gleient Linux sy’n terfynu’r gwasanaeth yn lleol, mae un cyfeiriad gwesteiwr yn ddigon:

ip address add 198.51.100.70/32 dev lo

Os yw’r rhagddodiad yn cael ei gyfeirio ymlaen at westai VM neu LAN arall, ffurfweddwch y llwybr i lawr yna a’i lwybr dychwelyd yn lle hynny. Nid oes angen neilltuo pob cyfeiriad yn y bloc i’r cleient VPN, ac mae’n creu gwrthdaro yn ddiweddarach.

Cadwch y ffynhonnell gyhoeddus ar y llwybr dychwelyd

Rhaid i ateb o’r rhagddodiad dirprwyedig adael drwy’r twnnel a chyrraedd llwybr y darparwr. Os yw’r gwesteiwr o bell yn ei anfon drwy ei ISP ei hun, mae’r cyfeiriad ffynhonnell yn edrych yn ffug, ac mae’r darparwr neu’r cyrchfan yn ei ollwng. Yr ateb yw rheol sy’n seiliedig ar ffynhonnell neu dabl llwybro pwrpasol, nid NAT ehangach. Heb hynny, mae’r gwasanaeth yn gweithio o bartner y twnnel ac yn methu o bob man arall.

Ar y gweinydd mynediad, rheol masquerade eang yw’r troseddwr arferol. Mae’n ailysgrifennu’r ffynhonnell gyhoeddus i brif gyfeiriad y gweinydd, ac ni fydd y cleient byth yn gweld yr un go iawn:

iptables -t nat -S POSTROUTING

Cyfyngwch NAT i’r cleientiaid VPN preifat sydd ei angen, a gadewch y rhagddodiad dirprwyedig heb ei gyfieithu. Yna cadarnhewch fod y gweinydd yn anfon y rhagddodiad ymlaen o gwbl, oherwydd mae cadwyn anfon ymlaen sy’n gwrthod yn ddiofyn yn ei ollwng yn dawel.

Gwiriwch y ddau gyfeiriad cyn ymddiried ynddo

Mae’r gwirio yn bedair arsylwad, nid un. Cadarnhewch fod llwybr y darparwr yn cyrraedd, bod y cnewyllyn yn anfon y rhagddodiad i’r twnnel, bod OpenVPN yn ei briodoli i’r cleient cywir, a bod yr ateb yn dychwelyd gyda’r ffynhonnell gyhoeddus yn gyfan. Mae gan bob arsylwad ei orchymyn ei hun, felly mae methiant yn cyfeirio at haen yn hytrach na’r dyluniad cyfan. Rhedwch nhw yn y drefn honno ar ôl pob newid ffurfweddiad.

Gofynnwch i’r cnewyllyn pa lwybr y mae cyfeiriad dirprwyedig yn ei gymryd, a gwyliwch y twnnel tra mae cais yn rhedeg:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Gall hidlo llwybr cefn ddadwneud llwybr cywir. Gwiriwch y gosodiad effeithiol ar y twnnel ac ar yr uplink, a chofiwch fod modd llym yn gwrthod traffig nad yw ei ffynhonnell yn cyfateb i’r rhyngwyneb y cyrhaeddodd arno:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Yn olaf, profwch yr achos methiant. Stopiwch y twnnel a chadarnhewch nad yw’r rhagddodiad cyhoeddus yn gollwng allan o’r uplink arferol. Dylai adfer y VPN ddod â’r gwasanaeth yn ôl heb ehangu pa borthladdoedd mae’r gwesteiwr yn eu datgelu.