Sut i binio un ap Linux i VPN gyda rheolau UID

Pinio un rhaglen i VPN ar Linux yw problem llwybro yn bennaf, a rheol y wal dân yn unig sy'n penderfynu beth sy'n digwydd ar ôl i'r llwybr gael ei ddewis. Os byddwch yn cyfateb UID y rhaglen yn OUTPUT cyn i'r twnel feddiannu'r llwybr diofyn, mae'r rheol yn gollwng yn union y traffig yr oeddech am ei amddiffyn. Ni all yr un rheol weld y broses ddatryswydd sy'n ateb ymholiadau DNS y rhaglen chwaith. Gosodwch y drefn yn gywir ac mae un cyfrif heb fraint yn dod yn ddetholydd twnel hollt dibynadwy.

Rhowch lwybr i'r cyfrif cyn dyfarniad

Mae cyfateb perchennog yn ateb un cwestiwn: a adeiladodd soced lleol sy'n perthyn i'r UID hwn y pecyn? Nid yw'n dewis rhyngwyneb ac ni all symud traffig y mae'r prif dabl eisoes yn ei anfon allan drwy'r NIC ffisegol. Dyna pam mae rheol UID heb lwybr cyfatebol yn blocio'r rhaglen yn lle ei hailgyfeirio.

Anfonwch y cyfrif i lawr ei dabl ei hun yn gyntaf, wedyn gadewch i'r wal dân gadarnhau'r canlyniad. Mae hyn yn gweithio ar waelodfa y mae ei iproute2 yn deall uidrange, y mae ip rule help yn ei adrodd mewn un llinell. Mae tabl 100 yn dal llwybr diofyn drwy'r twnel, ac mae'r rheol yn anfon UID 1000 yn unig i'r tabl hwnnw. Arhosodd popeth arall ar y prif dabl ac yn parhau i ddefnyddio'r cyswllt ffisegol.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

Mae ail gyfrif sy'n awyddus am dwnel gwahanol yn cael tabl 101 a'i reol ei hun, oherwydd ni all dau broffil fod yn berchen ar y llwybr diofyn yn yr un tabl gyda'i gilydd. Mae proffiliau NetworkManager yn system-gyfan, felly mae'r rhan hon yn aros â llaw, ac mae'r rheolau'n diflannu ar ailgychwyn oni bai bod rhywbeth yn eu hadfer. Ysgrifennwch y tablau mewn sgript cychwyn wrth ymyl diffiniad y twnel fel na all ailosod adael un cyfrif ar y llwybr anghywir.

Pam mae'r eithriad loopback yn lladd y twnel

Mae'r rhan fwyaf o fersiynau copi o'r rheol yn gollwng pob pecyn nad yw'n gadael drwy loopback. Nid loopback yw'r twnel, felly mae'r ffurf honno'n gollwng traffig y twnel hefyd, ac mae'r canlyniad yn edrych fel VPN marw yn hytrach na chamgymeriad wal dân.

Pan fydd OUTPUT yn rhedeg, mae'r cnewyllyn eisoes wedi dewis rhyngwyneb allan, felly -o cymharir â ateb y llwybr, nid â phennawd y pecyn. Mae cyfateb perchennog yn cael ei ymgynghori yn OUTPUT a POSTROUTING yn unig, ac nid yw pecynnau a anfonwyd ymlaen yn cario soced iddo ei ddarllen. Golyga'r cyfuniad hwnnw fod yn rhaid i'r eithriad enwi rhyngwyneb y twnel a gwadu'r cyfatebiad hwnnw, yn hytrach na gwadu loopback.

Haedda loopback ei ACCEPT ei hun uwchben y DROP o hyd, oherwydd mae'r pecyn DNS cyntaf o'r rhaglen yn mynd i'r stub lleol dros lo. Rhowch y ddwy reol yn y drefn hon ac mae'r cyfrif yn cyrraedd y stub, wedyn y twnel, a dim byd arall.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

Mae IPv6 yn set rheolau ar wahân, ac mae pâr sy'n cwmpasu v4 yn unig yn gadael ip6tables heb ei gyffwrdd. Byddai rhaglen sy'n ffafrio cofnodion AAAA wedyn yn gadael drwy'r cyswllt ffisegol heb gyrraedd y DROP o gwbl. Adlewyrchwch y ddwy reol yn ip6tables, neu analluogi IPv6 ar y waelodfa pan nad yw'r twnel yn cario cyfeiriad v6. Mae rheolau a ychwanegwyd â llaw hefyd yn diflannu ar ailgychwyn, felly arbedwch nhw gyda netfilter-persistent save neu ailadeiladwch yr un rhesymeg fel tabl nftables a lwythir gan yr uned gychwyn.

Mae atebion DNS yn dod o broses arall

Mae ymholiad y rhaglen i 127.0.0.53 yn pasio ACCEPT loopback, a dyna lle mae cyfateb UID yn stopio. Mae'r datryswydd stub yn anfon ymlaen i fyny o'i gyfrif gwasanaeth ei hun, felly rheol sy'n allweddol i vpnapp ni fydd byth yn gweld yr ail ymholiad. Os yw'r datryswydd yn dewis gweinydd LAN ar gyfer y cyswllt, mae atebion yn dod yn ôl dros y NIC ffisegol tra bod pecynnau'r rhaglen ei hun yn aros yn y twnel. Y canlyniad gweladwy yw twnel sy'n gweithio gydag enwau wedi torri, neu enwau a atebir gan weinydd nad oeddech wedi dewis.

Trwsiwch ddatrysiad enwau ar gyswllt y twnel, nid ar y rhaglen. Rhowch weinydd DNS a pharth llwybro i broffil y twnel, wedyn cadarnhewch gyda resolvectl query a resolvectl status tun0 bod y datryswydd yn ei ddefnyddio ar gyfer yr enwau sy'n bwysig. Y tu mewn i ofod enw rhwydwaith mae'r broblem yn diflannu, oherwydd gŵyr datryswydd y gofod am y twnel yn unig.

Gwiriwch y rheol o'r cyfrif ei hun

Gofynnwch i'r cnewyllyn ba lwybr y mae UID yn ei gael, wedyn gwnewch gais fel y cyfrif hwnnw a chymharwch y cyfeiriad ymadael â chyfeiriad eich cyfrif eich hun. Os bydd y ddau'n adrodd yr un cyfeiriad, mae'r rheol yn cyfateb rhywbeth heblaw'r traffig a phrofwyd gennych. Mae'r gorchymyn cyntaf isod yn dangos y chwiliad llwybr heb anfon pecyn, sy'n gwahanu camgymeriad llwybro oddi wrth gamgymeriad wal dân.

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

Mae cyfrifwyr yn dangos a danio rheol erioed. Rhedwch iptables -vnL OUTPUT, darllenwch y cyfrif pecynnau wrth ymyl pob rheol, a thriniwch sero wrth ymyl y DROP ar ôl traffig go iawn fel camgymeriad cyfateb.

Mae traffig a anfonwyd ymlaen y tu allan i'r dyluniad hwn. Nid oes gan gynhwysydd neu VM y tu ôl i bont unrhyw soced lleol sy'n eiddo i vpnapp, felly ni fydd cyfateb perchennog byth yn danio ac mae'r pecynnau hynny'n dilyn polisi FORWARD yn lle hynny. Os rhaid gorchuddio'r llwyth gwaith hwnnw, profwch ef ar wahân ac ysgrifennwch bolisi wedi'i allweddoli i'r bont neu i gyfeiriad y cynhwysydd. Mae'r dyluniad yn dal pan fydd y tabl, yr eithriad rhyngwyneb, y datryswydd a rheolau v6 i gyd yn pwyntio'r un ffordd; gadewch unrhyw un ohonynt allan ac mae'r cyfrif naill ai'n gollwng neu'n colli cysylltiad.