Miért hagyják ki az OpenVPN-kliensek az átjáró IPsec-szelektorait

Pingelje az átjáróról a távoli IPsec-alagút mögötti gazdagépet, és az tisztán válaszol, így az alagút egészségesnek látszik, a jegy pedig továbbhalad. Ezután egy csatlakozott kliens ugyanazt a gazdagépet próbálja, és semmit nem kap vissza. Az a ping soha nem bizonyította a kliens folyamatát, mert az átjáró saját forráscímével indult, és egy másik IPsec-szelektorral egyezett. Annak megértése, miért tér el a két eset, a javítás nagy része.

Az átjáró pingje olyan folyamatot vizsgál, amelyet a kliens soha nem használ

A forráscím dönti el, melyik házirend érvényes. Az átjárón létrejött csomag a helyi LAN vagy az alagút végpontjának címével lép ki, és a hozzá illő házirendet pontosan erre az esetre írták. A kliens csomagja a klienspool címével érkezik az OpenVPN-interfészre, ami teljesen más szelektor.

Ezért tűnik a hiba útválasztási problémának, holott valójában a házirend hatókörének problémája. Az átjáróról való elérhetőség bizonyítja, hogy a partner fut, és a javaslatokat megtárgyalták, és semmit nem bizonyít arról, hogy a pool védett-e.

Tolja be a távoli előtagot, amelyre az alkalmazásnak valóban szüksége van

Vegye a szemléltető párt: 10.8.0.0/24 a csatlakozott kliensekhez és 172.30.239.0/25 a védett távoli hálózathoz. A kliensnek a második előtaghoz kell útvonal, nem az átjáró LAN-jához és nem valamely más alagútcímhez. A poolba betolt útvonal az, ami egyáltalán ráveszi a klienst, hogy átadja ezt a forgalmat az átjárónak. Nélküle a csomag soha nem éri el a házirend-döntést, amelyet hibakeres.

Egy Community-kiszolgálón, amely elfogadja a betolt útvonalakat, a direktíva a valódi maszkot veszi fel: push "route 172.30.239.0 255.255.255.128". Az Access Server ugyanezt a célt a telepített verzió priváthálózat- vagy hozzáférésiszabály-beállításaival konfigurálja, az útválasztott vagy lefordított módot szándékosan megválasztva. A generált tűzfal-láncok szerkesztése a tulajdonos konfiguráció helyett az az út, amelyen egy működő telepítés reprodukálhatatlanná válik.

Csatlakozás után a kliens útválasztási táblázatát olvassa, ne a kiszolgáló szándékát. A csak a poolt lefedő útvonal azt jelenti, hogy a betolás soha nem érkezett meg, az alagúton át vezető alapértelmezett útvonal pedig szélesebb ennél a követelménynél, és később meglepi. Ellenőrizze a maszkot és az előtagot is, mert a /25-ként betolt /24 a szomszédos címek forgalmát olyan útra küldi, amely nem tudja elvinni. Ezután erősítse meg, hogy a kliens az alagút-interfészt választotta ehhez a célhoz.

A szelektorok tartalmazzák a klienspoolt

Az ügyfélcímeket megőrző útválasztott hozzáféréshez az IPsec-házirendnek védenie kell a pool és a távoli előtag közötti forgalmat. Az átjáró saját LAN-jára írt szelektorok beengedik a pinget és eldobják a kliens kérését, és pontosan ez az az aszimmetria, amely ezt a vizsgálatot elindította.

Vizsgálja meg a megtárgyalt házirendet és a beállított javaslatokat is, például az ipsec statusall paranccsal strongSwanon vagy a megvalósításának megfelelő állapotparanccsal. Házirendalapú IPsec esetén a szokásos útvonal fizikai interfészre mutathat, miközben az egyező forgalom továbbra is titkosított, tehát a hiányzó alagúteszköz semmit nem bizonyít. Hasonlítsa össze a szelektorpárokat a feljegyzett pool-lal és előtaggal.

Az átjárón lévő általános forrás-NAT is elronthatja az egyezést. Ha egy masquerade-szabály a házirend-ellenőrzés előtt átírja a kliens forrását, a csomag már nem úgy néz ki, mint az Ön által írt szelektor. Ez az egyik oka, hogy a széles masquerade-szabály rossz megoldás egy második VPN-hez: megváltoztatja, melyik házirend érvényes, és melyik címet naplózza a távoli oldal. Vegye ki a forgalmat, amelyet útvonalazni szándékozik, vagy fordítsa le szándékosan, és frissítse a szelektorokat.

Szándékosan válasszon útválasztást vagy fordítást

Az útválasztás láthatóvá teszi a kliens címét a távoli oldal számára, így a távoli naplók és a forrásonkénti szabályok értelmesek maradnak, és megköveteli, hogy a távoli átjáró ismerje a poolhoz vezető visszautat. A fordítás egyetlen cím mögé rejti a poolt, ami megszünteti a visszaútvonal problémáját, és megsemmisíti az egyes kliensek identitását.

Válasszon egy tervet, és írja le, mert a kettőhöz más szelektorok és más tűzfal-sorrend kell. A félig alkalmazott masquerade a kettő között landol, és egyiket sem elégíti ki. A leírt döntés az is, ami a következő mérnöknek lehetővé teszi, hogy megkülönböztessen egy hibát egy szándékos döntéstől.

Zárja a hurkot a továbbításon és a válaszon

Az átjárónak továbbítania kell a szándékolt protokollt és célt, ami engedélyezett IP-továbbítást és a párt engedélyező továbbítási láncot jelent. Ezután a távoli oldalnak vissza kell küldenie a válaszokat az IPsec-úton, és ez az ő átjárójukon hozott útválasztási döntés, nem a magáén. Mindkét fél közönséges konfiguráció, és mindkettő könnyen félkész marad. Külön tesztelje őket, hogy egy hiányzó továbbítási szabályt ne nézzenek törött alagútnak.

Ellenőrizze egyetlen valódi kliens–alkalmazás kéréssel, figyelve, ahogy áthalad az OpenVPN-interfészen, az IPsec-döntésen és a távoli gazdagépen. A választ külön megfigyelésként vizsgálja, mert egy megérkező kérés és egy soha vissza nem térő válasz ugyanúgy néz ki a kliens helyéről. Egy nyomon követett kérés többet ér, mint bármennyi ping az átjáróról.

A tesztelés alatt tartsa szűken a cél engedélyezését, és erősítse meg, hogy a szabály nélküli kliens nem érheti el a szolgáltatást. A telepített útvonal és a létrejött asszociáció nem ugyanaz, mint a megadott hozzáférés.