Publicēt LAN pakalpojumu pašā VPN vārtejas adresē
Izsekojiet pārsūtīto portu no klienta līdz ierīcei un atpakaļ: ierobežojiet galamērķa tulkojumu, pēc tam izlemiet, vai atbildes tiek maršrutētas vai tulkotas.
LAN ierīces parādīšana vienā no vārtejas pašas tuneļa adresēm prasa tikai vienu NAT rindu. Savienojums joprojām neizdodas, jo atbildošā ierīce nezina, ka klienta adrese ir sasniedzama caur šo vārteju. Izsekojiet pakešu no klienta uz iekšu, pēc tam izsekojiet atbildi atpakaļ uz āru, un trūkstošā puse kļūst acīmredzama.
Sāciet no klienta skatupunkta
Šī piemēra klients atrodas VPN pūlā 10.62.0.0/24 un pieslēdzas 10.62.0.1 8080 portā. Šī adrese pieder pašai vārtejai, tāpēc pakete nonāk vārtejas kodolā, nevis pie cita partnera. Aiz vārtejas LAN ir 172.21.4.0/24. Vārtejai ir 172.21.4.10, un ierīce, kas faktiski apkalpo HTTP, ir 172.21.4.40.
Adrese, kas pieder citam VPN partnerim, nav aizstājama ar vārtejas pakalpojuma adresi. Ja klients pieslēdzas partnera adresei, neviena vārtejas kārtula vispār nav iesaistīta, un visa šī gaita ir nepareizais gadījums.
Apzināti ierobežojiet galamērķa tulkojumu
Šaurā versija parāda vienu portu un pārraksta tikai galamērķi. Pakete saglabā protokolu un avotu, un tieši tas padara pārējo gaitu interesantu.
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
Kārtula bez protokola un porta kritērijiem ir plašā versija: tā saglabā jebkuru portu, ko klients izvēlējās, un maina tikai adresi. Tas ir likumīgi, ja paredzēts parādīt visu resursdatoru, un nepareizi, ja nolūks bija viena pakalpojuma. Izlasiet kārtulu atpakaļ un apstipriniet saskarnes nosaukumu. DNAT kārtula nepareizajā saskarnē neatbilst nekam, kas rada tādu pašu noildzi kā trūkstoša kārtula un izšķiež stundu, skatoties uz ierīci.
Lai pārsūtīšanas robeža piekrīt
Tulkojums maina galveni, bet nedod atļauju. Ar noklusējuma nomešanas politiku pārsūtītajai plūsmai vajag savu atļauju, un atgriešanās virzienam vajag noteiktā savienojuma kārtulu, kas jūsu politikā droši vien jau ir.
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
Beznosacījumu atļauja katrai DNAT plūsmai ir plašāka par šo dizainu un atļaus arī kartējumus, ko vēlāk pievienos kāds cits. Nosauciet galamērķi un portu, un atstājiet pārējo slēgtu. Ja pārsūtīšanas kārtulas skaitītāji paliek nullē, kamēr NAT skaitītāji kāpj, pakete tiek izmesta pirms jūsu kārtulas. Lasiet ķēžu secību, nevis pievienojiet otru kopiju.
Ierīcei kaut kā jāatbild
Pēc tulkojuma ierīce redz avotu 10.62.0.0/24 iekšienē. Tās atbilde dodas uz tās noklusējuma vārteju, kas ir LAN maršrutētājs, nevis VPN vārteja, ja vien kaut kas nepasaka citādi. Divi izkārtojumi to labo, un tie nav līdzvērtīgi. Maršruts ierīcē vai LAN maršrutētājā sūta 10.62.0.0/24 uz 172.21.4.10 un saglabā klienta avotu. Ierobežots avota tulkojums tā vietā paslēpj klientu aiz vārtejas LAN adreses.
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
Izvēlieties pēc tā, kas pakalpojumam vajadzīgs. Politika katram klientam un jēgpilni žurnāli vēlas maršrutēto formu; ierīce, kurai nevar dot maršrutu, vai pakalpojums, kuram vienkārši jāredz LAN adrese, norāda uz tulkoto formu. Nesniedzieties pēc globālas masquerade kārtulas, lai viena atbilde strādātu. Tā paslēpj katru klientu no katra galamērķa un klusi salauž politikas, kas atkarīgas no avota adresēm.
Nepārbaudiet no pašas vārtejas
Pieprasījums, kas ģenerēts uz vārtejas uz 10.62.0.1, iziet caur OUTPUT ķēdi, nevis caur ienākošo PREROUTING. Tā neveiksme vai panākumi neko nepasaka par kārtulu, kas vērsta pret klientu, un tā cilvēki nonāk pie secinājuma, ka strādājoša kārtula ir salauzta.
conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'
Palaidiet īstu klienta pieprasījumu un izlasiet abus. conntrack ieraksts parāda piemēroto tulkojumu, un uztveršanas rāda, vai pieprasījums pārgāja uz LAN un vai atbilde atgriezās pretī tunelim. Pēc kārtulu maiņas izmantojiet jaunu savienojumu, jo esošais stāvoklis saglabā iepriekšējo kartējumu un turpinās neizdoties vecajā veidā. Pēc tam apstipriniet visu sarunu: ierīces adrese, pārsūtīšanas atļauja un atbildes maršruts visi apraksta vienu un to pašu plūsmu.