Gateway-i strehon faqen e vet të administrimit: adresë e brendshme apo publike

Një faqe administrimi përgjigjet nga një telefon me të dhëna celulare dhe skadon nga një laptop i bashkuar me VPN. Asgjë në tunel nuk është prishur, sepse kërkesa nuk hyn kurrë në të. Emri i hostit zgjidhet në adresën publike të gateway-it, dhe ajo adresë arrihet vetëm nga jashtë tunelit që ai përfundon. Rregullimi do të thotë t'i japësh shërbimit një hyrje private, jo të zhvendosësh pikën fundore të jashtme.

Faqja ngarkohet nga jashtë dhe jo përmes tunelit

Po krahasohen dy kërkesa të ndryshme. Nga të dhënat celulare shfletuesi arrin drejtpërdrejt adresën publike. Nga brenda tunelit i njëjti emër zgjidhet në të njëjtën adresë publike, dhe paketa tani duhet të dalë përmes tunelit për të arritur një adresë në anën e vet të largët të tunelit. I njëjti emër, e njëjta adresë, dy pozicione shumë të ndryshme.

Një rrugë destinacioni zgjedh një adresë, jo një port. Asgjë në tabelën e rrugëzimit nuk e di që porti 443 është për administrim dhe porti 1194 është transporti, prandaj të dyja trajtohen si e njëjta destinacion.

Për këtë arsye faqja ndonjëherë funksionon dhe ndonjëherë jo, në varësi të emrit dhe rrjetit që përdori klienti. Është problem rruge dhe jo problem vërtetimi. Të dy klientët vërtetohen shumë mirë.

Mbajeni pikën fundore të jashtme të arritshme

Profilet e tunelit të plotë kanë nevojë për një rrugë përjashtimi për pikën fundore të VPN, dhe opsioni redirect-gateway i OpenVPN dokumenton pikërisht këtë: pika fundore e largët mban një rrugë përmes gateway-it që ekzistonte më parë, që tuneli të mos rrugëzojë në vetvete. Hiqni atë përjashtim dhe transporti i kriptuar ndjek tunelin, gjë që e përfundon sesionin në një lak. Pikërisht ai përjashtim është arsyeja pse adresa e pikës fundore mbetet e arritshme nga brenda tunelit.

Pasoja është që adresa publike mbetet e arritshme nga klienti, dhe për këtë arsye një kërkesë e shfletuesit drejt asaj adrese mund të ndjekë të njëjtin përjashtim dhe të dalë pa hyrë në tunel. Përjashtimi bën punën e vet, dhe dëmin e bën emri.

Lexoni vendimin e rrugës dhe jo listën e ndërfaqeve përpara se të ndryshoni diçka. Komandat më poshtë shtypin vendimin dhe jo inventarin. Ekzekutoni ato nga klienti që dështoi.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Nëse kërkimi tregon rrugën e pikës fundore përmes gateway-it fizik, sjellja është e saktë dhe faqja e administrimit thjesht po dërgohet në rrugën e gabuar. Aty zgjidhja e emrave bëhet rregullimi.

Jepini shërbimit një emër privat

Shërbimi ka nevojë për një emër që zgjidhet në adresën e gateway-it brenda tunelit, duke ruajtur njëkohësisht semantikën e certifikatës dhe të emrit të hostit që pret aplikacioni. Një regjistrim zone privat për emrin e administrimit është përgjigjja e zakonshme, dhe e lë emrin e transportit të paprekur.

Mos e ridrejtoni emrin e transportit në adresën e brendshme, sepse krijimi i radhës i tunelit do të përpiqej të arrinte një adresë që ekziston vetëm brenda një tuneli. Ai gabim prodhon një VPN që funksionon saktësisht një herë.

Kontrolloni edhe të dy familjet e adresave, sepse një regjistrim AAAA i lënë pas mund ta dërgojë shfletuesin diku që plani privat nuk e mbuloi kurrë.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Përshtatni politikën me vendin ku ekzekutohet procesi

Një proces vendas që dëgjon në gateway arrihet përmes rrugës së hyrjes lokale, prandaj zinxhiri i hyrjes dhe lidhja e soketit vendosin nëse kërkesa pranohet. Rregullat e përcjelljes dhe përcjellja IP nuk e bëjnë një dëgjues lokal të përgjigjet. Lejoni burimet e tunelit në politikën e hyrjes dhe konfirmoni që procesi është i lidhur me një adresë që tuneli mund ta arrijë.

Një kontejner i publikuar në një port hosti ndjek një rrugë tjetër, sepse paketa përkthehet sipas destinacionit dhe përcillet. Ajo kërkesë takon politikën e përcjelljes së hostit dhe rregullat e vetë Docker, prandaj një dëgjues vendas që funksionon mund të bashkëjetojë me një kontejner që refuzon të njëjtin port.

Rendi i nisjes ka rëndësi në të dyja rastet, sepse një lidhje me një adresë që shfaqet vetëm pasi tuneli ngrihet dështon në heshtje gjatë nisjes.

Kontrolloni aksesin privat dhe një rrugë publike të refuzuar

Bëni një kërkesë të re me emër nga një klient i autorizuar, me kontrollet e identitetit të vetë aplikacionit të paprekura. Pastaj provoni të njëjtin shërbim nga jashtë tunelit dhe konfirmoni që nuk përgjigjet. Një emër privat është lehtësi dhe jo kufizim, dhe një dëgjues ende i lidhur me adresën publike është ende i ekspozuar. Pikërisht kontrolli i fundit është ai që shumica e rishikimeve e anashkalojnë.

Lexoni lidhjet dhe gjendjen e filtrit, jo emrin e hostit që morën përdoruesit. Ekspozimi është veti e soketit dhe jo e emrit. Ky dallim i mbijeton çdo ndryshimi të DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Kur kërkesa e brendshme kthen faqen dhe kërkesa e jashtme skadon, shërbimi ka një rrugë private të qëllimshme dhe transporti mbetet i arritshëm. Kur kërkesa e jashtme ende përgjigjet, dëgjuesi ose një zë kontejneri i publikuar duhet të ngushtohet përpara se dikush ta përshkruajë shërbimin si vetëm të brendshëm.