VPN-kliens forgalma és tűzfalállapot: külső és belső folyam

A VPN-kézfogás befejeződik, a kliens címet kap, és az átjáró mögötti szolgáltatás mégis elutasítja a kapcsolatot. A tűzfal gyakran pontosan azt teszi, amit mondtak neki. Engedélyezte a külső alagútfolyamot, amely más csomag, mint a dekapszulált alkalmazáskapcsolat. Ebből két döntés következik: melyik folyamot engedélyezi, és hogy a határ egyáltalán követi-e az állapotot.

Amíg nem választja szét a kettőt, minden szabálymódosítás találgatás.

A tűzfal két különböző csomagot lát

A dekapszuláció előtt a tűzfal a VPN-végpontra címzett forgalmat lát: külső UDP-folyamot a fogadó felé. A dekapszuláció után egy továbbított csomag a kliens belső címét és a szolgáltatás célját hordozza.

A külső folyam engedélye nem jogosítja fel a továbbított TCP-kapcsolatot. Ezeket különböző láncokban, különböző interfészekkel szemben és a fordítás után különböző címekkel lehet kiértékelni.

Hasonlítsa össze a két oldal egyenértékű pozícióiból származó rögzítéseket. Az alagút szélén készült rögzítés és a szerveren készült rögzítés különböző tuple-öket mutat ugyanahhoz a munkamenethez.

Első döntés: az alagút vagy a szolgáltatás engedélyezése

Ha a kliensnek csak a VPN-végpontra van szüksége, a külső engedély elég lehet. Ha az átjárón túli szolgáltatásra van szüksége, továbbítási engedély kell ahhoz a célhoz és porthoz. Az olyan alagútszabály, amely a szolgáltatást is engedélyezi, olyan tervezési döntés, amelyet meg kell neveznie, nem véletlen.

Tartsa szűken a kliens tartományát és a szolgáltatás hatókörét. Az alagút alhálózatától a teljes helyi hálózatig adott engedély az a döntés, hogy minden gazdagépben megbízik, nem pedig egyetlen alkalmazás rövidítése.

Írja le a két szabályt külön. Az alagútszabály és a szolgáltatásszabály különböző módon hibázik, és különböző bizonyítékokkal hibakereshető. Ha az egyik hibázik, tudja, melyik réteget vizsgálja először.

Második döntés: állapottal vagy állapot nélkül minden határon

Egy létesített folyamra vonatkozó szabály beengedheti a válaszokat egy engedélyezett cseréhez, de viselkedése a terméktől függ. A felhő biztonsági csoport általában követi az állapotot; az alhálózati hozzáférési lista gyakran nem követi, és mindkét irányban kifejezett kezelést igényel. Ne feltételezze, hogy az útvonal minden határa ugyanúgy kezeli az állapotot. Sorolja fel az egyes határokat, és jelölje meg állapotkövetőként vagy állapot nélküliként, mielőtt a szabályokat megtervezi.

Ha egy szabály megváltozik, a meglévő követett folyamok tovább működhetnek, miközben az újak meghiúsulnak, vagy fordítva. Ez a különbség hasznos nyom, nem ok arra, hogy egy élő átjárón minden kapcsolatállapotot kiürítsen.

Teszteljen friss, ellenőrzött kéréssel, és vizsgálja meg a vonatkozó számlálókat. A tiszta teszt jobb, mint a zavaró visszaállítás. Jegyezze fel a számláló nevét a változási rekordba, hogy a következő teszt ugyanazt a bizonyítékot használja.

Ellenőrizze a visszaút ugyanazon irányelv mellett

Küldjön új kérést a klienstől a szolgáltatás felé, majd ellenőrizze az előre- és visszaszámlálókat minden határon. Erősítse meg, hogy a válasz a várt útvonalat használja, különösen ha fordítás is szerepel.

Tartsa szűken a tervezett kliens tartományát és a szolgáltatás hatókörét, és ellenőrizze a visszaút ugyanazon szabálykészlet mellett, amely a kérést engedélyezte. Az a szabály, amely csak azért működik, mert egy régi folyam még nyitva van, nem működő szabály.