Miért veszít el minden választ egy VPN-kliens az irodai LAN-on

Egy laptop Etherneten az iroda /24 hálózatán ül, és csatlakozik egy OpenVPN-kiszolgálóhoz is, amely ugyanabban a /24-ben él. Egy kolléga pingel az alagút címére; a kérés világosan megérkezik, és semmi nem megy vissza. Az alagút naplója tiszta, a böngészés még működik, tehát az alagút a rossz gyanúsított. Az IPv4-forrásérvényesítés a fogadó gépen eldobja a csomagot, mielőtt bármi elolvasná.

A dobás azelőtt történik, hogy bármi elolvasná a csomagot

A forrásérvényesítés egyetlen kérdést tesz fel minden beérkező csomagról: ha ez a gazdagép válaszolna arra a forrásra, a válasz azon az interfészen menne ki, amelyen a csomag épp megérkezett? Ha a válasz nem, a kernel megérkezéskor eldobja a csomagot. Sem csatlakozó, sem továbbítási útvonal nem látja soha, ezért az alagúton készült felvétel még mindig rögzít egy kérést, amelyet az alkalmazás soha nem kap meg.

A kliens itt 10.66.0.9-et tart az alagútján, és az OpenVPN-kiszolgáló 192.168.80.10-ről válaszol az irodai előtag belsejében. Egy kolléga 192.168.80.25-ről pingel az alagút címére, így a kérés átkel a LAN-on, a kiszolgáló az alagútba irányítja, és az irodai forráscímet hordozva megérkezik a kliens alagút-interfészére. Annak a gépnek az útvonaltáblájában az irodai előtag az Ethernet-eszközhöz tartozik, nem az alagúthoz. Az érvényesítés összeveti a megérkezési interfészt az útvonallal, eltérést talál és eldobja a csomagot, így a kolléga teljes veszteséget lát, miközben mindkét vég egészséges alagutat jelent.

A tüköriránynak ugyanaz a formája: amikor a kliens az iroda felé kezdeményez, a válaszok az iroda oldalán ugyanezen okból dobhatók el. A csak egy irányban ellenőrzött javítás általában második hibajegyként tér vissza.

Bizonyítsa a hatályos módot, mielőtt bármely sysctl-hez nyúl

Olvassa ki a tényleges értékeket a disztribúció alapértelmezése helyett, mert az interfészenkénti beállítás csak a döntés fele. A hatályos mód az interfész értéke és az all értéke közül a nagyobb, ezért a nulla az alagút-interfészen semmit nem jelent, amíg az all egy. A szigorú mód döntése útvonal-döntés, ezért futtassa azt a keresést, amelyet a kernel futtat, és hasonlítsa össze a válaszát azzal az interfésszel, amelyen a csomag valóban megérkezett.

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

Ezután ismételje meg a pinget, figyelve a hibaszámlálót. A felvétel által már mutatott kérés mellett emelkedő számláló ennek a dobásnak az aláírása, nem egy hiányzó útvonalé. Kapcsolja be a marsi csomagok naplózását, amíg ott van, hogy a kernel megnevezze az elutasított forrást és interfészt. Együtt kizárják a titkosítást, a tűzfalat és a hiányzó iroute-ot mint magyarázatot.

Írja fel az alapállapotot, mielőtt bármit változtat: mindkét értéket, a keresés által választott eszközt és a figyelt számlálót. Ez a feljegyzés mondja meg később, hogy a változtatás azt tette-e, amit gondol.

Mit fogad el valójában az egyes rp_filter módok

A kernel interfészenként három értéket mutat, és ezek nem egy szabály három árnyalatai. A nulla kikapcsolja az ellenőrzést. Az egy szigorú, és megköveteli, hogy a forrás a megérkezési interfészen keresztül visszairányuljon. A kettő laza, és csak azt kéri, hogy létezzen valamilyen útvonal a forráshoz a táblában, bárhová is mutat.

Az itt számító sor a laza, és az, amit továbbra is elutasít. Egy hamisított forrás, amely a táblájában bárhol irányítható, átmegy, míg a semmilyen útvonallal nem rendelkező forrás továbbra is elutasításra kerül. Laptopon ez szűk engedmény; olyan routeren, amely mások forgalmát továbbítja, széles. A mód a gazdagéphez tartozik, ezért ugyanaz a szám két helyen eltérő súlyt hordoz.

Hogy melyik sorra van szüksége ennek a topológiának, a táblából következik, nem a szokásból. A csomag legitim, a forrása irányítható, ezért a laza elfogadja, a szigorú nem. Semmi nem kíván nullát ebben az esetben, és a nulla választása eltávolítana egy ellenőrzést, amely itt semmibe nem kerül.

Válassza a legkisebb változtatást, amely megszünteti a kétértelműséget

A laza mód a legkisebb odaillő változtatás, és valódi szigorúságcsökkenés, nem ártalmatlan kapcsoló. Jobb lehetőség mindig van, amikor a topológia engedi: szüntesse meg az átfedést, és a kétértelműség eltűnik.

Ahol az irodai előtagra csak Etherneten át van szükség, vegye ki azokból az útvonalakból, amelyeket a profil húz, és a cím egyetlen úton elérhetővé válik. Amikor a két útnak valóban együtt kell léteznie, rögzítse a forrást és az eszközt egy házirend-szabállyal, ahelyett hogy minden interfészen lazítaná az érvényesítést. Ez megtartja a szigorú szűrést a gép minden mására, és dokumentálja a kivételt ott, ahol a következő mérnök keresni fogja.

Bármelyik utat választja, jegyezze fel egy sysctl drop-in fájlba, ne élő parancsba. Állítsa be az all és a default kulcsot együtt, hogy egy újracsatlakozás ne állíthassa vissza csendben a szigorú módot.

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

Miről mond le a laza mód, és hol

A laza mód továbbra is elutasítja azt a forrást, amelyet semmilyen útvonal nem érne el, és felhagy egy véletlenül irányítható hamisított forrás elutasításával. Laptopon ez szűk engedmény. Egy olyan eszközön, amely nem a saját forgalmát továbbítja, ugyanez a választás sokkal szélesebb. Ugyanaz a beállítás ezért két nagyon különböző jelentést hordoz attól függően, hol fut.

Az ellenőrzés teljes kikapcsolása olyan gazdagépen, amely mások forgalmát továbbítja, az az egyetlen javítás, amelyet el kell kerülni. A nulla eldobja azt az érvényesítést, amelyet a laza mód gondosan megőriz. Ha a gazdagép mások helyett továbbít, érveljen inkább az előző szakasz házirend-szabály lehetősége mellett.

Hagyjon megjegyzést, amely megnevezi a két interfészt, az átfedő előtagot és azt a pontos próbát, amely most sikerül. Ez hasznosabb a következő mérnöknek, mint egy sor arról, hogy a szűrést módosították.