LAN-szolgáltatás közzététele a VPN-átjáró saját címén

Egy LAN-eszköz bemutatása az átjáró egyik saját alagútcímén egyetlen NAT-sort igényel. A kapcsolat mégsem jön létre, mert a válaszoló eszköznek fogalma sincs arról, hogy az ügyfél címe ezen az átjárón keresztül elérhető. Kövesse végig a csomagot az ügyféltől befelé, majd a választ visszafelé kifelé, és a hiányzó fél nyilvánvalóvá válik.

Kezdje az ügyfél nézőpontjából

A példa ügyfele a VPN-készletben, a 10.62.0.0/24-ben van, és a 8080-as porton kapcsolódik a 10.62.0.1-hez. Az a cím magához az átjáróhoz tartozik, ezért a csomag az átjáró kernelébe érkezik, nem egy másik társhoz. Az átjáró mögött a LAN a 172.21.4.0/24. Az átjáró a 172.21.4.10-et birtokolja, és a HTTP-t ténylegesen kiszolgáló eszköz a 172.21.4.40.

Egy másik VPN-társhoz tartozó cím nem cserélhető fel az átjáró szolgáltatási címével. Ha az ügyfél egy társ címéhez kapcsolódik, egyáltalán nem vesz részt benne átjárószabály, és ez az egész végigvezetés a rossz eset.

Határolja be szándékosan a célfordítást

A szűk változat egy portot mutat be, és csak a célt írja át. A csomag megtartja a protokollját és a forrását, és éppen ez teszi érdekessé a végigvezetés többi részét.

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

A protokoll- és portkritériumok nélküli szabály a széles változat: megtartja, melyik portot választotta az ügyfél, és csak a címet változtatja. Ez akkor jogos, ha a teljes gazdagépet kell bemutatni, és akkor hibás, ha egyetlen szolgáltatás volt a szándék. Olvassa vissza a szabályt, és erősítse meg az interfész nevét. A rossz interfészen lévő DNAT-szabály semmire sem illeszkedik, ami ugyanazt az időtúllépést adja, mint egy hiányzó szabály, és egy órát pazarol az eszköz nézegetésére.

Engedje egyetérteni a továbbítási határt

A fordítás megváltoztatja a fejlécet, de nem ad engedélyt. Alapértelmezett eldobási irányelv mellett a továbbított folyamnak saját engedélyezésre van szüksége, a vissziránynak pedig a létesített kapcsolat szabályára, amely az irányelvében valószínűleg már megvan.

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

Minden DNAT-folyam feltétel nélküli engedélyezése szélesebb ennél a tervezésnél, és lehetővé teszi a később másvalaki által hozzáadott leképezéseket is. Nevezze meg a célt és a portot, és hagyja a többit zárva. Ha a továbbítási szabály számlálói nullán maradnak, miközben a NAT-számlálók nőnek, a csomag a szabálya előtt eldobódik. Olvassa a láncok sorrendjét, ahelyett hogy egy második példányt adna hozzá.

Az eszköznek valahogy válaszolnia kell

A fordítás után az eszköz forrást lát a 10.62.0.0/24-ben. A válasza az alapértelmezett átjárójához megy, ami a LAN-útválasztó, nem a VPN-átjáró, hacsak valami nem mond neki mást. Két elrendezés orvosolja ezt, és nem egyenértékűek. Egy útvonal az eszközön vagy a LAN-útválasztón a 10.62.0.0/24-et a 172.21.4.10-re küldi, megőrizve az ügyfél forrását. Egy korlátozott forrásfordítás ehelyett az átjáró LAN-címe mögé rejti az ügyfelet.

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

Aszerint válasszon, mire van szüksége a szolgáltatásnak. Az ügyfelenkénti irányelv és az értelmes naplók az útválasztott formát akarják; az az eszköz, amelynek nem adható útvonal, vagy az a szolgáltatás, amelynek egyszerűen LAN-címet kell látnia, a fordított formára mutat. Ne nyúljon globális masquerade-szabályhoz, hogy egyetlen válasz működjön. Minden ügyfelet minden cél elől elrejt, és csendben megtöri a forráscímektől függő irányelveket.

Ne teszteljen magából az átjáróból

Az átjárón a 10.62.0.1 felé létrehozott kérés az OUTPUT láncon keresztül lép ki, nem a bejövő PREROUTING-on. A sikertelensége vagy sikere semmit sem mond az ügyfél felé néző szabályról, és így jutnak arra az emberek, hogy egy működő szabály elromlott.

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

Futtasson valódi ügyfélkérést, és olvassa mindkettőt. A conntrack-bejegyzés az alkalmazott fordítást mutatja, a rögzítések pedig azt, hogy a kérés átment-e a LAN-ba, és jött-e vissza válasz az alagút felé. Szabálymódosítás után használjon új kapcsolatot, mert a meglévő állapot megtartja a korábbi leképezését, és továbbra is a régi módon fog elromlani. Ezután erősítse meg az egész beszélgetést: az eszköz címe, a továbbítási engedély és a válasz útvonala ugyanazt a folyamot írja le.