Porth VPN ar Raspberry Pi: un NIC neu borth cleient penodol

Mae gennych un Pi, un proffil VPN allan sy’n gweithio, a dwy ddyfais a ddylai gyrraedd y rhyngrwyd drwyddo. Y cwestiwn sy’n penderfynu’r adeiladwaith cyfan nid yw pa ganllaw i’w dilyn, ond faint o gynhwysiad sydd ei angen arnoch. Mae un porth yn gadael i’r Pi eistedd wrth ymyl y dyfeisiau hynny ar LAN y llwybrydd a gweithredu fel porth ychwanegol; mae ail borth yn gadael i chi eu rhoi ar segment lle mai’r Pi yw’r unig ffordd allan. Mae popeth ar ôl y dewis hwnnw — DHCP, cwmpas y mur tân, DNS, achos y cwymp — yn dilyn ohono.

Ym mha beth mae’r ddau gynllun yn wahanol mewn gwirionedd

Mae’r ddau gynllun yn llwybro. Y gwahaniaeth yw pwy arall sy’n sefyll ar y wifren a beth sy’n digwydd pan fo’ch polisi yn anghywir.

Cynhwysiad yw’r echel wirioneddol. Mae cynllun A yn gynghorol: mae dyfais sy’n anwybyddu’r porth a roddir gan DHCP ac yn dewis y llwybrydd yn dal i weithio, heb ei hamgryptio. Mae cynllun B yn cael ei orfodi gan dopoleg, oherwydd nid oes naid nesaf arall i’w dewis.

Cynllun A: y Pi fel porth ychwanegol ar y LAN presennol

Gadewch i ni dybio mai llwybrydd yr ISP yw 192.168.50.1, mai’r Pi yw 192.168.50.2, a bod y cleientiaid a ddewiswyd yn pwyntio at y Pi. Y peth pwysig yw bod dau lif pecyn gwahanol yn rhannu un cebl. Mae pecyn mewnol y cleient yn cyrraedd y Pi ac yn gorfod gadael drwy’r tiwnel; mae pecyn amgryptiedig y Pi ei hun i bartner y VPN yn gorfod gadael drwy’r un cebl at y llwybrydd. Maent yn teithio i gyfeiriadau cyferbyniol dros yr un rhyngwyneb ac angen triniaeth wahanol.

Rhowch ei gyfeiriad i’r Pi drwy’r rheolwr rhwydwaith sydd wedi’i osod yn lle hen rysáit ffeil rhyngwyneb sy’n ymladd ag ef am y ddyfais. Yna gosodwch y cleientiaid: porth statig ar un ddyfais, neu archeb DHCP sy’n rhoi 192.168.50.2 fel llwybrydd. Peidiwch â newid holl gwmpas DHCP y llwybrydd ar gyfer dwy ddyfais, a pheidiwch â thybio bod cleient yn parchu’r opsiwn — gwiriwch ef.

Mae’r gwendid yn strwythurol yn hytrach nag yn un y gellir ei drwsio. Gall unrhyw gleient ar y segment hwnnw bwyntio at 192.168.50.1 a gadael yn glir, ac mae dyfais ag ail ryngwyneb neu radio symudol yn gadael eich llwybr gorfodi yn gyfan gwbl. Os yw’r frawddeg honno’n annerbyniol i’r ddyfais dan sylw, mae eich ateb gennych yn barod: defnyddiwch gynllun B.

Cynllun B: mae porth penodol yn cau’r dyfeisiau i mewn

Yma mae’r Pi yn cadw 192.168.50.2 ar y cyswllt i fyny gyda phorth 192.168.50.1, ac yn cymryd 10.20.0.1/24 ar ail ryngwyneb ar gyfer y dyfeisiau sydd ynghlwm. Nawr mae’r Pi yn llwybrydd â dwy rwydwaith, ac mae gan y segment sydd ynghlwm un ffordd allan yn union.

Gwiriwch yr ystod yn erbyn popeth arall cyn ymrwymo: isrwydwaith y tiwnel ei hun, rhagddodiadau eraill rhwng safleoedd, ac unrhyw beth y gellir ei gyrraedd drwy’r VPN. Mae 10.20.0.0/24 sy’n gwrthdaro â LAN bell yn cynhyrchu’r math o ganlyniad hanner-gweithiol sy’n cymryd noswaith i’w ddiagnosio. Os mai addasydd USB yw’r ail borth, cadarnhewch ei fod yn cael ei gefnogi a phinnwch ei enw yn y rheolwr rhwydwaith fel nad yw aildrefnu ar ôl ailgychwyn yn symud eich cyfeiriad LAN.

Rhedwch y gwrandäwr DHCP ar y rhyngwyneb hwnnw yn unig. Mae gweinydd sy’n ateb ar y cyswllt i fyny yn cystadlu â llwybrydd yr ISP ac yn rhoi cyfeiriadau eich segment i weddill y tŷ. Rhwymwch ef i’r rhyngwyneb LAN, cyfyngwch ef i’r ystod a ddatganwyd, a chadwch gyfeiriad y Pi ei hun allan o’r pwll.

Anfon ymlaen, cyfieithu a’r rheol cau ar fethiant

Mae pedwar peth yn aml yn cael eu disgrifio fel un ac nid ydynt. Nid yw galluogi anfon ymlaen (net.ipv4.ip_forward=1) ond yn dweud wrth y cnewyllyn y caiff symud pecynnau rhwng rhyngwynebau; nid yw’n caniatáu dim ar ei ben ei hun ac nid yw’n gwarantu unrhyw lwybr. Dewis yr allanfa yw penderfyniad llwybro. Caniatáu’r pecyn yw penderfyniad polisi yn y gadwyn forward. Ailysgrifennu ei ffynhonnell yw penderfyniad postrouting. Mae adeiladwaith sy’n gwneud y cyntaf yn unig yn cynhyrchu Pi sy’n anfon traffig cleientiaid allan o’r cyswllt i fyny yn fodlon.

Cyfyngwch y caniatâd i’r ffynonellau a fwriadwyd gennych ac i’r rhyngwyneb y dylai’r traffig ei ddefnyddio, a chynhwyswch y llwybr dychwelyd a’r cyrchfannau sydd eu hangen ar y Pi ei hun. Yna cyfieithwch ar allanfa’r tiwnel os nad yw’r darparwr yn llwybro eich rhagddodiad LAN yn ôl atoch. llawlyfr nftables yn trin anfon ymlaen, allbwn lleol a chyfieithu ffynhonnell fel gweithrediadau ar wahân, sef y model meddwl cywir yma.

Y methiant cyffredin yw rheol masquerade lydan ar y rhyngwyneb corfforol. Yna mae’r traffig yn cyrraedd y rhyngrwyd drwy lwybr yr ISP tra’i fod, o safbwynt y cleient, yn edrych yn union fel VPN sy’n gweithio. Nid yw’n profi dim. Cadwch gyfieithu’n rhwym wrth yr allanfa a ddatganwyd, a chadwch eich rheolau yn y mur tân y mae’r gwesteiwr eisoes yn ei ddefnyddio yn lle ychwanegu set reolau gystadleuol sy’n fflysio cadwyn postrouting a rennir.

Yna deliwch ag absenoldeb y tiwnel. Mae proffil cleient sy’n gosod llwybr diofyn lydan hefyd yn golygu, pan fo’r tiwnel yn cwympo, y gall y llwybr diofyn arferol ddod yn ôl ac mae traffig y cleient yn dychwelyd yn dawel i’r cyswllt i fyny. Lle nad yw cwympo’n ôl i destun clir yn dderbyniol, rhaid i’r polisi forward wrthod traffig cleient-i-gyswllt-i-fyny yn eglur, yn y cyflwr lle mae llwybr y VPN wedi mynd. Ysgrifennwch hynny fel rheol wrthod, nid fel rhagdybiaeth. Mae cludiant amgryptiedig y Pi ei hun i bartner y VPN yn lif local-output ar wahân a rhaid iddo aros yn ganiataol, neu ni all y tiwnel ddod yn ôl byth.

Mae DNS ac IPv6 angen eu hateb eu hunain

Os yw cleientiaid yn defnyddio’r Pi fel datryswr, maent yn taro gwrandäwr lleol ac mae’r Pi yn cychwyn ymholiad newydd. Mae’r ymholiad i fyny hwnnw’n dilyn llwybr y Pi ei hun, nid y rheol forward a ysgrifennwyd gennych ar gyfer cleientiaid, felly mae llwybr cleient drwy’r tiwnel yn unig ynghyd â datryswr sy’n mynd allan yn uniongyrchol yn ollyngiad heb unrhyw neges gwall. Penderfynwch yn fwriadol: datryswr a gyrhaeddir dros y tiwnel, neu un lleol a dderbyniwch fel un uniongyrchol, a gwnewch bolisi allbwn y Pi ei hun yn cyfateb i’r penderfyniad hwnnw.

Mae IPv6 yn achos ar wahân eto. Nid yw rheol forward ar gyfer IPv4 yn cyfyngu ar ddim ynghylch IPv6, a gall hysbysebion llwybrydd ar y cyswllt i fyny roi i’r Pi, a thrwyddo i’r segment sydd ynghlwm, ail lwybr diofyn sy’n osgoi eich polisi. Naill ai rhowch lwybr gwarchodedig ei hun i IPv6 ar yr un egwyddor, neu cyfyngwch ef yn eglur ar segment y cleientiaid a dywedwch hynny.

Profwch y ffin cyn ymddiried ynddi

Derbyniwch y cynllun yn unig ar ôl pedwar gwiriad ar wahân, oherwydd mae’r prawf sengl demtasiwn — agor porwr ar un cleient — yn pasio mewn sawl cyflwr toredig.

Cadarnhewch fod un cleient go iawn yn cyrraedd y rhyngrwyd drwy’r tiwnel, yna cadarnhewch na all yr un cleient gyrraedd y rhyngrwyd gyda’r tiwnel i lawr. Cadarnhewch fod datrysiad DNS yn gweithio a bod yr ymholiad yn gadael lle y bwriadwyd. Cadarnhewch fod cludiant y Pi ei hun yn dal i weithio ar ôl ailgychwyn y tiwnel, ac nad yw adferiad yn gofyn am ailgychwyn y peiriant. Yn olaf, gwiriwch ddyfais na ddewiswyd gennych: o dan gynllun A dylai barhau i weithio’n normal, ac o dan gynllun B ni ddylai fodoli o gwbl ar y segment hwnnw.

• Mae dau borth a rheol wrthod yn rhoi gorfodaeth; mae un porth ac opsiwn DHCP yn rhoi cyngor.
• Mae cyfieithu ar y rhyngwyneb anghywir yn edrych fel llwyddiant ac nid yw.
• Mae traffig y Pi ei hun, DNS ac IPv6 pob un angen penderfyniad, nid casgliad.