Tehke IPv4 edastamine püsivaks üle VPN-lüüsi taaskäivituse

Lüüsi pingimine töötab ja selle taga olevale millelegi jõudmine ei tööta, ning see on edastusprobleemi, mitte tunneliprobleemi kuju. Kohalik tarne lüüsile tõestab, et tunnel tõusis ja aadressi määramine õnnestus; see ei ütle midagi selle kohta, kas kernel annab paketi ühest liidesest teise edasi. Enne mis tahes sysctl-i puudutamist kinnitage, et masin on mõeldud seda liiklust marsruutima ja leidke võrgukontekst, mis hoiab kliendi poole suunatud liidest. Seejärel lugege väärtust seal, mitte seal, kuhu viimati loetud juhend juhtumisi vaatas.

Lüüsile jõudmine ei ole sama mis edastamine

Kerneli sees tehakse kaks eraldi otsust. Kohalikule aadressile tarnimine lõpetab paketi teekonna; edastamine saadab selle uuesti välja teise liidese kaudu ja seda teist otsust juhitakse võrgu nimeruumi kaupa. Lüüs võib olla täiesti kättesaadav, samal ajal kui edastamine on väljas, ja pingi viibalt näevad need kaks riket ühesugused välja.

Pange kirja, millisele liidesele kliendi pakett saabub ja millise liidese kaudu edasine tee väljub. Mõlemad kuuluvad ühte nimeruumi ja see nimeruum hoiab seadistust, mis loeb.

Lugege väärtust seal, kus paketid tegelikult on

Lüüsil, mis marsruudib hosti nimeruumis, vastab küsimusele üks käsk: sysctl net.ipv4.ip_forward. Kui sissetulev ja edasine tee elavad nimetatud nimeruumis, küsige sellelt nimeruumilt: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Hosti väärtus ei asenda nimeruumi väärtust ja üks hostil ei ole millegi tõestuseks.

Igal marsruutimiskontekstil ei ole silti, mille saaksite anda käsule ip netns. Konteinerite käituskeskkonnad ja teenused loovad nimeruumi, mida ei registreerita kunagi sõbraliku nime all, ja nende jaoks kasutate käituskeskkonna kontrollivahendeid. Asendage vpn-gw tegeliku nimega või käituskeskkonna mehhanismiga, mis jõuab samasse konteksti, ja lõpetage hosti tasandil oletamine.

Andke seadistusele üks omanik

Tavalisel systemd-hostlüüsil on püsiv vorm drop-in-fail administraatori valitud nimega, näiteks /etc/sysctl.d/60-vpn-forwarding.conf, mis sisaldab net.ipv4.ip_forward = 1. Kirjutage fail ja laadige seejärel just see fail, et muutuks ka reaalajas olek: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, millele järgneb tagasilugemine. Failinimi on näide, mitte reserveeritud VPN-tee, ja algne number loeb, sest hiljem sorteeritud failid võidavad.

Tähtsusjärjekord on koht, kus püsivus vaikselt katkeb. Kontrollige nii distributsiooni laadijat kui ka oma drop-in-faili, sest procps sysctl --system loeb lõpus ka /etc/sysctl.conf, samas kui systemdi sysctl.d järjekord on hoopis teine jada. Hilisem määramine võib sama võtme kohe tagasi panna, jättes teie faili õigeks ja tegeliku väärtuse valeks. Ärge kirjutage olemasolevat administraatorifaili üle, et see vaidlus võita; leidke omanik ja muutke seal.

Pärast alglaadimist loodud nimeruumi ei juhi üldse hosti drop-in-fail. Selle seadistus kuulub sellele, mis selle loob, olgu selleks konteineri käituskeskkond või nimeruumi loomise üksus. Konteinerile laiade hostiõiguste andmine küsimusest möödahiilimiseks on halvem tehing kui kümne minuti kulutamine õige omaniku tuvastamisele.

Tea, mida lüliti maksab, enne kui selle ümber lülitad

ip_forward ei ole kahjutu tõeväärtus. Kerneli dokumentatsioon märgib, et selle muutmine lähtestab mitme muu IPv4-parameetri hosti või ruuteri vaikeväärtustele, nii et diagnostiline ümberlülitamine võib ära visata mujal tehtud häälestuse ega maini seda kunagi. Käsitlege seda külgtoimetega konfiguratsioonimuudatusena, mitte sondina, mida võib hooletult käivitada.

See välistab ka selle välja- ja sisselülitamise iga kord, kui klient ei saa hostini jõuda. Kui väärtus on juba üks, on rike mujal teel, ja sama võtme kolmandat korda ümberkirjutamine ei liiguta seda.

Tõestage püsivus ja seejärel testige tee ülejäänut

Lugege väärtus tagasi neljal hetkel: vahetult pärast muudatust, pärast VPN-liidese ilmumist, pärast uuesti ühendamist ja pärast plaanilist taaskäivitust. Väärtus, mis mõnel neist hetkedest tagasi vajub, on teise omanikuga, ja veel üks ühekordne kirjutamine peidab seda ainult järgmise taaskäivituseni.

Lubatud edastamine jätab siiski kolm asja kontrollida. Klient vajab marsruuti sihtkohta, lüüs vajab edasist marsruuti pluss luba seda kasutada, ja sihtkoht vajab tagasiteed kliendi tunneli aadressile. Privaatne marsruuditud LAN ei vaja automaatselt NAT-i, seega ärge lisage masqueradingut enne, kui teate, milline kolmest puudub, ja testige ettenähtud kliendist, mitte lüüsist endast, sest lüüsil algatatud päring ei puuduta kunagi edastusteed, mille te just lubasite. IPv6-l on oma edastus- ja marsruutimispoliitika, seega töötav IPv4-test ei ütle selle kohta midagi.

Hoidke drop-in-faili tee, nimeruumi omanik ja tagasilugemiskäsk koos runbookis. Kes selle järgmisena üle võtab, peaks saama väärtust lugeda, näha, kellele see kuulub, ja minuti jooksul otsustada, kas probleem on püsivuses või tee ülejäänud osas.