Pot VPN ali pravilo požarnega zidu: kaj spusti paket?

Z istim paketom se zgodita dve neodvisni odločitvi in vsaka od njiju lahko zahtevek tiho konča. Iskanje poti izbere vmesnik in naslednji skok, nato paketni filter odloči, ali je ta kombinacija dovoljena. Časovna omejitev vam pove, da je ena od dveh zavrnila, ne katera. Pojdite skozi faze po vrsti in popravilo običajno neha biti ugibanje.

Dve odločitvi, en paket, dva lastnika

Iskanje poti najprej povpraša pravila politike, nato tabelo, na katero kažejo, in izbere najbolj specifično predpono, ki se ujema s ciljem. Odjemalec, ki je namestil tunelsko pot, je lastnik te odločitve, in nič v pravilu požarnega zidu je ne more nadomestiti. Ko iskanje pokaže na nepričakovano mesto, vsaka naslednja faza dela na napačnem paketu.

Filtriranje je ločeno. Na gostitelju Linux kavlji netfilter delijo promet glede na to, za koga je paket: izhod zapusti stroj, vhod se na njem konča, posredovanje gre skozenj. Prehod, ki sprejema odjemalce VPN in jih usmerja v LAN, potrebuje pot posredovanja, in to je natanko tista veriga, ki jo večina privzetih konfiguracij pusti prazno.

Izbira vira pripada isti odločitvi, in prav tu se skriva večina neskladij. Jedro izbere izvorni naslov z izhodnega vmesnika, razen če pot navede enega, zato pravilo filtra, napisano za podomrežje LAN, nikoli ne ustreza paketu, ki odide z naslovom tunela.

Preberite, kaj je iskanje dejansko izbralo

Natisnite odločitev, namesto da bi jo sklepali. Spodnji ukaz razreši pot, ki bi jo jedro uporabilo za ta cilj, vključno z vmesnikom in virom, ki bi ga izbralo:

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'

Odjemalci VPN pogosto namestijo pravila politike na prioritetah pod glavno tabelo, zato čista glavna tabela sama po sebi ničesar ne dokazuje. Primerjajte prioritete pravil s tabelami, ki jih izberejo, in preverite, ali tunelska pot preživi ponovno povezavo, namesto da bi bila enkrat dodana ročno.

IPsec na osnovi politike doda tretjo stopnjo ujemanja, ki je usmerjanje ne pokriva, kot opisujejo opombe strongSwan o posredovanju za tunelske in transportne nastavitve. Varnostna politika izbere promet po predponi in protokolu, medtem ko pot le odloči, kam bi šel nezaščiten paket. Podomrežje, ki je usmerjeno, a nima ustreznega selektorja, bodisi ostane nezaščiteno bodisi se zavrže, odvisno od konfiguracije, in noben izid ni videti kot težava požarnega zidu. Natisnite politiko in primerjajte njene selektorje s predponami, za katere ste pričakovali, da jih bo tunel prenašal.

Filtriranje velja na kavlju, ne na poti

Pravilo, ki dovoli poslušalec VPN, je pravilo o prometu, naslovljenem na prehod samega. Ne pove ničesar o odjemalcih, ki dosežejo gostitelje za tem prehodom, ker posredovani promet poteka po drugi verigi. Branje nabora pravil kot enega ravnega seznama je običajen vzrok, da pravilno videti pravilo nikoli ne sproži.

Števci hitro razrešijo vprašanje. Pravilo z ničelnim števcem paketov ni bilo nikoli doseženo, kar kaže na napačno verigo, napačen vmesnik ali prejšnje zavrženje. Pravilo z naraščajočim števcem pod politiko zavrženja je meja, ki ste jo iskali, in paket se zavrže, namesto da bi bil napačno usmerjen.

Pošljite sondo po poti, ki jo uporablja odjemalec

Preizkusi, izvedeni na prehodu samem, gredo skozi izhod in vhod z lastnim izvornim naslovom prehoda. To je drugačna pot od posredovane zahteve odjemalca, zato uspešen lokalni curl dokaže manj, kot se zdi. Preizkusite s stroja, ki ne uspe, ali izrecno pripnite vmesnik in vir.

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'

Zajem na obeh koncih loči preostale primere. SYN, ki zapusti odjemalca in nikoli ne prispe, pomeni usmerjanje, šifriranje ali seznam dostopa višje gorvodno. SYN, ki prispe in ne dobi odgovora, pomeni storitev ali njen filter gostitelja, in tunel nikoli ni bil težava.

Povratni promet si zasluži svoj pogled. Asimetrično usmerjanje in filtriranje povratne poti zavržeta odgovore, ki prispejo na napačen vmesnik, kar se pokaže kot enosmerna povezava, ne kot blokirana vrata. Preverite vrednost sysctl, preden okrivite požarni zid za simptom, ki ga ni povzročil.

Beleženje deluje kot drugo mnenje, ne kot prvi korak. Začasna izjava dnevnika na verigi posredovanja poimenuje vmesnik in naslove, ki so jo zadeli, in jo je pozneje enostavno odstraniti. Pustite jo trajno in zgradili ste težavo z obsegom dnevnikov namesto odgovora.

Vsako spremembo postavite tja, kjer preživi ponovno povezavo

Pot, dodana z ip route add, živi, dokler vmesnik ne pade. Shranite jo v profil povezave: NetworkManager sprejema dodatne poti na povezavi, netplan pa jih ohrani med zagoni. Isto pravilo velja za izjemo požarnega zidu na strani odjemalca, ki izgine po naslednjem ponovnem nalaganju.

Pravila na strani strežnika pripadajo konfiguracijski datoteki, ki jo storitev naloži ob zagonu, ne interaktivni seji, ki se konča, ko jo zaprete. Napišite pravilo, znova naložite in potrdite, da se je števec premaknil, ker ponovno nalaganje, ki je zavrnilo sintakso, tiho pusti stari nabor pravil na mestu.

Nato ponovite prvotno zahtevo aplikacije od začetka do konca in zabeležite, kateri sloj se je spremenil. Popravek poti, ki je potreboval tudi spremembo filtra, bo še vedno propadel, in drugo napako je veliko lažje brati, ko veste, da prve ni več. Zabeležite datum in različico odjemalca ob rezultatu, saj se privzete nastavitve usmerjanja in filtriranja premikajo med različicami. Imajte to opombo na zahtevku, da naslednja oseba začne tam, kjer ste se ustavili, namesto da bi ponavljala dvostopenjsko pot.