Maabot ang malayong /24 sa pamamagitan ng tunnel: NETMAP, DNAT o ruta?

Maaari mong maabot ang isang subnet sa likod ng tunnel endpoint sa tatlong paraan, at ang isang minutong pagtitipon ng katotohanan ay karaniwang nagtatanggal ng dalawa. Ang mga katotohanan ay kung kailangang makilala ng mga server doon ang mga user, kung may tao bang doon ay tatawag sa iyong saklaw, at kung sino ang maaaring mag-edit ng router sa malayong dulo. Sagutin ang tatlong iyon at ang disenyo mismo ang pipili. Ipinapalagay ng natitira na pinapatakbo mo ang endpoint at maaari mong i-edit ang firewall nito.

Tatlong opsyon, at ang aktwal na binabago ng bawat isa

Ang prefix mapping, DNAT bawat host at isang rutang prefix ay inililipat ang mga packet sa pagitan ng parehong dalawang saklaw, ngunit iba't ibang bagay ang binabago. Ang mapping ay nag-imbento ng alias na saklaw at aritmetikong nagsusulat muli ng mga address habang nasa daan. Ang mga patakaran bawat host ay nagsusulat muli rin, ngunit ang bawat destinasyon ay pinangalanan sa kamay. Ang rutang prefix ay walang isinusulat muli: pinapanatili ng mga packet ang tunay na address at parehong dulo ay sumasang-ayon kung saan nakatira ang mga address na iyon.

Simulan ang pagtatanggal sa malayong dulo, kung saan pinakamahirap baguhin ang mga limitasyon. Kung ang server doon ay nagsusulat ng address ng kliyente sa mga log, tinitingnan ang mga ito laban sa isang allowlist o ipinapasa sa ibang sistema, sinisira ng pagsasalin ng pinagmulan ang nag-iisang identifier nito. Kung kailangan ding tumawag pabalik ng malayong dulo, ganap na hindi kasama ang pagsasalin, dahil walang nakakaalam doon na may alias. Kapag sumasagot lang sa mga kahilingan ang malayong dulo, nagiging ligtas ang mas murang opsyon.

Mga pares ng prefix, at bakit kailangang magtugma ang laki

Ang NETMAP ay target ng nat table na gumagana sa isang pares ng prefix na magkapareho ang haba. Wala itong table bawat address sa loob: tinatanggal nito ang prefix, pinapanatili ang host bits at ikinakabit muli sa bagong prefix, kaya ang /24 ay naka-map sa /24 at hindi kailanman sa /25. Ang posisyon ang nagtatakda ng direksyon: ang tugma ng destinasyon sa PREROUTING ay nagsusulat muli kung saan pupunta ang packet, at ang tugma ng pinagmulan sa POSTROUTING ay nagsusulat muli kung saan ito galing.

Ang host sa 192.168.2.17 ay lumalabas sa iyong mga kliyente bilang 10.50.1.17, at ang huling octet ay hindi dekorasyon — pareho itong numero sa magkabilang dulo. Magdagdag bukas ng host sa 192.168.2.40 at ang alias nito ay 10.50.1.40, walang patakarang ie-edit.

Kailangan pa rin ng mga kliyente ng ruta para sa alias na saklaw na tumuturo sa iyong kahon, maliban kung ang alias ay nasa subnet na naaabot na nila. Hindi kailangan ng gateway ng ruta para sa alias, dahil tumatakbo ang pagsasalin ng destinasyon sa PREROUTING, bago ang paghahanap ng ruta. Kailangan ding bukas ang forwarding, kung hindi ay itatapon ng kernel ang packet pagkatapos ng pagsulat muli. Ang tatlong utos sa ibaba ay ang buong setup sa isang gateway na Debian-style na may mga kliyente sa br0, ang alias sa 10.50.1.0/24 at ang tunnel sa tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Kailangang hanapin ng sagot ang sariling daan pabalik

Ang pagsulat muli ng destinasyon ay nagpapasya lamang kung saan ihahatid ang packet. Kailangan pa ring sumagot ng malayong server sa address na naaabot nito, at may dalawang paraan para ayusin iyon. Isalin ang pinagmulan upang bumalik ang mga sagot sa iyong kahon, o iwanan ang pinagmulan at bigyan ang malayong dulo ng ruta para sa saklaw ng kliyente.

Ang masquerade sa labas ay ang mas maikling daan: isang patakaran sa POSTROUTING at nakikita ng malayong dulo ang address ng iyong tunnel, kaya hindi nito kailangan ng sariling ruta. Ang halaga ay nagiging isang address ang bawat user, at wala nang ibig sabihin ang mga log bawat user. Kung iiwang buo ang pinagmulan, napanatili ang impormasyong iyon, ngunit kailangang ibalik ng malayong site ang mga sagot para sa saklaw ng kliyente sa tunnel.OpenVPN server iyon ay isang push na push "route 10.50.9.0 255.255.255.0", kasama ang route 192.168.2.0 255.255.255.0 linya.

Ang mamahaling pagkabigo ay gawin ang kalahati ng bawat isa. Kung mag-masquerade ka ng bahagi ng trapiko habang may bitbit ding return route ang malayong dulo para sa ibang trapiko, dumarating ang mga sagot sa interface kung saan hindi kailanman nakita ang connection tracking entry. Nag-uulat ang kliyente ng timeout para sa kahilingang naitala ng server bilang napaglingkuran. Ang dalawang direksyon ng isang daloy ay dapat dumaan sa parehong netfilter instance: isang gateway na nagsasalin, hindi dalawang firewall na magkakasunod.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Basahin ang entry sa dalawang direksyon: pinapanatili ng orihinal na tuple ang iyong alias sa destinasyon, habang dinadala ng sagot na tuple ang tunay na address. Kung wala ang sagot na tuple, ang problema ay ang return path, hindi ang patakaran. Kung hindi gumalaw ang mga counter ng PREROUTING, hindi naabot ng packet ang hook na iyon.

Mga banggaan at ang paghahanap na unang tumatakbo

Maaaring magbangga ang dalawang magkaibang saklaw, at ang parehong pagkabigo ay mukhang sirang tunnel kaysa masamang patakaran. Ang alias na iyong iniimbento ay dapat hindi ginagamit sa buong daan, at ang tunay na malayong saklaw ay hindi dapat umiiral na sa iyong network. Ang duplicate ay nagdudulot ng paputol-putol na trapiko sa maling host, na mas mahirap i-diagnose kaysa tinanggihang koneksyon. Tanungin ang routing table bago magdagdag ng patakaran.

Sa gateway, ip route get 192.168.2.17 dapat pangalanan ang tunnel device; ang lokal na bridge ay nangangahulugang natatakpan ang malayong saklaw at walang nat na patakarang makakapag-ayos nito. Kung gumagamit na ang iyong network ng 192.168.2.0/24, muling bilangin ang malayong site sa halip na magpatong ng mapping sa banggaan.

Subukan mula sa tunay na kliyente, pagkatapos ay itago

Subukan mula sa makina na aktwal na gagamit ng alias, hindi mula sa gateway, dahil ang trapikong nabuo nang lokal ay hindi kailanman dumadaan sa PREROUTING sa parehong paraan. Magbukas ng koneksyon sa isang host na may alias at panoorin ang mga counter at conntrack entry na sabay na lumalabas, pagkatapos ay isara at kumpirmahing umaalis ang entry. Ang lumang entry ay tumuturo sa kalahating bukas na koneksyon, na karaniwang nangangahulugang hindi kailanman bumalik ang sagot.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Ang dalawa o tatlong matagumpay na koneksyon ay nagpapatunay ng aritmetika, ngunit wala silang sinasabi tungkol sa pagtitiyaga o sa susunod na inhinyero. I-save ang mga patakaran kung saan binabasa ng boot process ang mga ito, na sa Debian at Ubuntu ay nangangahulugang iptables-save > /etc/iptables/rules.v4 na naka-enable ang netfilter-persistent. Ang mapping na nawawala sa reboot ay mas masahol pa sa wala, dahil dumarating ang outage nang walang kamakailang pagbabagong masisisi.

Mag-iwan ng tala sa tabi ng mga patakaran: ang alias na saklaw, ang tunay na saklaw, ang dahilan ng pares at kung aling panig ang maaaring magsimula. Ang talang iyon ay naghihiwalay ng disenyo mula sa bunton ng patakarang walang nangangahas na magbura. Inaayos din nito ang susunod na tanong, kapag nagdagdag ng host ang malayong site at may address na walang nag-configure ay sumasagot na. Kung sinasabi ng tala na kailangan ng malayong dulo ng return route, alam ng susunod na tao na ang pagtanggal ng masquerade na patakaran ay sisira sa koneksyon. Mura ang dokumentasyon dito; ang muling pagtuklas ng NAT dependency sa alas tres ng madaling araw ay hindi.