Tee IPv4-edelleenohjauksesta pysyvä VPN-yhdyskäytävän uudelleenkäynnistyksen yli

Yhdyskäytävän pingaaminen toimii ja mihinkään sen takana pääseminen ei, ja se on edelleenohjausongelman eikä tunneliongelman muoto. Paikallinen toimitus yhdyskäytävälle todistaa, että tunneli nousi ja osoitteen jako onnistui; se ei kerro mitään siitä, päästääkö ydin paketin yhdestä liittymästä toiseen. Ennen kuin kosket mihinkään sysctl-asetukseen, varmista, että kone on tarkoitettu reitittämään tätä liikennettä ja paikanna verkkokonteksti, joka pitää asiakkaaseen päin olevaa liittymää. Lue arvo sitten sieltä, älä sieltä mihin viimeksi lukemasi opas sattui katsomaan.

Yhdyskäytävään pääseminen ei ole sama kuin edelleenohjaus

Ytimen sisällä tehdään kaksi erillistä päätöstä. Toimitus paikalliseen osoitteeseen päättää paketin matkan; edelleenohjaus lähettää sen uudelleen ulos toisen liittymän kautta, ja tätä toista päätöstä ohjataan verkkonimiavaruuskohtaisesti. Yhdyskäytävä voi olla täysin tavoitettavissa, kun edelleenohjaus on pois päältä, ja ping-kehotteesta molemmat viat näyttävät samanlaisilta.

Kirjaa, mille liittymälle asiakaspaketti saapuu ja minkä liittymän kautta jatkoreitti lähtee. Molemmat kuuluvat yhteen nimiavaruuteen, ja se nimiavaruus pitää asetusta, jolla on merkitystä.

Lue arvo sieltä, missä paketit todella ovat

Yhdyskäytävällä, joka reitittää isäntänimiavaruudessa, yksi komento vastaa kysymykseen: sysctl net.ipv4.ip_forward. Kun saapumis- ja jatkoreitti elävät nimellyssä nimiavaruudessa, kysy sitä nimiavaruutta: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Isännän arvo ei korvaa nimiavaruuden arvoa, eikä ykkönen isännällä todista mitään.

Jokaisella reitityskontekstilla ei ole tunnistetta, jonka voisit antaa komennolle ip netns. Konttien ajonaikaiset ympäristöt ja palvelut luovat nimiavaruuksia, joita ei koskaan rekisteröidä ystävällisellä nimellä, ja niitä varten käytät ajonaikaisen ympäristön tarkistustyökaluja. Korvaa vpn-gw todellisella nimellä tai ajonaikaisen ympäristön mekanismilla, joka saavuttaa saman kontekstin, ja lopeta arvailu isäntätasolla.

Anna asetukselle yksi omistaja

Tavanomaisella systemd-isäntäyhdyskäytävällä pysyvä muoto on drop-in-tiedosto, jonka nimi on järjestelmänvalvojan valitsema, esimerkiksi /etc/sysctl.d/60-vpn-forwarding.conf, ja joka sisältää net.ipv4.ip_forward = 1. Kirjoita tiedosto ja lataa sitten juuri se tiedosto, jotta myös elävä tila muuttuu: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, jota seuraa takaisinluku. Tiedostonimi on esimerkki eikä varattu VPN-polku, ja etunumero on merkityksellinen, koska myöhemmin lajitellut tiedostot voittavat.

Ensisijaisuus on paikka, jossa pysyvyys hiljaa rikkoutuu. Tarkista sekä jakelun lataaja että oma drop-in-tiedostosi, koska procps sysctl --system lukee lopussa myös tiedoston /etc/sysctl.conf, kun taas systemdin sysctl.d-järjestys on täysin eri sekvenssi. Myöhempi määritys voi asettaa saman avaimen suoraan takaisin, jolloin tiedostosi on oikein ja tehollinen arvo väärin. Älä ylikirjoita olemassa olevaa järjestelmänvalvojan tiedostoa voittaaksesi tuon väittelyn; etsi omistaja ja muuta siellä.

Käynnistyksen jälkeen luotua nimiavaruutta ei hallita lainkaan isännän drop-in-tiedostolla. Sen asetus kuuluu sille, mikä sen luo, oli se sitten konttien ajonaikainen ympäristö tai nimiavaruuden valmisteluyksikkö. Laajojen isäntäoikeuksien antaminen kontille kysymyksen kiertämiseksi on huonompi kauppa kuin kymmenen minuutin käyttäminen oikean omistajan tunnistamiseen.

Tiedä, mitä kytkin maksaa ennen kuin käännät sitä

ip_forward ei ole harmiton boolean. Ytimen dokumentaatio huomauttaa, että sen muuttaminen palauttaa useita muita IPv4-parametreja isännän tai reitittimen oletusarvoihin, joten diagnostinen käännös voi heittää pois muualla tehdyn virityksen eikä mainita sitä koskaan. Käsittele sitä sivuvaiikutuksia sisältävänä kokoonpanomuutoksena, älä kokeiluna, jonka voi ajaa huolettomasti.

Se sulkee pois myös sen pois päältä ja päälle kytkemisen joka kerta, kun asiakas ei tavoita isäntää. Jos arvo on jo yksi, vika on muualla reitillä, eikä saman avaimen kolmas uudelleenkirjoitus siirrä sitä.

Todista pysyvyys ja testaa sitten reitin loppuosa

Lue arvo takaisin neljänä hetkenä: heti muutoksen jälkeen, VPN-liittymän ilmestyttyä, uudelleenyhdistämisen jälkeen ja suunnitellun uudelleenkäynnistyksen jälkeen. Arvolla, joka palautuu jossakin näistä kohdista, on toinen omistaja, ja vielä yksi kertaluonteinen kirjoitus vain kätkee sen seuraavaan uudelleenkäynnistykseen asti.

Päällä oleva edelleenohjaus jättää silti kolme asiaa tarkistettavaksi. Asiakas tarvitsee reitin kohteeseen, yhdyskäytävä tarvitsee jatkoreitin sekä luvan käyttää sitä, ja kohde tarvitsee paluureitin asiakkaan tunneliosoitteeseen. Yksityinen reititetty LAN ei tarvitse automaattisesti NATia, joten älä lisää masqueradingia ennen kuin tiedät, mikä kolmesta puuttuu, ja testaa aiotusta asiakkaasta eikä yhdyskäytävästä itsestään, koska yhdyskäytävällä alkanut pyyntö ei koskaan kosketa juuri käyttöön ottamaasi edelleenohjausreittiä. IPv6:lla on oma edelleenohjaus- ja reitityskäytäntönsä, joten toimiva IPv4-testi ei kerro siitä mitään.

Pidä drop-in-polku, nimiavaruuden omistaja ja takaisinlukukomento yhdessä runbookissa. Seuraavan tämän haltuunsa ottavan pitäisi pystyä lukemaan arvo, näkemään kuka sen omistaa ja päättämään minuutin kuluessa, onko ongelma pysyvyydessä vai reitin loppuosassa.