Publiko një shërbim LAN në adresën e vetë portës VPN

Të prezantosh një pajisje LAN në një nga adresat e tunelit të vetë portës kërkon vetëm një rresht NAT. Lidhja përsëri dështon, sepse pajisja që përgjigjet nuk e di se adresa e klientit është e arritshme përmes asaj porte. Ndiqni paketën nga klienti nga brenda, më pas ndiqni përgjigjen përsëri nga jashtë, dhe gjysma që mungon bëhet e dukshme.

Filloni nga këndvështrimi i klientit

Klienti në këtë shembull ndodhet në grupin VPN 10.62.0.0/24 dhe lidhet me 10.62.0.1 në portën 8080. Ajo adresë i përket vetë portës, kështu që paketa arrin në kernelin e portës dhe jo te një palë tjetër. Pas portës, LAN-i është 172.21.4.0/24. Porta mban 172.21.4.10 dhe pajisja që shërben vërtet HTTP është 172.21.4.40.

Një adresë që i përket një pale tjetër VPN nuk është e këmbyeshme me adresën e shërbimit të portës. Nëse klienti po lidhet me adresën e një pale, asnjë rregull i portës nuk është fare i përfshirë, dhe i gjithë ky ecje është rasti i gabuar.

Kufizoni përkthimin e destinacionit me qëllim

Versioni i ngushtë prezanton një port dhe rishkruan vetëm destinacionin. Paketa ruan protokollin dhe burimin e saj, dhe kjo është ajo që e bën pjesën tjetër të ecjes interesante.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Një rregull pa kritere protokolli dhe porte është versioni i gjerë: ruan çdo port që zgjodhi klienti dhe ndryshon vetëm adresën. Kjo është e ligjshme kur synohet të prezantohet i gjithë hosti, dhe e gabuar kur synimi ishte një shërbim i vetëm. Lexojeni rregullin përsëri dhe konfirmoni emrin e ndërfaqes. Një rregull DNAT në ndërfaqen e gabuar nuk përputhet me asgjë, çka prodhon të njëjtin afat kohor si një rregull që mungon dhe harxhon një orë duke shikuar pajisjen.

Lëreni kufirin e përcjelljes të bjerë dakord

Përkthimi ndryshon kokën, nuk jep leje. Me një politikë të paracaktuar hedhjeje, fluksi i përcjellë ka nevojë për pranimin e vet, dhe drejtimi i kthimit ka nevojë për rregullin e lidhjes së vendosur që politika juaj ndoshta e ka tashmë.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Pranimi pa kushte për çdo fluks DNAT është më i gjerë se ky dizajn dhe do të lejojë gjithashtu hartëzime që dikush tjetër i shton më vonë. Emërtoni destinacionin dhe portën, dhe lërini pjesën tjetër të mbyllur. Nëse numëruesit në rregullin e përcjelljes mbeten në zero ndërsa numëruesit e NAT ngrihen, paketa po hidhet para rregullit tuaj. Lexoni rendin e zinxhirëve në vend që të shtoni një kopje të dytë.

Pajisja duhet të përgjigjet në një farë mënyre

Pas përkthimit pajisja sheh një burim brenda 10.62.0.0/24. Përgjigja e saj shkon te porta e saj e paracaktuar, e cila është ruteri i LAN-it, jo porta VPN, përveç nëse diçka i thotë ndryshe. Dy rregullime e ndreqin këtë dhe nuk janë ekuivalente. Një rrugë në pajisje ose në ruterin e LAN-it dërgon 10.62.0.0/24 te 172.21.4.10 duke ruajtur burimin e klientit. Një përkthim burimi i kufizuar e fsheh klientin pas adresës LAN të portës.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Zgjidhni sipas asaj që i nevojitet shërbimit. Politika për klient dhe regjistrat kuptimplotë duan formën e rrutuar; një pajisje së cilës nuk mund t'i jepet një rrugë, ose një shërbim që thjesht duhet të shohë një adresë LAN, tregojnë formën e përkthyer. Mos u shtrini drejt një rregulli global masquerade për të bërë të funksionojë një përgjigje e vetme. Ai fsheh çdo klient nga çdo destinacion dhe thyen në heshtje politikat që varen nga adresat e burimit.

Mos testoni nga vetë porta

Një kërkesë e krijuar në portë drejt 10.62.0.1 del përmes zinxhirit OUTPUT, jo përmes PREROUTING hyrëse. Dështimi ose suksesi i saj nuk thotë asgjë për rregullin përballë klientit, dhe kështu njerëzit arrijnë në përfundimin se një rregull që funksionon është i prishur.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Ekzekutoni një kërkesë të vërtetë klienti dhe lexoni të dyja. Zëri i conntrack tregon përkthimin e aplikuar, dhe regjistrimet tregojnë nëse kërkesa kaloi në LAN dhe nëse u kthye një përgjigje drejt tunelit. Përdorni një lidhje të re pas ndryshimit të rregullave, sepse gjendja ekzistuese ruan hartëzimin e mëparshëm dhe do të vazhdojë të dështojë në mënyrën e vjetër. Pastaj konfirmoni të gjithë bisedën: adresa e pajisjes, leja e përcjelljes dhe rruga e përgjigjes përshkruajnë të njëjtin fluks.