Ar ôl newid IP y gweinydd, mae'r rheol SNAT yn dal i enwi'r un hen

Symudodd y gweinydd i gyfeiriad newydd, mae cleientiaid yn dal i gysylltu, ac nid oes dim o'r hyn a anfonant yn cyrraedd y rhyngrwyd. Y rhaniad hwnnw yw'r cliw: goroesodd y soced gwrando a'r anfon porth y symudiad, felly daw'r twnnel i fyny, tra bo'r cyfieithiad ffynhonnell a gymhwysir i becynnau a anfonir ymlaen yn dal i enwi cyfeiriad nad yw'r gwesteiwr yn berchen arno mwyach. Mae atebion i'r pecynnau hynny a ailysgrifennwyd yn mynd i beiriant nad yw yno mwyach.

Mae cysylltu ac anfon ymlaen yn methu mewn gwahanol leoedd

Mae sefydlu yn dibynnu ar y pwynt terfyn y mae cleientiaid eisoes yn ei adnabod: y cyfeiriad cyhoeddus, yr anfon porth o'i flaen, a'r gwrandawr y tu mewn. Mae traffig a anfonir ymlaen yn dibynnu ar ail benderfyniad a wneir ar ôl i'r pecyn fynd i mewn i'r twnnel, pan fo'r gwesteiwr yn ailysgrifennu ei ffynhonnell fel y gall atebion ddod o hyd i'w ffordd yn ôl.

Nid yw newid cyfeiriad ond yn torri'r ail benderfyniad, a dyna pam y darllenir y symptom fel "wedi cysylltu ond heb ryngrwyd". Mae hefyd yn esbonio pam mae'r gwiriadau arferol ar ochr y cleient yn edrych yn iach: mae'r ysgydwad llaw yn cwblhau, mae'r cleient yn derbyn cyfeiriad, a gall ping i gyfeiriad twnnel y gweinydd ateb hyd yn oed. Treulir oriau ar y cleient am fai sy'n byw ar yr ochr arall, a dyna pam mai'r tabl rheolau yw'r lle cyntaf i edrych.

Darllenwch y rheol a'i chyfrifwyr cyn golygu

Rhestrwch y rheolau cyfieithu gyda chyfrifwyr a chymharwch y ffynhonnell a ffurfweddwyd â'r cyfeiriadau sydd gan y gwesteiwr mewn gwirionedd. Mae rheol a ailysgrifennwyd i gyfeiriad marw fel arfer yn dangos traffig ar y ffordd i mewn, oherwydd bod pecynnau yn ei chyrraedd ac yn cael eu cyfieithu, a dim ar y ffordd yn ôl.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Gwiriwch dri maes tra byddwch yno: y pwll yn y cyfatebiaeth ffynhonnell, y rhyngwyneb allan os yw'r rheol yn enwi un, a'r eithriad sy'n cadw traffig twnnel-i-dwnnel rhag cael ei ailysgrifennu. Mae'r eithriad hwnnw'n hawdd ei golli yn ystod golygiad, ac mae ei golli yn gwneud i draffig cyfoedion ymddangos fel petai'n gweithio tra bo ei atebion yn cymryd llwybr rhyfedd.

Os yw'r cyfrifwyr yn sownd ar sero, nid yw pecynnau byth yn cyrraedd y rheol hon ac nid y cyfeiriad yw'r broblem bresennol. Chwiliwch am reol gystadleuol yn gynharach yn y gadwyn, sef yr hyn sy'n digwydd pan fo rhywun yn ychwanegu disodliad yn lle golygu'r gwreiddiol. Cymharwch rifau'r rheolau â'r allbwn a nodwyd gennych funud yn ôl. Mae trefn yn rhan o'r ffurfweddiad, nid yn fanylyn cosmetig.

Disodlwch y ffynhonnell, neu stopiwch enwi un

Pan fo gan y gwesteiwr gyfeiriad sefydlog, disodlwch y rheol yn ei lle yn hytrach nag ychwanegu un arall. Mae disodli yn ôl rhif rheol yn cadw'r drefn y mae gweddill y gadwyn yn dibynnu arni.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Pan fo'r cyfeiriad yn cael ei neilltuo'n ddeinamig, peidiwch ag enwi unrhyw ffynhonnell o gwbl a gadewch i'r cnewyllyn ddewis yr un cyfredol o'r rhyngwyneb allan. Mae'r amrywiad hwnnw'n goroesi'r symudiad nesaf heb olygiad, ar draul cuddio pa gyfeiriad a ddefnyddiwyd.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Cadarnhewch fod anfon ymlaen IPv4 yn dal i fod wedi'i alluogi trwy ffurfweddiad a reolir, yna gwnewch y rheol yn barhaol gyda mecanwaith y dosbarthiad ei hun. Mae newid a wneir yn y cnewyllyn sy'n rhedeg yn unig yn dychwelyd gyda'r ailgychwyn nesaf, fel arfer yn ystod ffenestr cynnal a chadw nad oes neb yn cysylltu'r newid â hi.

Dwy ffordd i wneud y disodliad yn anghywir

Mae cyfieithu'r pwll i gyfeiriad twnnel y gweinydd yn lle ei gyfeiriad LAN yn anfon atebion yn syth yn ôl i'r twnnel, lle cânt eu llwybro tuag at gleient na ofynnodd amdanynt erioed. Mae'r cysylltiad yn stopio mewn ffordd sy'n edrych fel dolen llwybro oherwydd dolen ydyw.

Pentyrru ail gyfieithiad uwchben yr hen un yw'r camgymeriad arall. Y rheol gyntaf sy'n cyfateb sy'n ennill, felly mae'r cofnod darfodedig yn dal i drin pecynnau nes iddo gael ei ddileu, ac mae cyfrifwyr y rheol newydd yn aros ar sero tra bo pawb yn beio'r disodliad. Dilëwch y dyblyg cyn ychwanegu unrhyw beth newydd. Yna darllenwch y rhestr unwaith eto a chadarnhau mai dim ond un cyfieithiad sy'n cyfateb i'r pwll.

Os yw'r twnnel hefyd yn cario IPv6, ailadroddwch yr adolygiad cyfan ar y pentwr arall. Mae llwybr diofyn IPv6 heb gyfieithiad a heb ragddodiad wedi'i lwybro yn methu yr un mor dawel, ac mae'n hawdd ei anghofio oherwydd bod popeth uwch ei ben yn edrych yn unfath.

Mae angen y cyfieithiad arall ar wasanaethau sy'n dod i mewn

Mae gwasanaeth ar gleient VPN y mae'n rhaid ei gyrraedd o'r tu allan angen cyfieithiad cyrchfan, nid cyfieithiad ffynhonnell: mae'r porth cyhoeddus yn cael ei ailysgrifennu i gyfeiriad twnnel y cleient cyn iddo ddod i mewn. Yna mae angen rheol benodol ar y llwybr anfon ymlaen sy'n caniatáu'r traffig hwnnw.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Peidiwch byth â chyfieithu'r porth sy'n cario'r twnnel ei hun, oherwydd bod yr ailysgrifennu hwnnw'n torri'r cysylltiad sy'n cadw'r gwasanaeth yn gyrraeddadwy. Cadwch borth y twnnel yn gyfan gwbl allan o'r rheolau cyrchfan. Gwiriwch o'r ddau ben wedyn: cyfrifwyr ar y rheol newydd, cipolwg byr ar y ddyfais twnnel, ac un cais i gyfeiriad y tu mewn i'r twnnel cyn i chi roi cynnig ar yr un cyhoeddus.