Linux aplikazio bat VPN batera lotzeko UID arauekin

Programa bat Linuxen VPN batera lotzea batez ere bideratze arazoa da, eta suebakiaren arauak soilik erabakitzen du zer gertatzen den bidea hautatu ondoren. Programaren UIDa OUTPUTen parekatzen baduzu tunelak lehenetsitako bidea izan aurretik, arauak babestu nahi zenuen trafikoa bera uzten du alde batera. Arau berak ez du programaren DNS kontsultak erantzuten dituen resolver prozesua ere ikusten. Jarri ordena behar bezala eta pribilegiorik gabeko kontu bat tunel zatituaren hautatzaile fidagarria bihurtzen da.

Eman kontuari bidea epaia baino lehen

Jabearen parekatzeak galdera bat erantzuten du: UID honi dagokion tokiko socket batek eraiki du paketea? Ez du interfazerik hautatzen eta ezin du taula nagusiak jadanik NIC fisikoan zehar bidaltzen duen trafikoa mugitu. Horregatik, bat etorrizko biderik gabeko UID arau batek programa blokeatzen du birbideratu ordez.

Bidali kontua lehenengo bere taula propioa zehar, eta gero utzi suebakiari emaitza baieztatzen. Hau iproute2-ren uidrange ulertzen duen ostalari batean funtzionatzen du, eta hori ip rule help lerro bakarrean jakinarazten du. 100 taulak tunelaren zehar lehenetsitako bidea du, eta arauak UID 1000 bakarrik bidaltzen du taula horretara. Gainerako guztia taula nagusian geratzen da eta lotura fisikoa erabiltzen jarraitzen du.

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

Beste tunel bat behar duen bigarren kontu batek 101 taula eta bere araua jasotzen ditu, bi profilek ezin baitute aldi berean lehenetsitako bidea taula berean izan. NetworkManager profilek sistema osokoak dira, beraz zati hau eskuzkoa izaten jarraitzen du, eta arauak berrabiaraztean desagertzen dira zerbaitk berreskuratzen ez baditu. Idatzi taulek tunelaren definizioaren ondoan dagoen abio script batean, berriz konektatzeak kontu bat bide okerrean utz ez dezan.

Zergatik hiltzen du loopback salbuespenak tunela

Arauaren bertsio kopiatuen gehienek loopback-etik irteten ez den pakete guztiak botatzen dituzte. Tunela ez da loopback, beraz forma horrek tunelaren trafikoa ere botatzen du, eta emaitza VPN hil baten itxura du, suebakiaren akatsaren ordez.

OUTPUT exekutatzen denean, kernelak irteerako interfazea hautatu du jada, beraz -o bidearen erantzunarekin alderatzen da, ez paketearen goiburuarekin. Jabearen parekatzea OUTPUT eta POSTROUTING ataletan soilik kontsultatzen da, eta birbidalitako paketeek ez dute socketik har dezan. Konbinazio horrek esan nahi du salbuespenak tunelaren interfazea izendatu eta parekatze hori ukatu behar duela, loopback ukatu ordez.

Loopbackek oraindik merezi du bere ACCEPT DROParen gainetik, programaren lehen DNS paketea tokiko stub-era doalako lo bidez. Jarri bi arauak ordena honetan, eta kontuak stub-era heltzen du, gero tunelera, eta beste inora ez.

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

IPv6 arau multzo bereizia da, eta v4-rako soilik den bikoteak ip6tables ukituta uzten du. AAAA erregistroak nahiago dituen programa batek lotura fisikoan zehar aterako litzateke DROP-era inoiz heldu gabe. Islatu bi arauak ip6tables-n, edo desgaitu IPv6 ostalarian tunelak v6 helbiderik ez daramanean. Eskuz gehitutako arauak ere berrabiaraztean desagertzen dira, beraz gorde itzazu netfilter-persistent save erabiliz edo berreraiki logika bera abio unitateak kargatzen duen nftables taula gisa.

DNS erantzunak beste prozesu batetik datoz

Programaren kontsulta 127.0.0.53-ra loopback ACCEPTetik pasatzen da, eta hor bertan gelditzen da UID parekatzea. Stub resolver-ak bere zerbitzu kontutik gorantz birbidaltzen du, beraz vpnapp-ari lotutako arauak ez du inoiz bigarren kontsulta ikusten. Resolver-ak loturarako LAN zerbitzari bat hautatzen badu, erantzunak NIC fisikoaren bidez itzultzen dira, programaren pakete propioak tunelan geratzen diren bitartean. Ikusgai den emaitza tunel funtzional bat da izen hautsiekin, edo zuk hautatu ez zenuen zerbitzari batek erantzundako izenekin.

Konpondu izenen ebazpena tunelaren loturan, ez aplikazioan. Eman tunel profilari DNS zerbitzari bat eta bideratze domeinu bat, eta gero baieztatu resolvectl query eta resolvectl status tun0 erabilita resolver-ak garrantzitsuak diren izenetarako erabiltzen duela. Sare izen-espazio baten barruan arazoa desagertzen da, espazioko resolver-ak tunela baino ez baitu ezagutzen.

Egiaztatu araua kontutik bertatik

Galdetu kernelari zein bide jasotzen duen UID batek, gero egin eskaera kontu horren izenean eta konparatu irteera helbidea zure kontuarenarekin. Biek helbide bera jakinarazten badute, arauak probatu duzun trafikoaz bestelako zerbait parekatzen du. Beheko lehen komandoak bide-kontsulta erakusten du paketerik bidali gabe, eta horrek bideratze akatsa suebaki akatsetik bereizten du.

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

Kontagailuek arau batek inoiz jotzen zuen erakusten dute. Exekutatu iptables -vnL OUTPUT, irakurri pakete kopurua arau bakoitzaren ondoan, eta tratatu DROParen ondoan dagoen zeroa trafiko erreala izan ondoren parekatze akats gisa.

Birbidalitako trafikoa diseinu honetatik kanpo dago. Zubi baten atzeko kontenedore edo VM batek ez du vpnapp-ri dagokion tokiko socketik, beraz jabearen parekatzea ez da inoiz aktibatzen eta pakete horiek FORWARD politikari jarraitzen diote. Karga hori estali behar bada, probatu bereizita eta idatzi zubiari edo kontenedorearen helbideari lotutako politika bat. Diseinuak eusten du taula, interfazearen salbuespena, resolver-a eta v6 arauak guztiek norabide bera seinalatzen dutenean; utzi horietako edozein kanpo eta kontuak isuri edo konexioa galduko du.