Sut mae cleient OpenVPN y tu ôl i NAT yn dod yn allfa ryngrwyd

Tri gwesteiwr Linux, un cynllun: canolbwynt OpenVPN sy'n gyraeddadwy'n gyhoeddus, gliniadur defnyddiwr, a pheiriant allfa y tu ôl i lwybrydd cartref cyffredin nad yw'n anfon dim i mewn. Mae'r allfa'n deialu'r canolbwynt ei hun. Yna mae traffig y defnyddiwr yn mynd i mewn i'r tiwnel wrth y gliniadur ac yn gadael trwy ddolen i fyny'r allfa. Mae popeth sy'n syndod yn dilyn o un manylyn: yr allfa a gychwynnodd y cysylltiad, felly mae'r llwybr i mewn eisoes yn bodoli ac nid oes angen porthflaen.

Mae'r hyn sy'n dilyn yn olrhain llwybr y pecyn yn hytrach na threfn y ffurfweddiad, oherwydd dim ond pan wyddoch pa gydran sy'n penderfynu beth y mae'r ffurfweddiad yn gwneud synnwyr. Mae pob haen yn penderfynu un peth yn union, a'r camgymeriadau'n crynhoi lle tybir bod dwy haen yn un.

Dwy sesiwn gludiant, un llwybr mewnol

Mae pob gwesteiwr yn cadw ei gysylltiad allanol i'r canolbwynt, ac nid oes yr un ohonynt yn gwybod am y llall. Mae traffig y defnyddiwr i'r rhyngrwyd yn llif mewnol ar wahân sy'n cael ei gario y tu mewn i diwnel y defnyddiwr ac yna'n cael ei allyrru o diwnel yr allfa. Y llif hwnnw yw'r hyn y mae'n rhaid i'r canolbwynt ei lwybro, a dyna'r hyn y mae'n rhaid i'r allfa ei anfon ymlaen.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Gan fod y ddau gysylltiad allanol yn mynd allan o ochr y cleient, nid yw llwybrydd yr allfa byth yn gweld SYN sy'n dod i mewn ac nid oes angen rheol NAT cyrchfan. Dim ond cadw'r gludiant sefydledig yn fyw sydd raid iddo, ac mae'n gwneud hynny'n barod ar gyfer unrhyw gysylltiad hirhoedlog. Nid oes angen i ddim ar y rhyngrwyd cyhoeddus gyrraedd yr allfa yn gyntaf, a dyna pam nad yw cyfeiriad deinamig ar y ddolen honno'n broblem. Rhaid i'r llwybrydd ganiatáu'r sesiwn allanol o hyd, ond yr un ganiatâd yw hwnnw ag y mae porwr yn ei ddefnyddio.

Beth mae iroute yn ei osod y tu mewn i'r gweinydd

Y canolbwynt yw'r unig ddyfais sy'n penderfynu pa bâr sy'n berchen pa gyrchfan, ac mae'n gwneud hynny yn ei dabl llwybro gofod defnyddiwr ei hun, nid yn un y cnewyllyn. Gall cofnod client-config-dir ar gyfer yr allfa o'r enw exit-node hawlio'r rhagddodiad diofyn yno:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Mae'r llinell honno'n dweud wrth broses y gweinydd "mae pecynnau mewnol ag unrhyw gyrchfan yn perthyn i'r cleient hwn". Nid yw'n ychwanegu llwybr diofyn at system weithredu'r canolbwynt, ac nid yw'n gwneud y canolbwynt yn borth rhyngrwyd. Cyfeirlyfr OpenVPN 2.6 yn cadw llwybro mewnol sy'n benodol i'r cleient a llwybro'r cnewyllyn fel mecanweithiau ar wahân, a'r gwahanu hwnnw yw'r rheswm y mae'r cynllun yn gweithio heb gyffwrdd â llwybr diofyn y canolbwynt.

Mae ar y defnyddiwr angen y cyfarwyddyd drych, wedi'i ddanfon fel push, fel bod ei draffig yn mynd i mewn i'r tiwnel yn lle gadael trwy ei borth lleol. Gyda thopoleg is-rwydwaith mae'r pwll yn llwybr cysylltiedig ar ddyfais tun yr allfa, felly nid oes angen push ychwanegol ar y dychweliad; yr hyn na ddylai'r allfa ei dderbyn yw'r ailgyfeiriad isod, a fyddai'n anfon ei thraffig i fyny yn ôl i'r tiwnel y mae'n ceisio ei ddefnyddio. Anfonwch ef at y defnyddiwr yn unig, a darllenwch y llwybrau a gymhwyswyd ar y cleient yn lle ymddiried bod y ffeil CCD wedi'i dewis.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Cnewyllyn yr allfa sy'n gwneud yr anfon ymlaen

Y tu mewn i'r allfa, mae pecyn o'r defnyddiwr yn cyrraedd y rhyngwyneb tun wedi'i gyfeirio at ryw westeiwr rhyngrwyd. Mae'r cnewyllyn yn ymgynghori â'i dabl llwybro, yn canfod y ddolen i fyny wirioneddol fel y gorau cyfateb, ac yna'n cymhwyso dwy bolisi annibynnol: a ellir anfon y pecyn hwn ymlaen o gwbl, ac a all adael trwy'r rhyngwyneb hwnnw gyda'r cyfeiriad ffynhonnell hwnnw. Mae anfon ymlaen yn sysctl, ac mae i ffwrdd yn ddiofyn ar lawer o ddosbarthiadau.

Felly mae ar yr allfa angen anfon ymlaen IPv4 wedi'i alluogi'n barhaus, rheol sy'n derbyn ffynonellau tiwnel y defnyddiwr tua'r ddolen i fyny, a'r llwybr ateb yn ôl trwy'r tun. Mae galluogi ar gyfer y gwesteiwr cyfan hefyd yn newid ymddygiad popeth arall sy'n llwybro trwyddo, a dyna pam y dylai'r rheol enwi ffynonellau a rhyngwynebau yn lle derbyn popeth.

Cyfieithu ffynhonnell sy'n prynu'r llwybr dychwelyd

Nid oes gan westeiwr rhyngrwyd lwybr i gyfeiriad 10.90.0.x, felly byddai atebion yn cael eu gollwng cyn cyrraedd yr allfa. Mae ailysgrifennu'r ffynhonnell wrth i'r pecyn adael y ddolen yn datrys hynny, ac mae olrhain cysylltiadau'n gwrthdroi'r ailysgrifennu ar y ffordd yn ôl.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Mae'r rheol uchod yn fan cychwyn ar gyfer un rhyngwyneb i fyny, nid yn bolisi mur tân. Culhewch y ffynhonnell i'r aseiniadau a awdurdodwyd gennych, a chadwch bolisi mewnbwn yr allfa ar wahân fel nad yw cymylu traffig y tiwnel yn ddistaw yn datgelu gwasanaethau lleol. Ar westeiwr â chyfeiriad i fyny deinamig, mae cymylu hefyd yn eich arbed rhag olrhain y cyfeiriad â llaw.

Lle y gall y canolbwynt orfodi a lle na all

Gyda client-to-client a llwybr data gofod defnyddiwr traddodiadol, mae'r canolbwynt yn trosglwyddo pecynnau mewnol rhwng parau y tu mewn i broses y gweinydd. Nid ydynt byth yn croesi cadwyn FORWARD cnewyllyn y canolbwynt, felly ni all rheol cnewyllyn yno gyfyngu ar dramwyfa rhwng parau, waeth pa mor ofalus y'i hysgrifennwyd. Rhaid i orfodi fyw ym mholisi'r gweinydd: pwy ganiateir i gysylltu, pa ffeil CCD maen nhw'n ei chael, ac a roddir perchnogaeth ddiofyn yr allfa o gwbl.

Dyna hefyd pam mae iroute diofyn yn benderfyniad ymddiriedaeth eang. Rhaid i'r allfa dderbyn traffig dychwelyd o gyfeiriadau mympwyol yn gyfreithlon, a rhaid iddi fod yn beiriant rydych yn ei reoli, ei glytio ac yn ei fonitro. Rhoi'r un berchnogaeth i bâr na fyddech yn rhoi llwybrydd iddo yw'r camgymeriad y mae'r cynllun hwn yn ei wahodd.

Aelodaeth yw'r rheolaeth wirioneddol. Gall unrhyw gleient sy'n gallu ffurfweddu ei lwybrau geisio defnyddio'r allfa, felly mae cyfyngu ar bwy a ganiateir i gysylltu, neu ba barau y bydd yr allfa'n eu gwasanaethu, yn rhan o'r cynllun.

Methu'n ddiogel pan fydd yr allfa'n diflannu

Tynnwch yr allfa all-lein ac mae'r berchnogaeth ddiofyn fewnol yn diflannu gyda'i sesiwn. Yr hyn na ddylai ddigwydd yw i'r canolbwynt ddod yn ddistaw yn allfa amnewidiol: dim llwybr diofyn o'r pwll VPN i ddolen i fyny'r canolbwynt, a dim rheol gymylu eang a fyddai'n barod i anfon yr un traffig ymlaen. Profwch y methiant hwnnw'n fwriadol, yna profwch adferiad gyda llif newydd yn hytrach na thudalen a oedd eisoes ar agor.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Os yw traffig y defnyddiwr yn dal i gyrraedd y rhyngrwyd ar ôl i'r allfa fynd, mae rhywbeth arall yn ei gario ac nid yw'r ffin a fwriadwyd gennych yn bodoli. Trinwch DNS ac IPv6 fel penderfyniadau ar wahân: nid yw llwybr IPv4 a chymylu'n dweud dim am draffig AAAA, a bydd datryswr a wthiwyd gan y canolbwynt yn ateb o ble bynnag y mae'r ymholiad yn gadael.