Enkursiga tabelo kontraŭ reala serĉo: kien iras la VPN-trafiko

Elŝuto de enkursiga tabelo estas la plej malmulte utila diagnozo en VPN-feraĵa solvado kaj la plej ofte algluita. Kvardek linioj da prefiksoj diras al vi, kion la maŝino povus fari, ne kion ĝi faris por la malsukcesinta peto. La mekanismo, kiun vi efektive volas, estas la serĉo: donita ĉi tiu fonto kaj ĉi tiu destino, kiu regulo kongruis, kiu tabelo estis konsultita, kaj kiu interfaco kaj sekva salteto eliris. Komencu de unu destino kaj unu fonto, poste legu la tabelon kun tiu demando en la mano, kaj la sama eligo fariĝas pruvo anstataŭ bruo.

Tabelo estas aro da kandidatoj, ne decido

Ĉiu ero priskribas prefikson kaj kion fari kun trafiko kongruanta al ĝi: sendi ĝin al interfaco, transdoni ĝin al sekva salteto, aŭ forĵeti ĝin. Nenio en tiu listo estas ordigita laŭ intenco, kaj la ero, kiu ŝajnas la plej specifa al homo, ne ĉiam estas tiu, kiun la kerno elektas, ĉar la elekto sekvas la plej longan prefikson kaj, inter egalaj prefiksoj, la metrikon.

Do la unua paŝo estas demandi la kernon anstataŭ legi la liston. La serĉa komando respondas por destino, kaj kun fonta argumento ĝi respondas por la preciza paro, kiun uzus plusendita aŭ ligita konekto:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Ĉiu adreso supre estas dokumenta ekzemplo. La punkto estas la formo de la respondo: interfaco, elektita fonta adreso, kluzo, kaj la tabelo, el kiu venis la ero. Se tiu eligo ne kongruas kun la interfaco, kiun vi atendis, vi lokalizis la problemon per unu komando, kaj nenia kvanto da legado de la plena tabelo dirus al vi, kiu kandidato venkis.

La serĉo trapasas unue regulojn, poste tabelojn

En Linux la decido estas duŝtupa. Politikaj reguloj estas taksataj laŭ prioritata ordo, kaj la unua kongrua regulo nomas tabelon por konsulti; tiu tabelo poste faras la plej longan prefiksan kongruon. Regulo povas kongrui laŭ fonto, destino, fajromuro-marko, interfaco aŭ kombinaĵo, kaj tial eligo de la ĉefa tabelo povas esti tute preciza kaj tute nerelevanta por la pako, kiun vi esploras.

ip rule show
ip route show table all | head -40
ip route show table 100

Se regulo sendas trafikon el via VPN-puto al tabelo 100, tiam tabelo 100 estas la grava, kaj la ĉefa tabelo estas logaĵo. Tio ankaŭ estas la mekanismo malantaŭ fontbaza enkursigado ĉe enkursigilo: la sama destino povas havi du malsamajn respondojn depende de tio, de kie venis la pako, kaj nur la serĉo kun fonta argumento malkaŝas, kiu validas.

IPv6 havas proprajn regulojn kaj tabelojn. Dezajno, kiu funkciigas ambaŭ familiojn, bezonas ambaŭ serĉojn, kaj funkcianta IPv4-respondo diras nenion pri la v6-vojo, kiun duloka kliento eble preferos.

Kion la VPN-kliento instalas

Klientoj kutime ne anstataŭigas la defaŭltan vojon, ĉar tio rompus la propran eksteran vojon de la tunelo. Ili instalas ion pli specifan, kio venkas laŭ prefiksa longo: paro da duon-defaŭltoj kovrantaj 0.0.0.0/1 kaj 128.0.0.0/1 estas la klasika artifiko, ĉar ambaŭ estas pli longaj prefiksoj ol 0.0.0.0/0 kaj kune kovras la tutan spacon. Aliaj instalas specifajn privatajn prefiksojn plus politikan regulon, kaj iuj aldonas markon por ke nur elektita trafiko estu kaptita.

Tial "la VPN ne ŝanĝis mian defaŭltan vojon" ne estas pruvo de fiasko. Kontrolu, kion ĝi ja aldonis, kaj ĉu la koncerna destino falas ene de tiuj prefiksoj:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Du duon-vojoj facile maltrafiĝas en eligo, ĉar ili ne aspektas kiel defaŭlto. Split-tunnel-agordo, kiu forgesis inkluzivi prefikson, produktas ĝuste tiun simptomon, kiun vi ĉasas: la aplikaĵo, kiu devus uzi la tunnelon, anstataŭe solvas kaj konektiĝas loke. Komparu la instalitajn prefiksojn kun la destinos, kiujn la uzanto efektive bezonas, ne kun la adresoj, kiujn vi hazarde testis. Split-tunnel-listo, kiu kovras la dosier-servilon sed ne ĝian solvilon, produktas konekton, kiu solviĝas al publika adreso kaj poste malsukcesas aŭtentigi, kio aspektas kiel pasvorta problemo kaj estas vojproblemo.

La ekstera vojo ankaŭ devas pluvivi

La tunelo mem estas trafiko. La pakoj, kiuj portas la enkapsuligitan ŝarĝon, iras al la adreso de la partnero trans la fizika interfaco, kaj tiu vojo ne rajtas esti enkursigita reen en la tunnelon. Kiam ĝi estas, vi ricevas la distingan fiaskon, kie la tunelo establiĝas kaj poste ĉesas pasigi trafikon, ĉar la transporto por la tunelo nun estas ene de la tunelo.

Kontrolu la adreson de la partnero same kiel vi kontrolis la internan destinon, kaj konfirmu, ke ĝi solviĝas al la fizika interfaco anstataŭ al la tunelo:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekursiva vojo, politika regulo, kiu kaptas la partneron, aŭ defaŭlto anstataŭigita de plentunela kliento estas la tri kutimaj kaŭzoj. Ĉiuj tri estas videblaj en la ekstera serĉo, kaj neniu el ili videblas en eligo de la ĉefa tabelo prenita post la fakto.

Kion enkursiga eligo ne povas diri al vi

Ĝusta serĉo signifas, ke la kerno sendus la pakon al prudenta loko. Ĝi ne signifas, ke la fajromuro permesas ĝin, ke la IPsec-politiko kovras ĝin, ke la NAT-regulo tradukas ĝin, aŭ ke la malproksima flanko havas revenan vojon. Ĉiu el tiuj estas posta stadio, kaj la notoj de strongSwan pri plusendado priskribas la ĉenon, kiun pako devas trapasi ĉe ambaŭ finoj.

Ĝi ankaŭ ne konsideras aplikaĵnivelan ligadon. Procezo povas ligiĝi al interfaco, starigi markon aŭ uzi sian propran solvilon kaj konektiĝi per nomo, kiu solviĝas alie ol tio, kion vi testis. Kiam la serĉo estas ĝusta kaj la konekto ankoraŭ malsukcesas, la sekva demando estas, kiu procezo faras ĝin kaj ĉu tiu procezo vidas la saman tabelon kiel vi.

Do tenu la diagnozon ordigita: nomu la destinon kaj la fonton, rulu la serĉon, legu nur la tabelon kaj regulon, kiujn la serĉo nomis, poste testu la sekvan stadion. Tiu sinsekvo tenas enkursigan esploron en minutoj kaj lasas registron, kiun iu alia povas sekvi, kion algluita tabelo neniam povas.