Rregullat që përcjellin të gjitha portat mund të gëlltisin listenerin tuaj WireGuard

Një gateway publik tashmë ekzekuton WireGuard në UDP 51820, SSH në 22 dhe një aplikacion që duhet të jetë i arritshëm nga interneti. Rregulli joshës përcjell çdo port te peer-i dhe e shpall punën të kryer. Në një gateway WireGuard ai rregull mund të kapë transportin e vetë tunelit dhe t'ju mbyllë jashtë makinës që e përfundon. Publikimi është një vendim rrugëtimi me një përjashtim për planin e kontrollit, jo një rresht i vetëm DNAT.

Hyrje publike apo hyrje përmes tunelit: zgjidhni një

Publikimi i një shërbimi krijon një pikë të re hyrjeje në internet. Nuk është e njëjta gjë me dhënien e anëtarësisë VPN një peer-i, sepse vizitori nuk hyn kurrë në tunel dhe gateway bëhet fytyra publike e backend-it. Ai dallim vendos audiencën e rregullit dhe certifikatën e tij.

Ndërfaqet administrative rrallë i përkasin atij vendi. Një faqe administrimi e arritur nga klientë VPN të autorizuar e mban sipërfaqen e sulmit brenda tunelit dhe shmang ekspozimin e një formulari hyrjeje ndaj skanimit arbitrar. Pikat fundore publike të aplikacionit kanë ende nevojë për certifikatën e tyre TLS, autentikimin dhe kufizimin e ritmit; kërcimi i kriptuar WireGuard nuk e mbron pjesën e vizitorit deri te gateway.

Nëse shërbimi vërtet duhet të jetë publik, shkruani emrin e hostit, certifikatën që e mbulon dhe vargjet e vizitorëve që duhet ta arrijnë. Këto tre fakte vendosin më vonë formën e rregullit dhe politikën e filtrimit. Çdo gjë jashtë tyre është zgjerim i fushëveprimit në një listener publik.

Një port hyn, një backend del

Përdorni një port të vetëm publik dhe një shërbim të vetëm backend. Në këtë shembull eth0 mban adresën publike 198.51.100.20, adresa e tunelit të gateway është 10.200.0.1 dhe peer-i ekzekuton aplikacionin në 10.200.0.7. TCP publik 9443 mapohet në TCP 8443 të peer-it:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

Rregulli SNAT përputhet me backend-in e përkthyer dhe destinacionin origjinal publik, kështu që një lidhje tjetër me të njëjtin shërbim backend mbetet jashtë këtij mapimi. Ai gjithashtu e fsheh adresën e vizitorit nga peer-i, dhe ky është kompromisi që e bën një kthim të rrugëtuar me ruajtje të burimit një dizajn të veçantë. Referenca e shtojcave të iptables dokumenton të dy objektivat dhe opsionet e tyre të përputhjes.

Përcjellja duhet ende të aktivizohet, dhe zinxhiri i filtrimit ka nevojë për një leje për destinacionin dhe portën e përkthyer plus përgjigjet e vendosura. Zinxhiri FORWARD e sheh destinacionin e përkthyer pas DNAT, kështu që një rregull i shkruar kundrejt adresës publike nuk përputhet me paketën e përcjellë. Shkruani lejen kundrejt tuple-it të backend-it, jo atij publik.

Peer-i duhet ta pranojë lidhjen e shërbimit nga adresa e tunelit të gateway dhe ta dërgojë përgjigjen përmes tunelit. AllowedIPs i tij duhet të autorizojë burimin që merr vërtet, i cili nën përkthimin e burimit është adresa e tunelit të gateway, dhe një zë i gjerë 0.0.0.0/0 në çdo peer nuk kërkohet për këtë dizajn. Ajo që i hedh poshtë trafikut të kthimit është një peer lista e të cilit e lë jashtë atë adresë, ose një dizajn me ruajtje burimi që përcjell në vend të saj adresën e vetë vizitorit, prandaj kontrolloni burimin që peer-i sheh vërtet, jo atë në rregullin tuaj.

Mbajini listenerët e vetë gateway jashtë rregullit

Zëvendësoni përputhjen e portës me një rregull që mbulon çdo destinacion TCP dhe UDP, dhe socket-i WireGuard i vetë gateway bie brenda tij. Përkthimi i destinacionit ndodh përpara se makina të vendosë që një paketë është lokale, kështu që UDP 51820 mund të përfundojë te peer-i në vend të procesit që mban çdo lidhje peer-i. Rregulli ngarkohet me sukses dhe tuneli vdes, një dështim i vështirë për t'u lexuar nga ana e peer-it.

SSH, agjentët e monitorimit dhe çdo shërbim tjetër i strehuar në gateway kanë të njëjtin ekspozim. Një rregull që përcjell gjithçka nuk e dallon planin e kontrollit nga aplikacioni i publikuar, dhe rindezja e parë pas ndryshimit është momenti kur bllokimi bëhet i dukshëm. Rregulli që kap gjithçka nuk paralajmëron për shërbimin që e merr në heshtje. E zbuloni kur dështon lidhja tjetër.

Nëse përcjellja e gjerë vërtet nevojitet, rezervoni portat e kontrollit përpara rregullit që kap gjithçka ose përdorni një adresë publike të veçantë për publikimin. Opsioni i dytë është më i pastër sepse adresa e kontrollit mban politikën e vet, por ofruesi duhet ta japë atë adresë; shtimi i një rekordi DNS nuk alokon një.

Përcjellja e gjerë TCP dhe UDP nuk është as të gjitha protokollet. ICMP, IPv6, reagimi i path-MTU dhe transporti i jashtëm i VPN kanë nevojë për politikën e vet, dhe një rregull që mbulon TCP dhe UDP i lë ato raste zinxhirit të parazgjedhur.

Zgjidhni modelin përpara se të shkruani rregulla

Katër forma mbulojnë shumicën e publikimeve nga një gateway, dhe zgjedhja varet nga sa shërbime ekzekutoni dhe sa rrezik në planin e kontrollit mund të duroni. Tabela më poshtë i rendit nga më e ngushta te më e gjera.

Filloni me modelin e ngushtë edhe nëse prisni më shumë shërbime më vonë. Është më i lehtë për t'u audituar, dhe shndërrimi i një grupi rregullash të ngushta në një rregull të rishikuar që kap gjithçka është më i thjeshtë sesa të zbuloni cilin listener kapi një rregull i gjerë. Cilindo model të zgjidhni, mbajini rregullat te pronari i firewall-it. Zbatimi i rreshtave iptables pranë një konfigurimi UFW ose nftables që menaxhon të njëjtat zinxhirë prodhon një politikë që ndryshon sipas rendit të nisjes.

Vërtetoni publikimin dhe rrugën e kontrollit

Provoni nga një klient i jashtëm i autorizuar duke përdorur emrin e hostit të miratuar dhe një certifikatë të vlefshme për të. Konfirmoni cili backend u përgjigj, pastaj kontrolloni që portat publike të palidhura mbeten të refuzuara. Një kontroll certifikate i çaktivizuar nuk është test HTTPS i kaluar, dhe një lidhje që arrin backend-in e gabuar është më e keqe se një e dështuar.

Pas kësaj verifikoni vetë gateway-n: lidhni një peer WireGuard, hapni një sesion SSH dhe konfirmoni që monitorimi ende raporton. Shërbimi i publikuar mund të funksionojë ndërsa plani i kontrollit është i prishur, prandaj të dy kontrollet i përkasin të njëjtës dritare ndryshimi. Rindizni një herë për të provuar që rregullat rizbatohen në rendin e pritur, pastaj hiqni publikimin dhe konfirmoni që heqja përputhet vërtet me shtimin. Një grup i madh shtimesh në nisje me pastrim të paplotë është mënyra se si një test i përkohshëm bëhet hapje e përhershme.