Maak IPv4-deurvervoer blywend na ’n herbegin van die VPN-grendel

Om die grendel te ping werk, maar om iets agter hom te bereik werk nie; dit is die vorm van ’n deurvervoerprobleem eerder as ’n tonnelprobleem. Plaaslike aflewering aan die grendel bewys dat die tonnel opgekom het en die adrestoewysing gewerk het; dit sê niks oor of die kernel ’n pakket van een koppelvlak na ’n ander sal deurgee nie. Voordat jy aan ’n sysctl raak, bevestig dat die masjien veronderstel is om hierdie verkeer te roeteer en vind die netwerkkonteks wat die kliëntgerigte koppelvlak bevat. Lees dan die waarde daar, eerder as waar die laaste gids wat jy gelees het toevallig gekyk het.

Om die grendel te bereik is nie dieselfde as deurvervoer nie

Twee afsonderlike besluite vind binne die kernel plaas. Aflewering aan ’n plaaslike adres beëindig die pakket se reis; deurvervoer stuur dit weer uit deur ’n ander koppelvlak, en daardie tweede besluit word per netwerknaamruimte beheer. ’n Grendel kan heeltemal bereikbaar wees terwyl deurvervoer af is, en vanuit ’n ping-opdrag lyk die twee foute identies.

Skryf neer op watter koppelvlak die kliëntpakket aankom en deur watter koppelvlak die verdere pad vertrek. Albei behoort aan een naamruimte, en daardie naamruimte hou die instelling wat saak maak.

Lees die waarde waar die pakkette werklik is

Op ’n grendel wat in die gasheernaamruimte roeteer, beantwoord een opdrag die vraag: sysctl net.ipv4.ip_forward. Wanneer die inkomende en verdere pad in ’n benoemde naamruimte woon, vra daardie naamruimte eerder: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Die gasheerwaarde is nie ’n plaasvervanger vir die naamruimtewaarde nie, en ’n een op die gasheer is geen bewys van enigiets nie.

Nie elke roeteringkonteks het ’n etiket wat jy aan ip netns kan gee nie. Houer-tydloopomgewings en dienste skep naamruimtes wat nooit onder ’n vriendelike naam geregistreer word nie, en vir dié gebruik jy die tydloop se inspeksienutsgoed. Vervang die werklike naam vir vpn-gw, of die tydloopmeganisme wat dieselfde konteks bereik, en hou op om op gasheervlak te raai.

Gee die instelling ’n enkele eienaar

Op ’n konvensionele systemd-gasheergrendel is die duursame vorm ’n drop-in-lêer met ’n deur die administrateur gekose naam soos /etc/sysctl.d/60-vpn-forwarding.conf wat net.ipv4.ip_forward = 1 bevat. Skryf die lêer, en laai dan daardie spesifieke lêer sodat die lewende toestand ook verander: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, gevolg deur ’n teruglees. Die lêernaam is ’n voorbeeld eerder as ’n gereserveerde VPN-pad, en die voorste nommer maak saak omdat later gesorteerde lêers wen.

Voorrang is waar volharding stilweg breek. Kontroleer die verspreidingslaaier sowel as jou eie drop-in, want procps sysctl --system lees ook /etc/sysctl.conf aan die einde, terwyl systemd se sysctl.d-volgorde heeltemal ’n ander reeks is. ’n Latere toewysing kan dieselfde sleutel reguit terugstel, wat jou lêer korrek laat en die effektiewe waarde verkeerd. Moenie ’n bestaande administrateurlêer oorskryf om daardie argument te wen nie; vind die eienaar en verander dit daar.

’n Naamruimte wat ná die opstart geskep is, word glad nie deur ’n gasheer-drop-in beheer nie. Sy instelling behoort aan wat dit ook al skep, of dit nou die houer-tydloop of die voorsieningseenheid vir die naamruimte is. Om ’n houer breë gasheervoorregte te gee om die vraag te ontduik, is ’n slegter ruil as om tien minute te spandeer om die regte eienaar te identifiseer.

Weet wat die skakelaar kos voordat jy dit omdraai

ip_forward is nie ’n onskadelike booleaan nie. Die kernel-dokumentasie noem dat die verandering daarvan verskeie ander IPv4-parameters na hul gasheer- of roeteerderverstek terugstel, so ’n diagnostiese omskakeling kan fyn instellings wat elders gedoen is, weggooi en dit nooit noem nie. Behandel dit as ’n konfigurasieverandering met newe-effekte eerder as ’n toets wat jy lugsig kan uitvoer.

Dit sluit ook uit om dit elke keer af en aan te skakel wanneer ’n kliënt nie ’n gasheer kan bereik nie. As die waarde reeds een is, is die fout elders in die pad, en om dieselfde sleutel ’n derde keer te herskryf sal dit nie beweeg nie.

Bewys volharding, en toets dan die res van die pad

Lees die waarde op vier oomblikke terug: direk ná die verandering, nadat die VPN-koppelvlak verskyn, ná ’n herverbinding, en ná ’n beplande herbegin. ’n Waarde wat op enige van daardie punte terugkeer, het ’n tweede eienaar, en nog een eenmalige skrywe verberg dit net tot die volgende herbegin.

Deurvervoer wat geaktiveer is, laat steeds drie dinge oor om te verifieer. Die kliënt het ’n roete na die bestemming nodig, die grendel het ’n verdere roete plus toestemming om dit te gebruik nodig, en die bestemming het ’n terugpad na die kliënt se tonneladres nodig. ’n Privaat geroteerde LAN het nie outomaties NAT nodig nie, so moenie masquerading byvoeg voordat jy weet watter van die drie ontbreek nie, en toets vanuit die bedoelde kliënt eerder as van die grendel self, want ’n versoek wat op die grendel ontstaan het, raak nooit die deurvervoerpad wat jy pas geaktiveer het nie. IPv6 dra sy eie deurvervoer- en roeteringbeleid, so ’n werkende IPv4-toets sê niks daaroor nie.

Hou die drop-in-pad, die naamruimte-eienaar en die terugleesopdrag saam in die runbook. Wie dit volgende optel, moet die waarde kan lees, sien wie dit besit, en binne ’n minuut besluit of die probleem volharding of die res van die pad is.