Ki válaszol valójában a VPN dedikált címén?

Egy kihasználatlanul fekvő cím a szervezet kiosztásában nem figyelő, és a tűzfalhoz adása nem hoz létre egyet sem. Valaminek le kell zárnia az IKE-t ezen a címen, és a mechanizmus attól függ, hogy az átjáró birtokolja-e a címet, vagy egy felsőbb eszköz fordítja-e. A csomagút az, ami a kettőt megkülönbözteti, és ez dönti el, melyik platformfunkcióra van szüksége, mielőtt bárki változási kérelmet nyitna. Először modellezze az utat, aztán válasszon.

A cím mögötti csomagút

A partner IKE-t küld a kapott címre, UDP 500-on, vagy UDP 4500-on, amikor a NAT-átjárás szerepet kap. Bármely eszköz, amely ezt a címet tartja az úton, vagy helyben fogadja és megválaszolja a datagramot, vagy továbbküldi máshová. Csak ez a két lehetőség van, és ebben a cikkben minden más abból következik, hogy melyik igaz.

A helyi fogadás azt jelenti, hogy azon az eszközön van egy ehhez a címhez kötött socket. A továbbküldés azt jelenti, hogy a datagramot átírják és továbbítják egy másik végponthoz, amelynél akkor a socket van. Az UDP 500-at engedélyező tűzfalszabály semmit nem mond arról, hogy a kettő közül melyik történik.

Írja le a rekordot, mielőtt bármihez hozzányúlna: a címet, amelyet a partnerek elérnek, hogyan kézbesíti a felsőbb hálózat, a helyi interfészt vagy logikai végpontot, amely fogadja, és azt a folyamatot, amely az IKE-re válaszol. Négy sor, és mindegyik ellenőrizhető. Ha valamelyik ismeretlen, az az ismeretlen a tervezési munka, nem pedig később rendezendő megvalósítási részlet. A változási kérelem jóváhagyása utáni kitöltésük az, ahogy egy fordítási szabály a rossz eszközre kerül.

A modell: az átjáró birtokolja a címet

Az első modellben maga az átjáró tartja a címet, akár másodlagos címként egy meglévő interfészen, akár címként egy dedikált interfészen, akár olyan loopbackként, amelyet a platform alagút-végpontként támogat. Ezek három különböző funkció három különböző konfigurációs úttal, és egy platform, amely az egyiket támogatja, lehet, hogy a többit nem.

Erősítse meg, hogy a platform és a kiadás pontosan ezt az elrendezést támogatja, mielőtt köré tervez. Egy útvonalazott blokk, egy további cím egy interfészen és egy loopback-végpont nem cserélhető fel, és egy kiadás dokumentációja nem ígéri, hogy a következő ugyanígy viselkedik.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

A figyelő socket a bizonyíték. Ha semmi nincs a címhez kötve, az átjáró nem a lezáró, függetlenül attól, mit mond az útválasztási tábla, és a csomagrögzítés megmutatja, hogy a datagramok megérkeznek, de semmi nem válaszol rájuk.

Ne tegyen egy második interfészt olyan alhálózatba, amely már létezik máshol a topológiában, és ne feltételezze, hogy a platform megoldja. Az átfedő interfész-alhálózatok kétértelmű forrásválasztást okoznak, és sok platformon a konfigurálás teljes megtagadását.

B modell: egy felsőbb eszköz fordítja le

A második modellben egy felsőbb tűzfal birtokolja a dedikált címet, és a forgalmat egy másik VPN-átjáróhoz továbbítja. Ez visszaúttal járó célfordítás, és teljesen érvényes tervezés mindaddig, amíg ilyenként dokumentálják.

Ami viszont nem, az annak bizonyítéka, hogy a felsőbb eszköz helyi VPN-socketet szerzett. A fordítás csomagokat továbbít; nem teszi a felső dobozt IKE-válaszolóvá. Ha a felsőbb szabályt eltávolítják, vagy visszaútja megszakad, a VPN leáll, pedig az átjáró egészséges és a saját figyelői épek.

Rögzítse mindkét címet: amelyet a partnerek elérnek, és amelyet az átjáró valóban lát. Aztán rögzítse a szállítást és a visszautat, mert az UDP 500-hoz működő, de a beágyazott ESP-hez nem működő fordítás kapcsolódik, majd nem tud forgalmat vinni, ami zavaró hiba a későbbi hibakereséshez.

Az identitás nem a külső cím

Az IPsec elválasztja az alagút végpontját a forgalomtól, amelyet véd, és az architektúra ezeket a döntéseket különböző helyeken tartja. A partnerek által elért cím megváltoztatása nem változtatja meg automatikusan, mely belső prefixek engedélyezettek, mely útvonalak települnek, vagy mely erőforrásokat érhet el a munkamenet.

Az authentikált identitás ismét különálló. Az IKEv2 identitásterhet és hitelesítéscserét hordoz, amelyeknek nem kell megfelelniük a külső csomagcímnek, és éppen ezért tud egy lefordított tervezés továbbra is helyesen hitelesíteni.

Ez a függetlenség hasznos és egyben csapda. Két DNS-név, amely egy közönséges figyelőre oldódik fel, nem választ különböző VPN-háttérrendszereket, és az egy identitást megnevező tanúsítvány nem fog kielégíteni egy másikat váró partnert. Erősítse meg, mit validál a partner, mielőtt feltételezné, hogy ezt egyedül a cím dönti el.

Fogadja el a tervezést egyetlen kapcsolat megfigyelésével

Vizsgálja meg, hová kézbesítik valójában az új engedélyezett kapcsolatot, melyik identitás válaszol, és melyik privát folyam engedélyezett utána. Három megfigyelés, három különböző réteg, és a cím sikeres nyilvános lekérdezése egyiket sem teszteli.

Tartsa meg a negatív esetet is: egy partnert, amelyet nem szabadna elfogadni, vagy egy belső prefixet, amelyet nem szabadna elérni, a változás után ellenőrizve. A kezdetben írt rekord az, ami ezt a tesztet lehetővé teszi anélkül, hogy a tervezést emlékezetből újra kellene építeni.

Mindezenek a célja, hogy a hálózat tulajdonosa támogatott kiosztási módszert választhasson, ahelyett hogy egy általános állításra hagyatkozna arról, mit tehet minden tűzfal egy további címmel. Pont ez az állítás az, ahol ezek a tervezések elromlanak, mert minden platformon hihetőnek hangzik, és általában egyiken sem igaz. A négy soros rekord ezt eldönti az Ön platformjára tíz perc alatt.