UFW e hedh serverin DNS të VPN-së sapo tuneli ngrihet
Politika e mohimit të parazgjedhur e UFW mbulon edhe ndërfaqen e tunelit. Rendit trafikun sipas drejtimit, lejo zgjidhësin e shtyrë në tun0 dhe më pas hap rrugën e jashtme.
Emrat ndalojnë së zgjidhuri në momentin që VPN lidhet, ndërsa një ping drejt një adrese publike ende përgjigjet dhe statusi i firewall-it nuk tregon asgjë që duket gabim. Në politikë nuk ndryshoi asgjë; ajo që ndryshoi është se u shfaq një ndërfaqe e re, dhe mohimi i parazgjedhur e mbulon që nga paketa e parë. UFW vendos sipas drejtimit dhe ndërfaqes, prandaj një rregull i shkruar për lidhjen pa tel nuk thotë asgjë për trafikun që del nga tuneli. Rregullimi është një grusht rregullash të ngushta të zbatuara në një rend të caktuar.
Simptoma shfaqet vetëm pasi tuneli të jetë ngritur
Politika e mohimit të parazgjedhur bën saktësisht atë që i është thënë: çdo gjë pa një rregull përputhës refuzohet, në çdo ndërfaqe që ekziston. Tuneli nuk ekzistonte kur u shkruan rregullat, prandaj asnjë prej tyre nuk mund ta kapë, dhe mohimi që ishte gjithmonë aty tani zbatohet për zgjidhjen e emrave. Trafiku i drejtpërdrejtë drejt një adrese fjalëpërfjalë mund të funksionojë ende kur e mbulon një leje më e gjerë, dhe për këtë arsye një ping drejt një zgjidhësi publik ka sukses ndërsa kërkimi i një emri dështon. Hendeku është një rregull për një ndërfaqe që politika nuk e ka parë kurrë.
Kjo shpjegon gjithashtu pse dështimi kthehet pastër: hiq tunelin dhe emrat zgjidhen përsëri, sepse kërkesa kthehet në një ndërfaqe që ka rregulla. Një politikë që dështon vetëm sa kohë tuneli është lart nuk është problem DNS, dhe rregullimi i vetë zgjidhësit humb më shumë kohë këtu. Lexo listën e ndërfaqeve përpara se të lexosh konfigurimin e zgjidhësit.
Tre drejtime, tre grupe rregullash të ndryshme
Një sesion prek rregulla në më shumë se një drejtim, dhe një tunel shton një ndërfaqe të dytë pothuajse në secilin prej tyre. Renditja e trafikut së pari sipas drejtimit dhe ndërfaqes e bën pjesën tjetër mekanike, sepse çdo rresht më poshtë kërkon rregullin e vet në vendin e vet. Shembujt përdorin tun0 dhe një pishinë 10.8.0.0/24, prandaj zëvendëso emrat dhe intervalet me ato nga dalja e vetë klientit.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Dy rreshta ngatërrohen shpesh sepse të dy përmendin tunelin. Një rregull për zgjidhësin lejon trafikun që klienti dërgon në tunel, ndërsa një rregull për SSH lejon trafikun që serveri merr prej andej; ata jetojnë në makina të ndryshme dhe dështojnë në mënyrë të pavarur. Rreshti që harrohet më shpesh është i dyti, sepse klienti nuk mund ta ndërtojë fare tunelin derisa trafiku i tij drejt adresës publike të serverit të lejohet. Puno nga lart poshtë dhe çdo dështim ka një shkak të mundshëm.
Një zgjidhës i shtyrë ka nevojë për rregullin e vet
Nëse tuneli mbart DNS varet nga ajo që dërgon serveri. Një server që shtyn një opsion zgjidhësi instalon një adresë private në konfigurimin e klientit, dhe ajo adresë rrugëtohet vetëm përmes tunelit. Nëse serveri nuk shtyn asgjë, klienti mban zgjidhësin që kishte tashmë dhe rregullat më poshtë nuk kanë çfarë të lejojnë. Kontrollo gjendjen e shtyrë dhe rezultatin aktual të kërkesës përpara se të shkruash çdo gjë:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedDalja e statusit emërton zgjidhësin në përdorim dhe lidhjen me të cilën është i lidhur, dhe kërkimi i rrugës pas tij tregon se cila ndërfaqe do të mbante një kërkesë drejt asaj adrese. Kur zgjidhësi qëndron në një lidhje tjetër, problemi është më herët se firewall-i dhe asnjë rregull nuk do të ndihmojë. Kur të dy bien dakord për tunelin, nevojiten dy rregulla, sepse UDP mbart shumicën e kërkesave dhe TCP merr përsipër kur një përgjigje shkurtohet. Shëno të dyja vlerat, sepse janë ato që rregullat do të emërtojnë:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'Hap rrugën e jashtme përpara asaj të brendshme
Klienti duhet të arrijë adresën publike të serverit përpara se të ekzistojë një tunel, prandaj rregulli për të qëndron në lidhjen fizike dhe duhet të jetë në vendin e vet i pari. Një politikë që lejon zgjidhësin por harron serverin e lë klientin plotësisht të paaftë ta ndërtojë tunelin, dhe kjo simptomë zakonisht i faturohet një kill switch. Më pas lejo shërbimet që vërtet i doje përmes tunelit, një rregull i ngushtë në një herë, në vend që të hapësh ndërfaqen në tërësi. Rregullat e ngushta janë arsyeja pse mohimi mund të mbetet në vendin e vet.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'Rendi ka rëndësi gjatë testimit, sepse rregulli i parë është ai që e lejon tunelin të ngrihet fare. Shtoje, lidhu dhe konfirmo se tuneli është lart përpara se të shtosh rregullin e shërbimit, sepse të bësh të dyja njëherësh do të thotë që një dështim nuk të thotë asgjë se cila gjysmë është gabim. Zëvendëso adresën e dokumentacionit më lart me pikën fundore për të cilën është konfiguruar klienti.
Përfundo anën e klientit duke u shkëputur qëllimisht. Mohimi duhet të vazhdojë të refuzojë trafikun që e përjashtove qëllimisht, sepse një zgjidhës që përgjigjet sa kohë tuneli është lart mbulon vetëm gjysmën e një politike që refuzon në rast dyshimi.
Një klient që lidhet nuk është pranuar ende
Serveri ka drejtimin e vet për t'u marrë parasysh, dhe një klient që përfundon shtrëngimin e duarve ende nuk arrin asgjë që ekzekutohet në server derisa serveri ta pranojë. Rregulli i dëgjuesit publik lejon vetëm që tuneli të ekzistojë; nuk e lë trafikun e tunelit të hyjë. Në server këto janë dy rregulla plus një kontroll që shërbimi vërtet dëgjon:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'Pishina në rregull duhet të jetë e barabartë me intervalin që cakton serveri, dhe numri i tunelit duhet të përputhet me atë që krijoi serveri, sepse një rregull për një ndërfaqe tjetër nuk dallohet nga asnjë rregull. limit është i qëllimshëm për një portë administrative, sepse kufizon lidhjet e përsëritura në vend që t'i pranojë pa kufi. Kontrolli i dëgjuesit ndan një portë të mbyllur nga një paketë e hedhur, të cilat nga klienti duken njësoj. As rregullat e numëruara nuk janë e gjithë piktura: rregullat before të UFW dhe çdo rresht nftables i shkruar me dorë përputhen më herët dhe mund të refuzojnë ende një paketë që lista duket se e lejon.