IPsec-politiko glutas vian lokan trafikon: kiel rimarki tion

La presilo sur la skribotablo ĉesas respondi en la momento, kiam la tunelo ekfunkcias, kaj nenio en la tunela agordo mencias la presilon. Kutime okazis, ke protektita gamo estis skribita sufiĉe larĝa por inkluzivi ĝin, do la maŝino nun provas ĉifri trafikon, kiu devus resti sur la loka segmento. Legi la instalitan politikon klarigas la kaptadon; mallarĝigi ĝin en la ĝusta loko tenas la malproksiman trafikon protektita. La vojaĝo de la malsukcesa peto al la kongrua politiko daŭras kelkajn minutojn.

Sekvu la fluon antaŭ ol ŝanĝi selektilon

Komencu ĉe la malsukcesa peto kaj notu kvar valorojn: la fontadreson, kiun uzas la maŝino, la ekzaktan celon, la itineron, kiun elektas la kerno, kaj la politikon, kiu kongruas kun tiu paro.

Tiuj kvar faktoj decidas, ĉu la kaptado estas intenca aŭ akcidenta. Celo, kiu falas en la malproksiman selektilon, estas protektata laŭ la dezajno, eĉ se la dezajno estis malĝusta. Celo ekster ĝi, kiu tamen estas kaptata, signifas, ke io alia kongruas, kaj ŝanĝi la selektilon ne helpos. Ambaŭ kazoj oftas, kaj unu komando distingas ilin.

Faru tion antaŭ ol redakti ion ajn, ĉar la interesa kazo estas la loka subreto, kiu interkovras privatan gamon, kiun la konekto protektas. Familiaraj prefiksoj kiel 192.168.0.0/16 aperas en multaj retoj, kaj selektilo skribita por unu el ili povas silente kovri vian.

Tri specoj de loka, kiuj kondutas malsame

Celo atribuita al ĉi tiu gastiganto, celo sur la sama ligo kaj celo malantaŭ alia interfaco estas tri malsamaj kazoj. La kerno traktas ĉiun malsame, kiam ĝi decidas, ĉu la trafiko bezonas protekton.

Ankaŭ trafiko generita de la enirejo mem ne samas al trafiko plusendita de kliento. Politiko, kiu ŝajnas ĝusta por plusendita trafiko, povas kapti la administran sesion de la enirejo mem, kaj tiel administranto perdas aliron dum li riparas la tunelon.

La utila kutimo estas nomi la kazon laŭte: ĉu ĉi tiu pako venas de mi, iras al mia ligo aŭ pasas tra mi? Ĉiu respondo montras al malsama loko por mallarĝigi. Skribi la kazon ankaŭ malhelpas la sekvan personon refari la saman laboron.

Kiam la protektita gamo estas tuta privata spaco, ĉiuj tri kazoj povas samtempe enfali en ĝin, kaj la simptomo fariĝas maŝino, kiu atingas nenion krom la tunela finpunkto.

Legu la instalitan politikon, ne la dosieron

Agordaj dosieroj priskribas la intencon; la kerno tenas la politikojn, kiuj efektive kongruas. Montru ambaŭ kaj traktu malkongruon kiel la unuan konstaton.

Ĉi tiuj komandoj montras la elektitan itineron por la celo kaj la instalitajn politikojn en ĉiu direkto:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

La itinero diras al vi, kiun interfacon la pako uzus. La politika listo diras al vi, ĉu poste aplikiĝas ŝablono al tiu pako, kaj la konekta listo montras, kiujn selektilojn la demono kredas esti instalinta. Se la celo aperas en malproksima selektilo, vi trovis la kaptadon sen diveni.

Mallarĝigu la selektilon aŭ preteriru la celon

Estas du subtenataj riparoj, kaj ili respondas al malsamaj demandoj. Mallarĝigi la selektilon diras, ke ĉi tiu konekto protektas nur pli malgrandan gamon, kio estas ĝusta, kiam la pli larĝa gamo estis eraro. Aldoni preteriron diras, ke ĉi tiu specifa celo neniam rajtas esti protektata, kio estas ĝusta, kiam la protektita gamo vere estas larĝa kaj unu celo estas la escepto.

Elektu la unuan, kiam vi povas, ĉar pli malgranda selektilo estas pli facila por pripensi kaj aperas en la konekta difino. Elektu la duan, kiam la larĝa gamo estas intenca kaj la escepto estas unu sola gastiganto aŭ subreto, kiun vi povas nomi.

Ambaŭ apartenas al la agordo, kiu posedas la konekton. Rultempa regulo aldonita permane malaperas ĉe la sekva rekonekto, kaj la paneo revenas en momento, kiam neniu plu memoras la provizoran solvon.

Esceptoj sekuraj kontraŭ reinstalo

Post la ŝanĝo, ripetu la saman senpovan peton kaj rigardu la samajn nombrilojn. La loka celo devus respondi, kaj la celata malproksima celo devus plu montri ĉifritan trafikon.

Ĉi tiuj du kontroloj konfirmas, ke la escepto pluvivis kaj la protekto ne:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Poste malkonektu kaj rekonektu la tunelon intence, kaj ripetu ambaŭ. Escepto, kiu funkcias antaŭ la rekonekto kaj malsukcesas poste, estis aplikita al la malĝusta tavolo, kaj tio estas la plej ofta maniero, kiel ĉi tiu problemo revenas.