Publikimi i porteve të Docker kundrejt VPN-së: ku shkon përgjigja

Një kontejner i publikuar përgjigjet nga adresa e vet përpara NAT-së së kundërt. Dy modele mund ta mbajnë atë përgjigje në rrugën publike, me kosto të ndryshme.

Pritësi vazhdon t'u përgjigjet SSH pasi ngrihet një VPN me tunel të plotë, ndërsa një shërbim i publikuar me Docker në të njëjtën makinë hesht. Nuk ka asgjë të gabuar te dëgjuesi: kontejneri është duke punuar, hartëzimi i portës ekziston dhe paketa arrin. Kontejneri është i shëndetshëm dhe kërkesa vërtet e arrin atë. Ajo që ndryshon është nga ku fillon përgjigja kur Linux zgjedh rrugën e vet, dhe ky dallim vendos cilin nga dy modelet më poshtë ju nevojitet.

Ndiqni tuple përmes NAT-së së destinacionit

Merrni një pritës në 192.0.2.10 që publikon TCP 2222 drejt një kontejneri në 172.30.240.5:22. Një kërkesë nga 198.51.100.25 përkthehet përpara se të arrijë kontejnerin, dhe kontejneri përgjigjet si vetvetja.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Në vendimin e rrugës të pritësit përgjigja ende mbart adresën burimore të kontejnerit. Përkthimi i kundërt e rivendos më vonë tuple-n e publikuar, dhe për këtë arsye paketa duket e gabuar pikërisht në momentin kur zgjidhet rruga.

Pse një rregull vetëm për pritësin e humbet atë

Një rregull që zgjedh tabelën WAN vetëm për paketat nga 192.0.2.10 mbulon daemonët e vetë pritësit dhe e humbet plotësisht këtë përgjigje të përcjellë. Adresa burimore në përgjigje është 172.30.240.5, jo pritësi.

Korrigjimi i tepruar është të drejtohet gjithçka nga kontejneri përmes WAN, gjë që i përjashton nga VPN edhe lidhjet dalëse të palidhura të kontejnerit. Kjo është një politikë tjetër nga ajo që u kërkua, dhe zakonisht befas on dikë më vonë.

Përputhja pas DNAT është një hook tjetër

Dokumentacioni i Docker për firewalls vëren se filtrimi i zakonshëm i përdoruesit e sheh destinacionin pas DNAT, kështu që përputhja e portës së publikuar 2222 në një rregull normal nuk është e njëjtë me përputhjen e portës 22 të kontejnerit. Nëse tuple-i origjinal ka rëndësi, përdorni mekanizmin e mbështetur të destinacionit origjinal në vend që të hamendësoni cila portë është e dukshme.

Ky konfuzion hook-esh prodhon rregulla që duken të sakta dhe nuk përputhen kurrë. Kontrolloni numëruesit në vetë rregullin përpara se të rishkruani politikën. Një rregull pa asnjë goditje ju thotë se po vlerësohet diku ku paketa nuk arrin kurrë.

Modeli A: mbaj vendimin si gjendje e lidhjes

Një shenjë lidhjeje mund ta mbajë vendimin e hyrjes përmes përkthimit, por duhet të rivendoset në paketë përpara kërkimit të rrugës që ka rëndësi. Fazat janë:

  1. Rezervoni një fushë shenje dhe një përparësi rregulli që nuk përplasen me Docker, VPN-në ose një pronar tjetër politike.
  2. Identifikoni vetëm lidhjen e re WAN të synuar në një pikë përpara DNAT ku gjurmimi i lidhjeve është i disponueshëm.
  3. Regjistroni vendimin në shenjën e lidhjes, pa e detyruar vetë kërkesën origjinale në tabelën WAN.
  4. Në drejtimin e përgjigjes, rivendosni në paketë vetëm bitet tuaja të shenjës përpara rrugëzimit.
  5. Zgjidhni një tabelë të plotë WAN mjaft herët që një rregull VPN të mos mund të fitojë i pari.

Ajo tabelë ka nevojë për rrugët reale të lidhura dhe portën hyrëse. Ka nevojë edhe për sjellje të përcaktuar kur rruga mungon. Rënia e heshtur në tunel është rezultati më i keq, sepse konfigurimi vazhdon të duket sikur punon. Në vend të kësaj dështoni i mbyllur dhe regjistrojeni.

Modeli B: përfundoni në pritës

Një frontend i konfiguruar me qëllim në anën e pritësit, si një proxy TCP ose një proxy i kundërt përpara kontejnerit, e mban përgjigjen të dalë nga adresa e pritësit. Atëherë rregullat e shkruara për pritësin sillen si pritet, dhe kontejneri mbetet në rrjetin e vet privat.

Kostoja është një pjesë tjetër lëvizëse me konfigurimin, trajtimin e adresave burimore dhe kontrollet e aksesit të vet. Zakonisht është kufiri më i thjeshtë i mbështetur, dhe shpesh është përgjigja e saktë kur politikën e rrugëzimit do ta mirëmbante një person i vetëm që mund të largohet.

Verifikoni ndryshimin, jo qëllimin

Hapni një lidhje të re të autorizuar nga ana publike dhe konfirmoni se përgjigja del nga ndërfaqja e synuar. Më pas kontrolloni nëse një kërkesë e palidhur e nisur nga kontejneri vazhdon të ndjekë VPN-në.

Mos e zbrazni tabelën e lidhjeve të makinës për të testuar një rregull: hyrjet ekzistuese mbajnë hartëzimin e mëparshëm, dhe zbrazja prish gjithçka tjetër në pritës. Publikimi i një porte përcakton arritshmërinë. Nuk përcakton rrugën e përgjigjes. Shkruani modelin e zgjedhur me emrat e tabelave të tij, që personi tjetër të mos duhet ta rizbulojë gjatë një incidenti.

Artikuj të ngjashëm