A ddylech chi ddefnyddio SNAT ar borthladd sy'n cael ei anfon ymlaen i is-rwydwaith VPN?

Mae anfon port ymlaen i westwy sydd y tu ôl i gleient VPN y llwybrydd ei hun yn methu mewn ffordd sy'n edrych fel problem mur cadarn, oherwydd bod y cais yn cyrraedd yn amlwg. Mae'r gwasanaeth yn cofnodi cysylltiad, mae'r cleient yn aros, ac nid oes dim yn dod yn ôl. Gwnaeth cyfieithu cyrchfan ei waith; y pecyn dychwelyd yw'r rhan a aeth ar goll. Mae un rheol NAT ffynhonnell ddethol ar y llwybrydd yn trwsio hyn, a'r rhan ddiddorol yw penderfynu pa mor gul y gall y rheol honno fod.

Pam mae'r ateb yn cymryd ffordd wahanol

Mae anfon port ymlaen yn ailysgrifennu i ble mae pecyn yn mynd, byth o ble y daeth. Mae cyfeiriad y cleient rhyngrwyd yn aros yn y maes ffynhonnell ar hyd y twnnel, felly mae'r gwasanaeth pell yn gweld dieithryn ac yn ateb yr un ffordd y gŵyr: trwy ei giât ddiofyn ei hun. Y giât honno yw canolbwynt VPN yr ochr bell, nad oes ganddo lwybr yn ôl i gyfeiriad cyhoeddus mympwyol.

Gwyliwch gipiad ar ryngwyneb y twnnel ac mae'r anghymesuredd yn amlwg: pecynnau cais yn mynd allan, dim yn dod i mewn. Roedd y gadwyn anfon ymlaen wedi caniatáu'r llif a chludodd y twnnel ef, felly mae'r cwymp yn digwydd ar ôl i'r gwestwy pell ddewis llwybr dychwelyd yn barod.

Rheol ffynhonnell sy'n ddigon cul i ymddiried ynddi

Gwnewch y llwybrydd yn ffynhonnell y mae'r gwestwy pell yn ateb iddi. Yn y trefniant hwn mae'r cyfeiriad WAN yn 203.0.113.24, y LAN yn 192.168.88.0/24, cyfeiriad twnnel y llwybrydd yn 172.20.5.1, ac mae'r gwasanaeth yn ateb ar 172.20.5.40:8443. Mae'r rheol isod yn cyfateb i'r pecyn ar ôl cyfieithu cyrchfan, a dyna pam mae'n enwi'r cyfeiriad cyfieithiedig yn hytrach na'r un cyhoeddus. Nid oes dim ynddi yn dibynnu ar gyfeiriad y cleient, a dyna'r pwynt yn union.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Mae pob cyfatebiad yn y llinell honno'n bod er mwyn cadw'r ailysgrifennu'n lleol i un gwasanaeth ar un twnnel. Tynnwch y rhyngwyneb neu'r port ac rydych yn ailysgrifennu mwy o draffig nag sydd ei angen ar y broblem, a dyna sut mae trwsio wedi'i dargedu yn troi'n dirgelwch i'r person nesaf.

Pryd yw mwgwd cyffredinol yn ddewis gonest

Os yw'r llwybrydd yn anfon llawer o wasanaethau ymlaen i'r un is-rwydwaith VPN, mae rheol pob gwasanaeth yn dod yn rhestr nad oes neb yn ei chynnal. Mae cuddio popeth sy'n gadael rhyngwyneb y twnnel yn symlach ac yn fwy rhagweladwy, ar gost cuddio'r cleient gwreiddiol oddi wrth bob gwestwy yr ochr bell. Dewiswch hi pan nad yw'r cofnodion draw'n cael eu defnyddio ar gyfer priodoli; cadwch y rheol gul pan fyddant.

Mae'r ddau opsiwn hefyd yn methu'n wahanol. Mae rheol gul ar goll yn torri un gwasanaeth; gall mwgwd llydan sy'n cyfateb i ormod ailosod yn dawel draffig a oedd eisoes yn gweithio, gan gynnwys cysylltiadau allan y llwybrydd ei hun.

Gwiriwch y cyfrifwyr cyn cyhoeddi

Mae rheolau nad ydynt byth yn cyfateb yn edrych yn union yr un fath â rheolau sy'n gweithio nes i chi gyfrif pecynnau. Darllenwch y tabl yn ôl gyda chyfrifwyr beit cyn i unrhyw gleient gysylltu, yna cysylltwch o rwydwaith nad yw'n LAN a'i ddarllen eto. Dau ddarlleniad sy'n troi amcan yn ffaith. Cyhoeddwch yr anfon ymlaen dim ond ar ôl i'r ail symud.

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

Mae cyfrifydd sero ar y rheol ffynhonnell ar ôl cysylltiad go iawn yn golygu bod y cyfatebiad yn anghywir, fel arfer oherwydd nad yw'r gyrchfan na'r port yn cyfateb i'r pecyn ar ôl cyfieithu. Os yw'r cyfrifydd yn codi ond mae'r cleient yn dal i amseru allan, mae'r llwybr dychwelyd wedi'i drwsio ac mae rhywbeth arall yn gollwng yr ateb, felly edrychwch nesaf ar y polisi anfon ymlaen yr ochr bell. Mae mynediad gwalltpin o du mewn y LAN yn broblem ar wahân ac mae angen ei rheol ei hun, nid fersiwn lletach o'r un hon.