VPN-itinero aŭ fajroŝirma regulo: kiu faligas la paketon?

Du sendependaj decidoj okazas al la sama paketo, kaj iu ajn el ili povas silente fini la peton. La itinera serĉo elektas interfacon kaj sekvan salteton, poste la paketa filtrilo decidas ĉu tiu kombino estas permesata. Tempolimo diras al vi, ke unu el la du rifuzis, ne kiu. Trapasu la etapojn laŭ ordo kaj la ripeto kutime ĉesas esti konjekto.

Du decidoj, unu paketo, du posedantoj

La itinera serĉo unue konsultas la politikajn regulojn, poste la tabelon al kiu ili montras, kaj elektas la plej specifan prefikson kongruan kun la celo. Kliento, kiu instalis tunelan itineron, posedas tiun decidon, kaj nenio en fajroŝirma regulo povas anstataŭigi ĝin. Kiam la serĉo montras al io neatendita, ĉiu posta etapo laboras sur la malĝusta paketo.

Filtrado estas aparta. Sur Linux-gastiganto la netfilter-hokoj dividas trafikon laŭ por kiu la paketo estas: eligo forlasas la maŝinon, enigo finiĝas sur ĝi, plusendo trapasas ĝin. Pordego, kiu akceptas VPN-klientojn kaj plusendas ilin al LAN, bezonas la plusendan vojon, kaj ĝuste tiu ĉeno estas lasata malplena de plej multaj defaŭltaj agordoj.

Fonta elekto apartenas al la sama decido, kaj tie kaŝiĝas la plej multaj miskongruoj. La kerno elektas fontan adreson de la elira interfaco krom se la itinero nomas unu, do filtrila regulo skribita por la LAN-subreto neniam kongruas kun paketo eliranta kun la tunela adreso.

Legu, kion la serĉo efektive elektis

Presu la decidon anstataŭ dedukti ĝin. La suba komando solvas la itineron, kiun la kerno uzus por tiu celo, inkluzive de la interfaco kaj la fonto, kiun ĝi elektus:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-klientoj ofte instalas politikajn regulojn ĉe prioritatoj sub la ĉefa tabelo, do pura ĉefa tabelo pruvas nenion per si mem. Komparu la regulajn prioritatojn kun la tabeloj, kiujn ili elektas, kaj kontrolu ĉu la tunela itinero postvivas rekonon anstataŭ esti aldonita permane unufoje.

Politikbazita IPsec aldonas trian kongruigan etapon, kiun itinrado ne kovras, kiel la plusendaj notoj de strongSwan priskribas por tunelaj kaj transportaj agordoj. La sekureca politiko elektas trafikon laŭ prefikso kaj protokolo, dum la itinero nur decidas kien irus neprotektita paketo. Subreto, kiu estas itinrigita sed havas neniun kongruan selektilon, aŭ restas neprotektita aŭ estas faligita, laŭ la agordo, kaj neniu el la rezultoj aspektas kiel fajroŝirma problemo. Presu la politikon kaj komparu ĝiajn selektilojn kun la prefiksoj, kiujn vi atendis, ke la tunelo portos.

Filtrado validas ĉe hoko, ne ĉe itinero

Regulo, kiu permesas la VPN-aŭskultanton, estas regulo pri trafiko adresita al la pordego mem. Ĝi diras nenion pri klientoj atingantaj gastigantojn malantaŭ tiu pordego, ĉar plusendita trafiko trapasas alian ĉenon. Legi la regulan aron kiel unu ebenan liston estas la kutima kialo, ke ŝajne ĝusta regulo neniam ekagas.

Nombriloj rapide solvas la demandon. Regulo kun nula paka nombro neniam estis atingita, kio montras al la malĝusta ĉeno, la malĝusta interfaco aŭ pli frua faligo. Regulo kun kreskanta nombro sub faliga politiko estas la limo, kiun vi serĉis, kaj la paketo estas forĵetata anstataŭ misitinrigita.

Sendu sondilon tra la vojo, kiun uzas la kliento

Testoj faritaj sur la pordego mem vojaĝas tra eligo kaj enigo, kun la propra fonta adreso de la pordego. Tio estas malsama vojo ol plusendita peto de kliento, do sukcesa loka curl pruvas malpli ol ĝi aspektas. Testu de la maŝino, kiu malsukcesas, aŭ fiksu la interfacon kaj fonton eksplicite.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Kapto ĉe ambaŭ finoj apartigas la ceterajn kazojn. SYN, kiu forlasas la klienton kaj neniam alvenas, signifas itinradon, ĉifradon aŭ supran alirliston. SYN, kiu alvenas kaj ne ricevas respondon, signifas la servon aŭ ĝian gastigan filtrilon, kaj la tunelo neniam estis la problemo.

Revena trafiko meritas propran rigardon. Nesimetria itinrado plus inversvoja filtrado faligas respondojn alvenantajn sur la malĝusta interfaco, kio montriĝas kiel unudirekta konekto anstataŭ blokita pordo. Kontrolu la sysctl-valoron antaŭ ol kulpi la fajroŝirmon pri simptomo, kiun ĝi ne kaŭzis.

Protokolado funkcias kiel dua opinio, ne unua paŝo. Provizora protokola deklaro sur la plusenda ĉeno nomas la interfacon kaj la adresojn, kiuj trafis ĝin, kaj ĝi estas facile forigebla poste. Lasu ĝin konstante kaj vi konstruis protokolan volumenan problemon anstataŭ respondon.

Metu ĉiun ŝanĝon tie, kie ĝi postvivas rekonon

Itinero aldonita per ip route add vivas ĝis la interfaco falos. Konservu ĝin en la konekta profilo: NetworkManager akceptas kromajn itinerojn sur la konekto, kaj netplan tenas ilin inter lanĉoj. La sama regulo validas por fajroŝirma escepto ĉe la klienta flanko, kiu malaperos post la sekva reŝargo.

Reguloj ĉe la servila flanko apartenas al la agorda dosiero, kiun la servo ŝargas ĉe starto, ne al interaga seanco, kiu finiĝas kiam vi fermas ĝin. Skribu la regulon, reŝargu, kaj konfirmu ke la nombrilo moviĝis, ĉar reŝargo, kiu malakceptis la sintakson, silente lasas la malnovan regulan aron surloke.

Poste ripetu la originan aplikaĵan peton de komenco ĝis fino kaj notu, kiu tavolo ŝanĝiĝis. Itinera ripeto, kiu ankaŭ bezonis filtrilan ŝanĝon, ankoraŭ malsukcesos, kaj la dua malsukceso legeblas multe pli facile post kiam vi scias, ke la unua foriris. Notu la daton kaj la klientan version apud la rezulto, ĉar defaŭltoj de itinrado kaj filtrado ambaŭ moviĝas inter eldonoj. Tenu tiun noton en la bileto, por ke la sekva persono komencu tie, kie vi haltis, anstataŭ ripeti la duetapan migradon.