eth0:0 ay isang label, hindi isang device: ayusin ang tugma ng SNAT

Ang NAT rule na dapat magbigay sa isang VPN client pool ng sarili nitong pampublikong address ay nakatayo sa zero packets, habang ang parehong pool ay patuloy na lumalabas na may maling source. Karaniwang hindi nagkakamali ang rule sa address; nagkakamali ito sa interface. -o eth0:0 ay tumutukoy sa isang device na hindi umiiral, dahil eth0:0 ay isang label na nakakabit sa isang address sa eth0. Ang pagtingin sa mga counter ang pinakamabilis na paraan upang kumpirmahin ito, at ang pagtatama ay mas maliit kaysa sa ipinahihiwatig ng imbestigasyon.

Tingnan kung ano ang itinatawag ng kernel sa device

Basahin ang dalawang view nang hiwalay bago magbago ng anuman:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

Ipinapakita ng listahan ng link ang mga interface. Maaaring magpakita ang listahan ng address ng pangalawang IPv4 address na may dalang label eth0:0, at ang device para sa address na iyon ay nananatiling eth0. Itinuturing ng manual ng address ng iproute2 ang label bilang pangalan ng address, hindi bilang pangalawang link, at iyon ang pagkakaibang nakasandal ang buong problema.

Ipinaliliwanag ng kasaysayan ang pagkalito. Ang lumang ifconfig eth0:0 syntax ay talagang mukhang bagong interface, at ang mga script noong panahong iyon ay tumutukoy pa rin sa isa. Sa kasalukuyang sistema, ang alias ay isang label sa isang address, at walang anuman sa daan ng routing o netfilter ang tumitingin dito bilang hiwalay na exit point.

Tingnan kung ano talaga ang tinugma ng rule

Basahin ang mga counter kasama ng listahan ng rule, hindi mula sa memorya:

iptables -t nat -L POSTROUTING -v -n --line-numbers

Ang rule na ang packet counter ay nananatiling zero habang dumadaloy ang tugmang trapiko ay hindi sinusuri, at ang kondisyon ng output interface na nagpapangalan ng eth0:0 ay karaniwang dahilan. Ang output device na pinili ng ruta ay eth0, kaya ang kondisyon na naghahanap ng ibang pangalan ay hindi kailanman nagiging totoo, anuman ang piniling source address ng kernel.

Palitan ang kondisyon sa tunay na device at iwanan ang label sa labas nito. Kung kailangan mong paghiwalayin ang dalawang client pool na nagbabahagi ng device na iyon, paghiwalayin sila ayon sa source prefix, hindi sa pangalan ng interface na hindi maaaring umiral. Dalawang rule na may tugmang -s -s na hindi nag-ooverlap ay nababasa at nasusubok; isang rule na may kathang-isip na device ay wala sa dalawa. Bigyan ang bawat rule ng komentong nagpapangalan sa pool, dahil pagkalipas ng anim na buwan ang prefix lamang ay walang magsasabi kaninuman kung bakit naroon iyon.

Tingnan ang rutang pumili ng device

Tumatakbo ang NAT ng postrouting pagkatapos nang piliin ng ruta ang isang output interface, kaya ang interface sa rule ay dapat ang pinili ng ruta. Tanungin ang kernel nang direkta gamit ang ip route get para sa isang representatibong client address at basahin kapwa ang device at ang source na iniuulat nito.

Kung pinangalanan ng sagot ang eth0, lutas na ang bahagi ng rule tungkol sa interface. Kung pinangalanan nito ang isang tunnel device, hindi kailanman naaabot ng packet ang rule na ine-edit mo, at lumilipat ang paghahanap sa routing table at sa mga prayoridad nito. Ang rule na hindi kailanman tumutugma dahil lumabas ang packet sa ibang lugar ay mukhang kapareho sa output ng counter ng rule na may maling baybay na device. Kumpirmahin kung alin sa dalawang kaso ang nasa iyo bago mag-edit ng anuman, dahil ang pangalawa ay nangangailangan ng pagbabago sa routing, hindi sa teksto.

Sadyang piliin ang isinaling source

Kapag tama na ang device, ang source address ay hiwalay na desisyon. Ito ay isang ilustratibong IPv4 pool at halimbawang address lamang:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

Ang pagsulat ng address sa --to-source ay hindi nagiging dahilan upang i-ruta ito ng sinuman pabalik sa iyo. Dapat ihatid ng upstream provider o ng may-ari ng address ang mga sagot para sa address na iyon sa host na ito, at ang address ay dapat isang pinahihintulutan mong gamitin. Kung hindi, tutugma ang rule at magsasalin at ang mga sagot ay pupunta pa rin sa ibang lugar.

Ang pagbabago ng source address ay hindi kapareho ng pagbabago ng uplink. Kapag ang tunay na pangangailangan ay ibang pisikal na landas, dapat munang piliin ng patakaran ng routing ang landas na iyon; pagkatapos ay muling isinusulat ng SNAT ang source sa alinmang device na pinili ng patakaran. Ang dagdag na label sa eth0 ay hindi nagbibigay ng ruta o pahintulot.

I-verify gamit ang koneksyong bago mo lang binuksan

Magbukas ng bagong kliyenteng koneksyon sa halip na gamitin muli ang umiiral. Pinapanatili ng connection tracking ang salin na naitala nito nang magsimula ang daloy, kaya ang lumang sesyon ay maaaring magpatuloy sa paggamit ng dating source address at gawing mukhang sira ang isang tamang bagong rule. Panoorin ang counter na tumataas, pagkatapos ay tingnan ang isinaling source sa kawad o sa dulong dulo.

Para sa maraming pool na nagbabahagi ng isang interface, bigyan ang bawat isa ng tahasang tugma sa source at sariling address ng salin, panatilihin sila sa pinamamahalaang pagsasaayos ng firewall at itala ang pagkakasunod-sunod ng pagsusuri. Pagkatapos, itala ang na-verify mo: ang device mula sa ip route get, ang counter na gumalaw, at ang source na nakita ng kabilang dulo. Ang talaang iyon ay sumasagot sa susunod na ulat nang hindi inuulit ang pagkalito sa label.