Si ta lidhni një aplikacion Linux me një VPN me rregulla UID

Lidhja e një programi të vetëm me një VPN në Linux është kryesisht problem rrugëtimi, dhe rregulli i firewall-it vendos vetëm çfarë ndodh pasi zgjidhet rruga. Nëse përputhni UID-në e programit në OUTPUT përpara se tuneli të zotërojë rrugën e paracaktuar, rregulli hedh poshtë pikërisht trafikun që dëshironit të mbronit. I njëjti rregull nuk e sheh as procesin e resolver-it që u përgjigjet kërkesave DNS të programit. Rregulloni rendin dhe një llogari pa privilegje bëhet një përzgjedhës i besueshëm i tunelit të ndarë.

Jepini llogarisë një rrugë para verdiktit

Përputhja e pronarit përgjigjet një pyetjeje: a e ndërtoi paketën një soket lokal që i përket këtij UID? Ajo nuk zgjedh ndërfaqe dhe nuk mund të zhvendosë trafikun që tabela kryesore tashmë e dërgon përmes NIC-it fizik. Prandaj një rregull UID pa rrugë përputhëse e bllokon programin në vend që ta ridrejtojë.

Kalojeni llogarinë fillimisht nëpër tabelën e saj, dhe pastaj lëreni firewall-in të konfirmojë rezultatin. Kjo funksionon në një host, iproute2 i të cilit kupton uidrange, çka ip rule help e raporton në një rresht. Tabela 100 mban një rrugë të paracaktuar përmes tunelit, dhe rregulli dërgon vetëm UID 1000 në atë tabelë. Çdo gjë tjetër mbetet në tabelën kryesore dhe vazhdon të përdorë lidhjen fizike.

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

Një llogari e dytë që ka nevojë për një tunel tjetër merr tabelën 101 dhe rregullin e vet, sepse dy profile nuk mund të zotërojnë të dy rrugën e paracaktuar në të njëjtën tabelë. Profilet NetworkManager janë në nivel sistemi, prandaj kjo pjesë mbetet manuale, dhe rregullat zhduken në rindezje nëse diçka nuk i rikthen. Shkruani tabelat në një skript nisjeje pranë përkufizimit të tunelit, që një rilidhje të mos lërë një llogari në rrugën e gabuar.

Pse përjashtimi i loopback-it e vret tunelin

Shumica e versioneve të kopjuara të rregullit hedhin çdo paketë që nuk del përmes loopback-it. Tuneli nuk është loopback, prandaj ajo formë hedh edhe trafikun e tunelit, dhe rezultati duket si VPN i vdekur dhe jo si gabim i firewall-it.

Kur OUTPUT ekzekutohet, kernel-i ka zgjedhur tashmë një ndërfaqe dalëse, prandaj -o krahasohet me përgjigjen e rrugës dhe jo me kokën e paketës. Përputhja e pronarit konsultohet vetëm në OUTPUT dhe POSTROUTING, dhe paketat e përcjella nuk mbajnë asnjë soket që ajo të lexojë. Ky kombinim do të thotë që përjashtimi duhet të emërtojë ndërfaqen e tunelit dhe ta mohojë atë përputhje, në vend që të mohojë loopback-un.

Loopback ende e meriton ACCEPT-in e vet mbi DROP, sepse paketa e parë DNS nga programi shkon te stub-i lokal përmes lo. Vendosini dy rregullat në këtë rend, dhe llogaria arrin stub-in, pastaj tunelin, dhe asgjë tjetër.

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 është një grup rregullash i veçantë, dhe një çift vetëm për v4 e lë ip6tables të paprekur. Një program që preferon regjistrimet AAAA do të dilte atëherë përmes lidhjes fizike pa arritur kurrë te DROP. Pasqyroini të dyja rregullat në ip6tables, ose çaktivizoni IPv6 në host kur tuneli nuk mbart asnjë adresë v6. Rregullat e shtuara me dorë zhduken gjithashtu në rindezje, prandaj ruajini me netfilter-persistent save ose rindërtoni të njëjtën logjikë si tabelë nftables që ngarkohet nga njësia e nisjes.

Përgjigjet DNS vijnë nga një proces tjetër

Kërkesa e programit drejt 127.0.0.53 kalon ACCEPT-in e loopback, dhe pikërisht aty ndalon përputhja e UID-së. Resolver-i stub përcjell lart nga llogaria e vet e shërbimit, prandaj një rregull i lidhur me vpnapp nuk e sheh kurrë kërkesën e dytë. Nëse resolver-i zgjedh një server LAN për lidhjen, përgjigjet kthehen përmes NIC-it fizik ndërsa paketat e vetë programit mbeten në tunel. Rezultati i dukshëm është një tunel që punon me emra të prishur, ose emra që përgjigjen nga një server që nuk e keni zgjedhur.

Rregulloni zgjidhjen e emrave në lidhjen e tunelit, jo në aplikacion. Jepini profilit të tunelit një server DNS dhe një domen rrugëtimi, dhe pastaj konfirmoni me resolvectl query dhe resolvectl status tun0 që resolver-i e përdor atë për emrat që kanë rëndësi. Brenda një hapësire emrash rrjeti problemi zhduket, sepse resolver-i i hapësirës njeh vetëm tunelin.

Kontrolloni rregullin nga vetë llogaria

Pyetni kernel-in cilën rrugë merr një UID, pastaj bëni një kërkesë si ajo llogari dhe krahasoni adresën e daljes me atë të llogarisë tuaj. Nëse të dyja raportojnë të njëjtën adresë, rregulli përputhet me diçka tjetër dhe jo me trafikun që provuat. Komanda e parë më poshtë tregon kërkimin e rrugës pa dërguar paketë, çka ndan një gabim rrugëtimi nga një gabim firewall-i.

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

Numëruesit tregojnë nëse një rregull është ndezur ndonjëherë. Ekzekutoni iptables -vnL OUTPUT, lexoni numrin e paketave pranë secilit rregull, dhe trajtoni një zero pranë DROP pas trafikut real si gabim përputhjeje.

Trafiku i përcjellë qëndron jashtë këtij dizajni. Një kontejner ose VM pas një ure nuk ka soket lokal në pronësi të vpnapp, prandaj përputhja e pronarit nuk ndizet kurrë dhe ato paketa ndjekin politikën FORWARD. Nëse ajo ngarkesë duhet mbuluar, provojeni veçmas dhe shkruani një politikë të lidhur me urën ose adresën e kontejnerit. Dizajni qëndron kur tabela, përjashtimi i ndërfaqes, resolver-i dhe rregullat v6 tregojnë të gjithë të njëjtin drejtim; lini jashtë cilindo prej tyre dhe llogaria ose rrjedh ose humbet lidhjen.