VPN de loko al loko: kiun direkton vere bezonas regulo?

Ambaŭ finoj raportas establotan tunelon, la fora filio respondas de la enirejo, kaj la aplikaĵo ankoraŭ tempolimas por uzantoj ĉe unu flanko. La kutima konsilo diras aldoni fajroŝirmilan regulon en ambaŭ direktojn. Kelkfoje tio pravas, kelkfoje ĝi duobligas regulon, kiu jam ekzistas, kaj kelkfoje la dua regulo estas tiu, kiu rompas la staton. Kiu kazo validas dependas de tio, kie la fajroŝirmilo vidas la paketon.

Stata revena trafiko ŝanĝas la nombron

Stata fajroŝirmilo registras la peton kaj permesas la respondon sen dua regulo, do dizajno, kiu bezonas nur unu regulon, estas normala. Senstata alirlisto ne havas tian memoron, kaj la respondo devas esti eksplicite permesita. Ambaŭ pravas sur sia propra platformo, kaj tial la konsiloj kontraŭdiras.

Legu la plusendan dokumentaron por la platformo antaŭ vi, kaj kontrolu, ĉu la politiko, kiun vi redaktas, estas stata tie, kie ĝi vidas la paketon. Eksplicita malpermeso por establita trafiko, aŭ regula ordo, kiu taksas la respondon antaŭ la stata tabelo, transformas funkcian dizajnon en enigman. La nombro da reguloj estas efektiviga detalo, dum la postulo estas, ke ambaŭ direktoj de permesita konversacio povu finiĝi.

Kie la fajroŝirmilo vidas malĉifritajn paketojn

En politika tunelo, la fajroŝirmilo povas taksi la ĉifritan paketon antaŭ malĉifrado kaj la malĉifritan paketon poste, sur malsamaj interfacoj. Regulo skribita por la malĝusta estas ĉeestanta, ĝusta kaj neniam kongruas. Tiel regularo kopiita el funkcianta deplojo povas malsukcesi sur identa aparataro.

Itinero-bazita IPsec kaj la plej multaj modernaj efektivigoj prezentas tunelan interfacon, do la malĉifrita paketo alvenas tien kaj ordinaraj interfacaj reguloj validas. Konfirmu, kiun modelon la deplojo uzas antaŭ ol kopii regularon el gvidilo skribita por la alia. La tunela interfaco ankaŭ estas la loko por rigardi, kiam vi bezonas scii, ĉu paketo entute estis malĉifrita.

Malsimetria itineraĵo rompas la supozon

Stata fajroŝirmilo supozas, ke ĝi vidas ambaŭ duonojn de la konversacio. Se la respondo revenas per alia enirejo, tiu aparato tenas neniun staton por la peto kaj forĵetas ĝin laŭ sia propra politiko. La simptomo estas unudirekta fiasko, kiun neniu regulo ĉe la senda flanko povas ripari. Spuru la respondon antaŭ ol redakti ion ajn.

Kontrolu la respondon itineron antaŭ ol aldoni larĝan permesan regulon ĉe ambaŭ flankoj. Toleri ĉion sur ĉiu interfaco kaŝas la itineran eraron kaj samtempe larĝigas aliron, kio estas la plej malbona havebla kombinaĵo.

Kontrolu ambaŭ direktojn per realaj fontadresoj

Testu per la adreso, kiun la fora flanko efektive vidas, ĉar tradukado povas igi fontan regulon kongrui kun nenio. Rulu la kaptadon sur ambaŭ enirejoj samtempe.

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

Peto, kiu aperas sur la fora enirejo kun neattendita fontadreso, klarigas regulon, kiu neniam kongruas, kaj respondo alvenanta sur la malĝusta interfaco klarigas statan malkongruon. Poste testu unu celon ene de la aprobita amplekso kaj unu ekster ĝi, por ke la limo estu montrata anstataŭ supozata.

Notu la fontadreson post tradukado, la interfacon, kiun uzis la malĉifrita paketo, kaj la regulon, kiu kongruis. Tiuj tri faktoj respondas la sekvan kazon sen ripeti la tutan esploradon.