Cleient VPN ar weinydd LAN: pam mae atebion yn gadael ar y ffordd anghywir
Mae gwesteiwr sy’n deialu VPN yn cael llwybr diofyn, felly mae atebion i gleientiaid LAN yn gadael drwy’r twnnel. Ychwanegwch y llwybr dychwelyd culach a’i wirio.
Mae’r symptomau’n dilyn un patrwm: mae gwesteiwr yn gweithio, yna mae’n cysylltu â VPN fel cleient, ac yn awr mae cleientiaid LAN yn ei gyrraedd tra bod ei atebion yn diflannu. Mae cipiad ar y gwesteiwr yn dangos bod yr atebion yn gadael drwy ddyfais y twnnel yn lle rhyngwyneb y LAN. Nid oes dim wedi torri yn y twnnel, a llwybr yw’r ateb, nid ailgysylltu. Ewch drwy’r pedwar gwiriad isod yn eu trefn a stopiwch ar yr un cyntaf sy’n methu.
Mae ateb yn becyn newydd, nid gwrthdroi’r llwybr
Mae’n helpu i ollwng y syniad bod ateb yn teithio’n ôl ar hyd y llwybr yr aeth cais arno. Mae llwybro’n cael ei benderfynu fesul pecyn, fesul cyfeiriad, ar y gwesteiwr sy’n anfon. Nid yw cais a gyrhaeddodd o 10.64.0.23 y tu mewn i’r twnnel yn creu unrhyw lwybr dychwelyd; pan fydd y gwesteiwr yn ateb, mae’r ateb hwnnw’n cael ei baru â’r tabl fel pecyn newydd ac yn gadael ar hyd y llwybr sy’n ennill.
Dyna pam mae cleient twnnel llawn ar beiriant sy’n gwasanaethu LAN hefyd yn cynhyrchu methiant mor ddryslyd. Mae’r cleient yn gosod llwybr diofyn, neu’r ddau hanner llwybr diofyn y mae rhai cleientiaid yn eu ffafrio, ac mae’r ateb i gleient LAN yn awr yn cyfateb i’r twnnel. Mae’n mynd i’r darparwr, nad oes ganddo reswm i’w anfon ymlaen, ac mae’r cleient LAN yn gweld goramser er bod y gwesteiwr i fyny ac yn ateb yn lleol. Mae’r cipiad yn ei wneud yn amlwg, ac mae’r tabl llwybro’n ei esbonio.
Cadwch ddau isrwydwaith yn eich pen wrth ddarllen y gweddill. Un yw cronfa gyfeiriadau VPN y daw’r cleientiaid o bell ohoni, yn yr enghraifft hon 10.64.0.0/24. Y llall yw’r LAN sy’n rhaid parhau i weithio, 172.16.24.0/24 gyda’i lwybrydd yn 172.16.24.1. Y nam yw bod y traffig rhyngddynt yn cael ei benderfynu gan y llwybr diofyn.
Profwch hyn gyda’r cipiad a’r chwiliad
Cyn newid unrhyw beth, cadarnhewch pa ddyfais fydd yr ateb yn ei defnyddio. Mae chwiliad yn gyflymach na chipiad ac yn ateb yr union gwestiwn y bydd y cnewyllyn yn ei ateb pan gaiff y pecyn ei adeiladu.
ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp
Darllenwch yr ateb mewn dwy ran. Os yw’n enwi dev tun0, bydd y gwesteiwr yn rhannu’r ateb ac yn ei drosglwyddo i’r darparwr, ac ni fydd y cleient LAN byth yn ei weld. Os yw’n enwi dev eth0 ond bod y cleient yn dal i gael goramser, mae’r llwybr eisoes yn iawn ac mae’r pecyn yn cael ei ollwng yn ddiweddarach, sef problem wahanol gyda chyweiriad gwahanol.
Mae’r cipiad yn yr un cam yn setlo’r amheuaeth na all ping ei setlo. Mae ateb adlais yn cyrraedd y cleient LAN yn profi bod rhyw lwybr yn gweithio, nid pa ryngwyneb a’i cariodd, felly rhedegwch y cipiad ar y gwesteiwr ei hun a gwyliwch o ble mae’r fframiau’n gadael. Mae argraffydd ar yr un isrwydwaith yn parhau i ateb, oherwydd mae ei lwybr uniongyrchol yn fwy penodol na llwybr diofyn y twnnel. Mae porthladd a anfonwyd ymlaen yn methu’n union fel unrhyw lif arall, oherwydd y tabl sy’n dewis y rhyngwyneb, nid y cysylltiad.
Gosodwch y llwybr culaf sy’n trechu’r twnnel
Hyd y rhagddodiad sy’n penderfynu, nid y metrig, felly mae llwybr i’r gronfa gleientiaid drwy lwybrydd y LAN yn ennill dros unrhyw lwybr diofyn y mae’r cleient VPN yn ei osod. Nid oes angen llawdriniaeth fetrig, a gall y llwybr diofyn aros yn union lle y gosododd y cleient ef.
ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10
Defnyddiwch replace yn lle add, oherwydd bydd cleient sy’n ailgysylltu wedi gosod ei gofnod ei hun ac mae ail add yn methu â gwall llwybr sy’n bodoli eisoes sy’n darllen fel problem caniatâd. Ar westeiwr Windows y cyfateb yw route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, lle mae -p yn cadw’r cofnod dros ailgychwyn, gan y gall y cleient ailadeiladu’r tabl pan ddaw’r twnnel yn ôl i fyny. Ar westeiwr Windows cyfredol y cyfateb a gefnogir yw New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, gyda’r gorchymyn route hŷn yn cael ei gadw fel ffurf etifeddol.
Mae un manylyn yn penderfynu a yw hyn yn gywir ai dim ond yn gredadwy: rhaid i’r naid nesaf fod y llwybrydd sy’n berchen ar y llwybr yn ôl at y cleientiaid. Mae cyfeirio’r llwybr at gyfeiriad y cyrhaeddir ef ei hun drwy’r twnnel yn creu dolen sy’n ymddangos fel colled ysbeidiol yn hytrach na methiant glân. Cadarnhewch fod y naid nesaf ar isrwydwaith y LAN cyn cyflawni’r llinell.
Cadwch yr ateb ar ôl ailgysylltu
Mae llwybr a ychwanegwyd â llaw yn goroesi hyd at yr ailgysylltiad nesaf ar y gorau. Os yw’r gronfa gleientiaid yn ddynamig, pinwch hi yng nghyfluniad y gweinydd fel bod y rhagddodiad a lwybrwyd gennych yn parhau i fod y rhagddodiad a gaiff cleientiaid; fel arall mae’r cofnod yn pwyntio at ystod wag ac mae’r symptom yn dychwelyd wythnosau’n ddiweddarach heb achos amlwg. Mae ysgrifennu’r llwybr yn sgript up y cleient ei hun yn opsiwn dibynadwy arall, oherwydd mae’n rhedeg ar ôl i’r cleient ailysgrifennu’r tabl.
Gall mur tân cyflwr guro llwybr cywir o hyd. Os yw’r cipiad yn awr yn dangos bod yr ateb yn gadael drwy eth0 a bod y cleient yn dal i gael goramser, gwiriwch a yw’r gwesteiwr yn gollwng y pecyn cyn ei anfon. Hidlo llwybr cefn llym a net.ipv4.conf.all.rp_filter wedi’i osod i 1 yn gollwng pecynnau na fyddai eu ffynhonnell yn cael ei llwybro’n ôl allan drwy’r rhyngwyneb y gwnaethant gyrraedd arno, sef yn union yr achos anghymesur yr ydych newydd ei greu ac yna ei drwsio, ac mae cyflwr conntrack yn adrodd yr un stori ar gyfer porthladdoedd a anfonwyd ymlaen.
Y gwiriad olaf yw’r un y mae pobl yn ei hepgor: ailadroddwch y chwiliad ar ôl i’r twnnel fod i lawr ac i fyny eto. Dylai pedwar gwerth gyfateb i’r hyn a ysgrifennwyd gennych: y cyrchfan, y naid nesaf, y ddyfais a’r ffynhonnell a ddewiswyd. Os symudodd unrhyw un ohonynt, mae’r cleient wedi ailysgrifennu’r tabl ac mae’r cywiriad yn perthyn i’w fachau yn hytrach nag i hanes y shell.