Pam mae net.ipv4.conf.default.forwarding yn gadael tun0 yn llonydd

Gosodoch net.ipv4.conf.default.forwarding=1, ailgychwynnwyd y VPN, ac mae'r tunel yn dal i ollwng pecynnau y dylai'r porth allu eu cyfeirio. Mae'r gosodiad yn edrych yn iawn yn y ffeil, ac mae'r rhyngwyneb yn dal i adrodd bod anfon ymlaen wedi'i analluogi. Nid oes dim wedi torri: gwnaethoch newid y gwerth y mae rhyngwynebau'r dyfodol yn ei etifeddu, nid yr un y mae'r tunel byw yn ei ddefnyddio.

Ewch drwy hyn ar y gwesteiwr sy'n berchen ar y tunel, yn y namespace rhwydwaith lle mae'r tunel yn bodoli mewn gwirionedd. Gall cynhwysydd neu namespace rhwydwaith ddal y rhyngwyneb tra bod y gwesteiwr yn dangos rhifau gwahanol.

Darllenwch y tri gwerth gyda'i gilydd

Dechreuwch drwy gymharu'r switsh ar draws y porth, y templed ar gyfer rhyngwynebau newydd, a'r rhyngwyneb sy'n bwysig i chi. Amnewidiwch tun0 gyda'r rhyngwyneb mynediad go iawn, a darllenwch y rhyngwyneb dychwelyd hefyd, oherwydd mae anfon ymlaen yn cael ei werthuso ar y pwynt lle mae'r pecyn yn cyrraedd.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Canlyniad cyffredin yw ip_forward = 0, default.forwarding = 1 a tun0.forwarding = 0. Nid yw'r ddau gyntaf yn cytuno ynghylch rôl y gwesteiwr, ac mae'r trydydd yn dangos beth mae'r rhyngwyneb yn ei wneud mewn gwirionedd. Mae'r cyfuniad hwnnw'n gyson â gwesteiwr na chafodd ei ffurfweddu fel llwybrydd erioed, dim ond gwerth templed. Nid yw'r tri rhif yn gwrth-ddweud ei gilydd; maent yn ateb tri chwestiwn gwahanol. Nid yw ysgrifennu gwerth y templed yn penderfynu rôl y gwesteiwr chwaith.

Pam mai'r switsh byd-eang sy'n symud

net.ipv4.ip_forward yw'r rheolaeth ar draws y porth. Mae ei newid yn diweddaru'r gosodiadau anfon ymlaen fesul rhyngwyneb fel rhan o'r un gweithrediad, a dyna pam y gall un ysgrif wneud i dunel sy'n bodoli eisoes ddechrau anfon ymlaen. default.forwarding dim ond hadu'r rhyngwynebau a gaiff eu cychwyn wedyn, felly mae tunel a oedd eisoes yn bodoli yn cadw'r gwerth y cafodd ei eni ag ef.

Mae dogfennaeth y cnewyllyn yn nodi ip_forward fel un arbennig am reswm cysylltiedig: mae ei newid yn ailosod set o baramedrau IPv4 eraill i'r rhagosodiadau ar gyfer gwesteiwr neu lwybrydd. Mae hynny'n ei wneud yn offeryn pŵl. Mae ei osod unwaith fel rhan o sefydlu rôl y porth yn iawn; mae ei doglo dro ar ôl tro fel tric dadfygio yn gallu ailysgrifennu'n ddistaw ffurfweddiad y buoch yn amser yn ei gael yn iawn.

Mae gwerthoedd fesul rhyngwyneb yn bodoli am reswm hefyd. Gall porth a reolir yn fwriadol gadw anfon ymlaen i ffwrdd ar ryngwyneb na ddylai byth lwybro, hyd yn oed tra bod y gwesteiwr yn anfon ymlaen yn rhywle arall. Dyna pam mae darllen y rhyngwyneb byw yn bwysig a pham nad yw'r gwerth byd-eang ar ei ben ei hun yn ateb cyflawn. Darllenwch eithriad o'r fath fel penderfyniad bwriadol, ac ysgrifennwch pam mae'r rhyngwyneb hwnnw'n wahanol. Fel arall bydd y peiriannydd nesaf yn ei "drwsio" yn garedig.

Gwnewch y gosodiad yn barhaol yn y lle iawn

Mae sysctl -w unigol llwyddiannus yn profi bod y cnewyllyn yn derbyn y gwerth. Nid yw'n goroesi ailgychwyn, ac nid yw'n goroesi rheolwr rhwydwaith sy'n ailddefnyddio ei syniad ei hun o ffurfweddiad y rhyngwyneb wrth ailgysylltu. Rhowch rôl y porth yn y ffeil ffurfweddu sysctl neu yn y rheolwr rhwydwaith sy'n berchen ar y gwesteiwr, yna ailgychwynnwch y gwasanaeth sy'n ei ddefnyddio.

Mae trefn yn bwysig gyda thuneli. Os yw'r rheolwr yn creu'r rhyngwyneb wrth gychwyn ac yn defnyddio anfon ymlaen wedyn, gall y rhyngwyneb etifeddu'r hen ragosodiad. Mae ailgychwyn gwasanaeth sy'n ailgreu'r tunel hefyd yn ddigwyddiad creu, ac mae'n hawdd ei golli pan fydd yr uned yn edrych yn iach. Gwiriwch y dilyniant, nid cynnwys terfynol y ffeil yn unig.

Ailddarllenwch yr un tri gwerth ar ôl i'r VPN ailgysylltu ac unwaith eto ar ôl ailgychwyn. Mae tunel newydd ei greu yn rhyngwyneb newydd, ac mae rhyngwyneb newydd yn cymryd y rhagosodiad sy'n weithredol ar adeg ei greu. Os yw'r rhifau'n newid ar draws y digwyddiadau hynny, mae rhywbeth nad ydych wedi'i nodi eto yn defnyddio'r ffurfweddiad.

Peidiwch â thrwsio hyn gyda'r offeryn anghywir

Pan oedd anfon ymlaen yn edrych yn doredig, y demtasiwn yw fflysio'r mur gwarchod neu ychwanegu masquerading. Nid yw'r un o'r ddau yn mynd i'r afael â'r switsh anfon ymlaen. Mae cyflwr anfon ymlaen, caniatâd i anfon ymlaen, llwybr i'r cyrchfan, a llwybr dychwelyd yn bedwar gofyniad ar wahân, a dim ond y cyntaf yw'r sysctl.

Profwch gyda'r llif cywir hefyd. Nid yw cais a wneir ar y porth ei hun yn arfer anfon ymlaen o gwbl; traffig a gynhyrchir yn lleol ydyw. Y cwestiwn yw a yw pecyn sy'n cyrraedd o gleient VPN neu o westeiwr LAN yn cael ei dderbyn a'i lwybro ymlaen, felly rhaid i'r prawf ddechrau y tu ôl i'r porth.

Cadwch achos IPv6 ar wahân

Mae popeth yma yn IPv4. Mae gan anfon ymlaen IPv6, hysbysebion llwybrydd, ac ymddygiad accept_ra eu rheolaethau eu hunain, ac mae copïo llwybr ipv4 i osodiad ipv6 yn cynhyrchu ffeil sy'n edrych yn gredadwy ac yn gwneud dim defnyddiol. Mae angen i borth â stac dwbl gael y ddau set wedi'u ffurfweddu'n fwriadol.

Un gwiriad olaf: ar ôl i'r gwerthoedd gytuno, cadarnhewch fod llwybr y tunel yn cael ei ddewis ar gyfer y gyrchfan a bod y llwybr ateb yn bodoli. Mae anfon ymlaen wedi'i alluogi ar ryngwyneb heb lwybr yn dal i fod yn dwll du, ac mae'r methiant hwnnw'n edrych yr un peth o safbwynt y cleient.