Publikimi i portave të Docker dhe burimet VPN: dy përputhje që i humbisni

Rregulli thotë lejo adresën e serverit VPN drejt shërbimit të publikuar, dhe lidhja prapë prishet. Ky rezultat është i zakonshëm dhe nuk është defekt i Docker. Dy përputhje të ndara janë të gabuara: burimi që shkruat mund të mos jetë burimi që pranon hosti, dhe porta që shkruat mund të mos jetë porta që sheh filtri. Rregullimi i të dyjave kërkon të shikoni rrugën e paketës në vend të diagramit të shërbimit.

Miti: lejo serverin VPN dhe mbarove

Një VPN e rrugëzuar mund të ruajë adresën e tunelit të klientit deri në hostin Docker. Një portë që bën përkthim burimi mund ta zëvendësojë atë adresë me të vetën. Të dyja modelet janë legjitime dhe prodhojnë burime të ndryshme për të njëjtin veprim të përdoruesit.

Pra shprehja IP-ja e serverit VPN përshkruan një supozim, jo një vëzhgim. Derisa të dini cila nga dy modelet është përpara jush, rregulli është hamendësim.

Burimi: grupi i klientëve ose porta e përkthyer

Kontrolloni katër gjëra me radhë. Së pari, grupin e adresave të klientëve, për shembull 10.90.0.0/24. Së dyti, nëse porta e përkthen atë grup përpara se të arrijë hostin. Së treti, burimin që hosti vëzhgon vërtet për një lidhje të re. Së katërti, nëse vërtetimi i aplikacionit i dallon përdoruesit individualë, sepse një adresë e përkthyer e përbashkët nuk mund ta bëjë këtë.

Nëse grupi ruhet, një rregull që përputhet vetëm me adresën publike të portës humb çdo klient. Nëse porta përkthen qëllimisht, lejimi i adresës së përkthyer pranon çdo përdorues pas saj, gjë që mund të jetë e pranueshme për një shërbim me identifikim të vetin dhe e papranueshme për çdo gjë tjetër.

Porta: DNAT ndryshon numrin që përputhni

Në publikimin e zakonshëm përmes urës Linux me iptables të Docker, një hartëzim i hostit nga 8443 në portën 443 të kontejnerit përkthehet përpara se të ekzekutohet filtri i përcjelljes. Paketa arrin në filtër me portën e destinacionit 443. Një rregull që përputhet me 8443 në atë moment nuk aktivizohet kurrë, edhe pse 8443 është ajo që shtypi klienti.

Porta e publikuar vazhdon të ekzistojë në gjurmimin e lidhjeve, prandaj destinacioni origjinal mund të përputhet atje kur ju nevojitet vërtet.

Vendosni cili numër shpreh qëllimin. Përputhni portën e kontejnerit pas DNAT kur rregulli mbron shërbimin brenda kontejnerit. Përputhni destinacionin origjinal me opsionin conntrack kur rregulli duhet të përshkruajë çfarë kërkoi klienti, dhe pranoni koston shtesë të përputhjes dhe kujdesin për rendin e rregullave që vijnë me të.

Zinxhiri: DOCKER-USER, jo INPUT

Udhëzuesi i iptables i Docker vendos politikën e përcjelljes së përdoruesit në zinxhirin DOCKER-USER, i cili vlerësohet përpara rregullave të vetë Docker për përcjellje. Një rregull i kopjuar nga një shërbim i hostit në zinxhirin INPUT filtron trafikun që drejtohet drejt hostit, jo trafikun që përcillet drejt një kontejneri. Ky gabim prodhon një rregull që duket i saktë dhe nuk ka asnjë efekt në rrugën e kontejnerit.

Mbani së bashku në të njëjtin rregull intervalin e burimit, portën efektive të destinacionit, protokollin dhe ndërfaqen hyrëse. Një leje vetëm mbi burimin për çdo destinacion të përcjellë është më e gjerë sesa lejimi i një shërbimi të vetëm të publikuar.

Verifikoni me lidhje të reja

Provoni të dy drejtimet me lidhje të reja: një klient VPN i lejuar dhe një burim që duhet të mbetet i refuzuar. Gjendja ekzistuese e lidhjes mund ta mbajë një sesion gjallë pasi politika ndryshon, prandaj një lidhje e vjetër nuk provon asgjë për rregullin e ri. Më pas kontrolloni rrugën e përgjigjes, sepse kontejneri duhet ende të rrugëzojë mbrapsht drejt burimit që sheh.

Rendi i zinxhirëve dhe sjellja e përkthimit të portave pas këtyre kontrolleve dokumentohen në udhëzuesin e iptables të Docker. Lexojeni përpara se të kopjoni një recetë dhe konfirmoni cilin backend përdor Docker i instaluar, sepse backend-i nftables e integron politikën ndryshe.