Láttu IPv4-framsendingu vara við endurræsingu VPN-gáttar

Að pikka gáttina virkar en að ná í hvað sem er fyrir aftan hana ekki, og það er lögun framsendingarvandamáls en ekki gönguvandamáls. Staðbundin afhending til gáttarinnar sannar að göngin komust upp og að úthlutun vistfangs tókst; hún segir ekkert um hvort kjarninn láti pakka fara frá einu viðmóti til annars. Áður en þú snertir nokkurt sysctl, staðfestu að vélin eigi að beina þessum umferðarstraumi og finndu netumhverfið sem heldur viðmótinu sem snýr að viðskiptavininum. Lestu síðan gildið þar, ekki þar sem síðasta leiðarvísirinn sem þú las horfði fyrir tilviljun.

Að ná til gáttarinnar er ekki það sama og framsending

Tvær aðskildar ákvarðanir eiga sér stað inni í kjarnanum. Afhending á staðbundið vistfang endar ferð pakkans; framsending sendir hann aftur út um annað viðmót, og sú önnur ákvörðun er stýrt fyrir hvert netnafnrými. Gátt getur verið fullkomlega aðgengileg á meðan framsending er slökkt, og frá ping-ákvaði líta báðar bilanirnar eins út.

Skrifaðu niður hvaða viðmót pakki viðskiptavinarins kemur inn á og hvaða viðmót leiðin áfram fer út um. Bæði tilheyra einu nafnrými, og það nafnrými heldur stillingunni sem skiptir máli.

Lestu gildið þar sem pakkarnir eru í raun

Á gátt sem beinir í nafnrými hýsilsins svarar ein skipun spurningunni: sysctl net.ipv4.ip_forward. Þegar innkomuleiðin og leiðin áfram lifa í nefndu nafnrými, spurðu það nafnrými: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Gildi hýsilsins er ekki staðgengill fyrir gildi nafnrýmisins, og einn á hýsilnum er engin sönnun fyrir neinu.

Ekki hefur hvert beiningarumhverfi merki sem þú getur gefið ip netns. Keyrsluumhverfi gáma og þjónustur búa til nafnrými sem eru aldrei skráð undir vingjarnlegu nafni, og fyrir þau notar þú skoðunartól keyrsluumhverfisins. Skiptu vpn-gw út fyrir raunverulega nafnið, eða fyrir kerfi keyrsluumhverfisins sem nær sama umhverfi, og hættu að giska á hýsilplaninu.

Gefðu stillingunni einn eiganda

Á hefðbundinni systemd-hýsilgátt er varanlega formið drop-in skrá með nafni sem stjórnandinn velur, eins og /etc/sysctl.d/60-vpn-forwarding.conf, sem inniheldur net.ipv4.ip_forward = 1. Skrifaðu skrána og hladdu síðan einmitt þeirri skrá svo lifandi ástand breytist líka: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, og lestu svo til baka. Skráarnafnið er dæmi en ekki frátekin VPN-slóð, og fremsta talan skiptir máli því skrár sem raðast síðar vinna.

Forgangur er þar sem varanleiki brotnar hljóðlega. Athugaðu bæði hleðslutæki dreifingarinnar og þína eigin drop-in, því procps sysctl --system les líka /etc/sysctl.conf í lokin, á meðan sysctl.d-röð systemd er allt önnur röð. Síðari úthlutun getur sett sama lykil strax aftur og skilið skrána þína rétta en virka gildið rangt. Ekki skrifa yfir fyrirliggjandi stjórnandaskrá til að vinna þann rökþrætu; finndu eigandann og breyttu þar.

Nafnrými sem búið er til eftir ræsingu er alls ekki stýrt af hýsildrop-in. Stilling þess tilheyrir því sem býr það til, hvort sem það er keyrsluumhverfi gáma eða úthlutunareining nafnrýmisins. Að gefa gámi víðtæk hýsilréttindi til að komast hjá spurningunni er verri skipti en að eyða tíu mínútum í að bera kennsl á rétta eigandann.

Vitaðu hvað rofinn kostar áður en þú varpar honum

ip_forward er ekki meinlaust boolean. Kjarnaskjölin benda á að breyting á því endurstilli nokkur önnur IPv4-færibreytur í sjálfgefna gildi hýsils eða beinis, svo greiningarvarp getur hent stillingum sem gerðar voru annars staðar og aldrei nefnt það. Meðhöndlaðu það sem stillingabreytingu með aukaverkunum, ekki sem prófun sem hægt er að keyra kærulaus.

Það útilokar líka að slökkva og kveikja á því í hvert sinn sem viðskiptavinur nær ekki hýsli. Ef gildið er þegar einn er bilunin annars staðar á leiðinni, og að endurskrifa sama lykil í þriðja sinn færir hann ekki.

Sannaðu varanleikann og prófaðu síðan afgang leiðarinnar

Lestu gildið aftur á fjórum augnablikum: strax eftir breytinguna, eftir að VPN-viðmótið birtist, eftir endurtengingu og eftir fyrirhugaða endurræsingu. Gildi sem fellur til baka á einhverjum þessara punkta hefur annan eiganda, og ein skrif í viðbót fela það bara þar til næsta endurræsing.

Kveikt framsending skilur samt eftir þrjú atriði til að staðfesta. Viðskiptavinurinn þarf leið að áfangastaðnum, gáttin þarf leið áfram auk leyfis til að nota hana, og áfangastaðurinn þarf afturleið að gönguvistfangi viðskiptavinarins. Einkarekið beint LAN þarf ekki NAT sjálfkrafa, svo bættu ekki masquerading við fyrr en þú veist hvert þriggja vantar, og prófaðu frá fyrirhuguðum viðskiptavini en ekki frá gáttinni sjálfri, því beiðni sem á upptök sín á gáttinni snertir aldrei framsendingarleiðina sem þú varst að virkja. IPv6 ber eigin framsendingar- og beiningarstefnu, svo virk IPv4-prófun segir ekkert um hana.

Haltu drop-in-slóðinni, eiganda nafnrýmisins og lestrarskipuninni saman í runbookinu. Sá sem tekur þetta næst ætti að geta lesið gildið, séð hver á það og ákveðið innan mínútu hvort vandamálið er varanleiki eða afgangur leiðarinnar.