Miks VPN-klient kontori kohtvõrgus kaotab iga vastuse

Sülearvuti istub Etherneti kaudu kontori /24 võrgus ja liitub ka OpenVPN-serveriga, mis elab samas /24 võrgus. Kolleeg pingib tunneli aadressi; päring saabub selgelt ja midagi ei lähe tagasi. Tunneli logi on puhas ja veebilehitsemine töötab endiselt, seega on tunnel vale kahtlusalune. IPv4 allika valideerimine vastuvõtvas masinas viskab paketi ära, enne kui miski seda loeb.

Äraviskamine toimub enne, kui miski paketti loeb

Allika valideerimine küsib iga sissetuleva paketi kohta ühe küsimuse: kui see host vastaks sellele allikale, kas vastus väljuks liidesest, millelt pakk just saabus? Kui vastus on ei, viskab tuum paketi saabumisel ära. Ei pistik ega edastustee näe seda kunagi, ja seepärast registreerib tunnelil tehtud püük ikkagi päringu, mida rakendus kunagi ei saa.

Klient hoiab siin tunnelil aadressi 10.66.0.9 ja OpenVPN-server vastab aadressil 192.168.80.10 kontori prefiksi sees. Kolleeg aadressil 192.168.80.25 pingib tunneli aadressi, seega päring läbib kohtvõrgu, server suunab selle tunnelisse ja see saabub kliendi tunneli liidesele, kandes kontori allikaaadressi. Selle masina marsruutimistabelis kuulub kontori prefiks Etherneti seadmele, mitte tunnelile. Valideerimine võrdleb saabumisliidest marsruudiga, leiab lahknevuse ja jätab paketi kõrvale, seega kolleeg näeb täielikku kadu, samal ajal kui mõlemad otsad teatavad tervest tunnelist.

Peegelsuunal on sama kuju: kui klient alustab kontori suunas, võidakse vastused kontori poolel samal põhjusel kõrvale jätta. Ainult ühes suunas kontrollitud parandus tuleb tavaliselt tagasi teise piletina.

Tõestage kehtiv režiim, enne kui puudutate ükskõik millist sysctl-i

Lugege tegelikke väärtusi, selle asemel et usaldada distributsiooni vaikeväärtust, sest liidesepõhine seade on ainult pool otsusest. Kehtiv režiim on suurem liidese väärtusest ja all väärtusest, seega null tunneli liidesel ei tähenda midagi seni, kuni all on üks. Range režiimi otsus on marsruutimisotsus, seega käivitage otsing, mille tuum käivitab, ja võrrelge selle vastust liidesega, millelt pakk tegelikult saabus.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Seejärel korrake pingi, jälgides vigade loendurit. Kasvav loendur päringu kõrval, mida püük juba näitab, on selle äraviskamise tunnus, mitte puuduva marsruudi oma. Lülitage seal olles sisse marsi pakettide logimine, et tuum nimetaks allika ja liidese, mille ta tagasi lükkas. Koos välistavad need selgitustena šifri, tulemüüri ja puuduva iroute.

Kirjutage lähtejoon üles enne, kui midagi muudate: mõlemad väärtused, seade, mille otsing valis, ja loendur, mida jälgisite. Just see kirje ütleb teile hiljem, kas muudatus tegi selle, mida te arvate.

Mida iga rp_filter režiim tegelikult vastu võtab

Tuum pakub liidese kohta kolm väärtust ja need ei ole ühe reegli kolm varjundit. Null lülitab kontrolli välja. Üks on range ja nõuab, et allikas marsruuditaks tagasi saabumisliidese kaudu. Kaks on lõtv ja nõuab ainult, et tabelis oleks mingi marsruut allikani, ükskõik kuhu see osutab.

Rida, mis siin loeb, on lõtv rida, ja see, mida see endiselt tagasi lükkab. Võltsitud allikas, mis on teie tabelis kõikjal marsruuditav, läheb läbi, samas kui allikas, millel pole üldse marsruuti, lükatakse endiselt tagasi. Sülearvutis on see kitsas järeleandmine; ruuteris, mis edastab teiste inimeste liiklust, on see lai. Režiim kuulub hostile, seega kannab sama number kahes kohas erinevat kaalu.

Millist rida see topoloogia vajab, tuleneb tabelist, mitte harjumusest. Pakk on seaduslik ja selle allikas on marsruuditav, seega lõtv võtab selle vastu ja range mitte. Miski selles juhtumis ei nõua nulli ja nulli valimine eemaldaks kontrolli, mis siin midagi ei maksa.

Valige väikseim muudatus, mis kaotab mitmetähenduslikkuse

Lõtv režiim on väikseim sobiv muudatus ja see on tõeline ranguse vähenemine, mitte kahjutu lüliti. Parem valik on olemas alati, kui topoloogia seda lubab: eemaldage kattuvus ja mitmetähenduslikkus kaob.

Kui kontori prefiksi on vaja ainult Etherneti kaudu, eemaldage see marsruutidest, mida profiil tõmbab, ja aadress muutub ühe tee kaudu kättesaadavaks. Kui mõlemad teed peavad tõesti kõrvuti eksisteerima, kinnitage allikas ja seade poliitikareegliga, selle asemel et igal liidesel valideerimist lõdvendada. See hoiab range filtreerimise kõige muu jaoks masinas ja dokumenteerib erandi seal, kust järgmine insener seda otsib.

Ükskõik millise tee valite, kirjutage see sysctl drop-in faili, mitte reaalajas käsku. Seadke võtmed all ja default koos, et taasühendus ei saaks vaikselt range režiimi taastada.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Mida lõtv režiim ära annab, ja kus

Lõtv režiim lükkab endiselt tagasi allika, kuhu ükski marsruut ei jõuaks, ja lõpetab võltsitud allika tagasilükkamise, mis juhtub olema marsruuditav. Sülearvutis on see kitsas järeleandmine. Seadmes, mis edastab liiklust, mis ei kuulu talle, on sama valik palju laiem. Seega kannab sama seade kahte väga erinevat tähendust sõltuvalt sellest, kus see töötab.

Kontrolli täielik väljalülitamine hostis, mis edastab liiklust teiste inimeste eest, on ainus parandus, mida tuleks vältida. Null viskab ära valideerimise, mida lõtv režiim hoolikalt hoiab. Kui host edastab teiste eest, argumenteerige selle asemel eelmise jaotise poliitikareegli valiku poolt.

Jätke märkus, mis nimetab kaks liidest, kattuvat prefiksit ja täpset proovi, mis nüüd õnnestub. See on järgmisele insenerile kasulikum kui rida, mis ütleb, et filtreerimist kohandati.