Dapat ka bang maglapat ng SNAT sa port forward papunta sa isang VPN subnet?
Ang port forward papunta sa VPN subnet ay naghahatid ng kahilingan ngunit nawawala ang tugon. Isang piling tuntunin ng source NAT sa router ang nagbabalik ng daan pabalik.
Ang pag-forward ng port papunta sa isang host na nasa likod ng sariling VPN client ng router ay nabibigo sa paraang mukhang problema sa firewall, dahil malinaw na dumarating ang kahilingan. Nagre-record ang serbisyo ng koneksyon, naghihintay ang client, at walang bumabalik. Nagawa ng pagsasalin ng destinasyon ang trabaho nito; ang return packet ang bahaging nawala. Isang piling tuntunin ng source NAT sa router ang nag-aayos nito, at ang kawili-wiling bahagi ay ang pagpapasya kung gaano kakipot ang tuntuning iyon.
Bakit ibang daan ang tinatahak ng tugon
Ang port forward ay nagsusulat muli kung saan pupunta ang packet, hindi kailanman kung saan ito galing. Nananatili ang address ng internet client sa source field sa buong daan sa tunnel, kaya nakikita ng malayong serbisyo ang isang estranghero at tumutugon sa tanging paraang alam nito: sa pamamagitan ng sarili nitong default gateway. Ang gateway na iyon ay ang VPN concentrator sa kabilang panig, na walang ruta pabalik sa isang arbitraryong pampublikong address.
Panoorin ang isang capture sa tunnel interface at kitang-kita ang kawalan ng simetriya: lumalabas ang mga packet ng kahilingan, walang pumapasok. Pinayagan ng forward chain ang daloy at dinala ito ng tunnel, kaya nangyayari ang pagbagsak pagkatapos nang pumili ng daan pabalik ang malayong host.
Isang tuntunin sa pinagmulan na sapat na kakipot para pagkatiwalaan
Gawing ang router ang pinagmulan na tinutugunan ng malayong host. Sa layout na ito ang WAN address ay 203.0.113.24, ang LAN ay 192.168.88.0/24, ang tunnel address ng router ay 172.20.5.1, at tumutugon ang serbisyo sa 172.20.5.40:8443. Ang tuntunin sa ibaba ay tumutugma sa packet pagkatapos ng pagsasalin ng destinasyon, kaya pinapangalanan nito ang naisaling address at hindi ang pampubliko. Wala sa loob nito ang nakadepende sa address ng client, at iyon mismo ang punto.
iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1Bawat tugma sa linyang iyon ay umiiral upang manatiling lokal ang muling pagsulat sa isang serbisyo sa isang tunnel. Alisin ang interface o ang port at mas maraming trapiko ang isusulat mong muli kaysa kailangan ng problema, at ganoon nagiging palaisipan para sa susunod na tao ang isang naka-target na pag-aayos.
Kailan ang pangkalahatang maskara ang tapat na pagpili
Kung maraming serbisyo ang ipinoproseso ng router papunta sa parehong VPN subnet, ang tuntunin kada serbisyo ay nagiging listahang walang nag-aalaga. Ang pag-maskara sa lahat ng lumalabas sa tunnel interface ay mas simple at mahuhulaan, kapalit ng pagtatago ng orihinal na client sa bawat host sa kabilang panig. Piliin iyon kapag hindi ginagamit ang mga log doon para sa attribution; panatilihin ang kakipot na tuntunin kapag ginagamit.
Nabibigo rin ang dalawang opsyon sa magkaibang paraan. Ang nawawalang kakipot na tuntunin ay sumisira sa isang serbisyo; ang malawak na maskara na tumutugma sa masyadong marami ay maaaring tahimik na magsulat muli ng trapikong gumagana na, kabilang ang sariling mga koneksyon palabas ng router.
Suriin ang mga counter bago maglathala
Ang mga tuntuning hindi kailanman tumutugma ay mukhang katulad ng mga tuntuning gumagana hanggang bilangin mo ang mga packet. Basahin muli ang talahanayan na may byte counter bago kumonekta ang sinumang client, pagkatapos kumonekta mula sa network na hindi LAN at basahin itong muli. Dalawang pagbasa ang nagpapalit ng haka-haka tungo sa katotohanan. Ilathala ang port forward pagkatapos lamang gumalaw ng pangalawa.
iptables -t nat -L POSTROUTING -v -n --line-numbersAng zero counter sa tuntunin sa pinagmulan pagkatapos ng tunay na koneksyon ay nangangahulugang mali ang tugma, kadalasan dahil hindi tumutugma ang destinasyon o port sa packet pagkatapos ng pagsasalin. Kung tumataas ang counter pero nag-time out pa rin ang client, naayos na ang daan pabalik at may ibang nagtatapon ng tugon, kaya tingnan sa susunod ang patakaran sa pag-forward sa kabilang panig. Ang hairpin access mula sa loob ng LAN ay hiwalay na problema at kailangan ng sarili nitong tuntunin, hindi mas malawak na bersyon nito.