VPN no vietas uz vietu: kuram virzienam tiešām vajag noteikumu?

Abi gali ziņo par izveidotu tuneli, attālā filiāle atbild no vārtejas, un lietotne tomēr pārsniedz laiku lietotājiem vienā pusē. Parastais padoms ir pievienot ugunsmūra noteikumu abos virzienos. Dažkārt tas ir pareizi, dažkārt tas dublē jau esošu noteikumu, un dažkārt tieši otrais noteikums salauž stāvokli. Kurš gadījums attiecas, ir atkarīgs no tā, kur ugunsmūris redz paketi.

Stāvokļa atgriešanās trafiks maina skaitu

Stāvokļa ugunsmūris reģistrē pieprasījumu un ielaiž atbildi bez otra noteikuma, tāpēc dizains, kuram vajag tikai vienu noteikumu, ir normāls. Stāvokļa neesošajam piekļuves sarakstam šādas atmiņas nav, un atbildei jābūt skaidri atļautai. Abi ir pareizi savā platformā, tāpēc padomi ir pretrunīgi.

Izlasiet priekšā esošās platformas pārsūtīšanas dokumentāciju un pārbaudiet, vai rediģētā politika ir ar stāvokli tur, kur tā redz paketi. Skaidrs aizliegums izveidotajam trafikam vai noteikumu secība, kas novērtē atbildi pirms stāvokļa tabulas, pārvērš strādājošu dizainu mīklainā. Noteikumu skaits ir ieviešanas detaļa, bet prasība ir, lai abi atļautās sarunas virzieni varētu pabeigties.

Kur ugunsmūris redz atšifrētas paketes

Politikā balstītā tunelī ugunsmūris var novērtēt šifrēto paketi pirms atšifrēšanas un atšifrēto paketi pēc tam, dažādos interfeisos. Noteikums, kas rakstīts nepareizajam interfeisam, ir klātesošs, pareizs un nekad nesakrīt. Tā no strādājošas ieviešanas nokopēts noteikumu kopums var neizdoties identiskā aparatūrā.

Maršrutā balstīts IPsec un lielākā daļa mūsdienu ieviešanu nodrošina tuneļa interfeisu, tāpēc atšifrētā pakete nonāk tur un tiek piemēroti parastie interfeisa noteikumi. Apstipriniet, kuru modeli izmanto ieviešana, pirms kopējat noteikumu kopumu no rokasgrāmatas, kas rakstīta otram. Tuneļa interfeiss ir arī vieta, kur skatīties, kad jāzina, vai pakete vispār tika atšifrēta.

Asimetriskā maršrutēšana salauž pieņēmumu

Stāvokļa ugunsmūris pieņem, ka redz abas sarunas puses. Ja atbilde atgriežas pa citu vārteju, šai ierīcei nav pieprasījuma stāvokļa, un tā to nomet saskaņā ar savu politiku. Simptoms ir vienvirziena kļūme, ko neviens noteikums sūtītāja pusē nevar salabot. Izsekojiet atbildes ceļam pirms kaut ko rediģējat.

Pārbaudiet atbildes maršrutu pirms plaša atļaušanas noteikuma pievienošanas abās pusēs. Visu tolerēšana katrā interfeisā slēpj maršrutēšanas kļūdu un vienlaikus paplašina piekļuvi, un tas ir sliktākā pieejamā kombinācija.

Pārbaudiet abus virzienus ar īstām avota adresēm

Pārbaudiet ar adresi, ko attālā puse patiešām redz, jo tulkošana var panākt, ka avota noteikums nesakrīt ar neko. Palaidiet uztveršanu abās vārtejās vienlaikus.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Pieprasījums, kas attālajā vārtejā parādās ar negaidītu avota adresi, izskaidro noteikumu, kas nekad nesakrīt, un atbilde, kas ierodas nepareizajā interfeisā, izskaidro stāvokļa neatbilstību. Pēc tam pārbaudiet vienu galamērķi apstiprinātajā apjomā un vienu ārpus tā, lai robeža tiktu parādīta, nevis pieņemta.

Pierakstiet avota adresi pēc tulkošanas, interfeisu, ko izmantoja atšifrētā pakete, un noteikumu, kas sakrita. Šie trīs fakti atbild uz nākamo biļeti, neatkārtojot visu izmeklēšanu.