VPN maršruts vai ugunsmūra noteikums: kas nomet paketi?

Vienam un tam pašam paketam notiek divi neatkarīgi lēmumi, un jebkurš no tiem var klusi izbeigt pieprasījumu. Maršruta meklēšana izvēlas saskarni un nākamo lēcienu, pēc tam pakešu filtrs izlemj, vai šī kombinācija ir atļauta. Taimauts jums pasaka, ka viens no diviem atteicās, nevis kurš. Ejiet cauri posmiem pēc kārtas, un labojums parasti pārstāj būt minējums.

Divi lēmumi, viens pakets, divi īpašnieki

Maršruta meklēšana vispirms konsultējas ar politikas noteikumiem, pēc tam ar tabulu, uz kuru tie norāda, un izvēlas konkrētāko prefiksu, kas atbilst galamērķim. Klientam, kurš instalējis tuneļa maršrutu, pieder šis lēmums, un nekas ugunsmūra noteikumā nevar to aizstāt. Kad meklēšana norāda uz negaidītu vietu, katrs vēlākais posms strādā ar nepareizo paketi.

Filtrēšana ir atsevišķa. Linux resursdatorā netfilter āķi sadala trafiku pēc tā, kam pakete ir paredzēta: izeja atstāj mašīnu, ieeja tajā beidzas, pārsūtīšana iet cauri. Vārtejai, kas pieņem VPN klientus un maršrutē tos uz LAN, ir vajadzīgs pārsūtīšanas ceļš, un tā ir tieši tā ķēde, kuru lielākā daļa noklusējuma konfigurāciju atstāj tukšu.

Avota izvēle pieder pie tā paša lēmuma, un tieši tur slēpjas lielākā daļa neatbilstību. Kodols izvēlas avota adresi no izejošās saskarnes, ja vien maršruts nenorāda kādu, tāpēc filtra noteikums, kas rakstīts LAN apakštīklam, nekad neatbilst paketei, kas iziet ar tuneļa adresi.

Izlasi, ko meklēšana patiešām izvēlējās

Izdrukājiet lēmumu, nevis seciniet to. Tālāk dotā komanda atrisina maršrutu, ko kodols izmantotu šim galamērķim, tostarp saskarni un avotu, ko tas izvēlētos:

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 klienti bieži instalē politikas noteikumus ar prioritātēm zem galvenās tabulas, tāpēc tīra galvenā tabula pats par sevi neko nepierāda. Salīdziniet noteikumu prioritātes ar tabulām, ko tie izvēlas, un pārbaudiet, vai tuneļa maršruts iztur atkārtotu savienojumu, nevis tiek pievienots ar roku vienreiz.

Uz politiku balstīts IPsec pievieno trešo saskaņošanas posmu, ko maršrutēšana neaptver, kā apraksta strongSwan pārsūtīšanas piezīmes tuneļa un transporta iestatījumiem. Drošības politika izvēlas trafiku pēc prefiksa un protokola, bet maršruts tikai izlemj, kur aizietu neaizsargāta pakete. Apakštīkls, kas tiek maršrutēts, bet kam nav atbilstoša selektora, vai nu paliek neaizsargāts, vai tiek izmests atkarībā no konfigurācijas, un neviens no rezultātiem neizskatās pēc ugunsmūra problēmas. Izdrukājiet politiku un salīdziniet tās selektorus ar prefiksiem, ko gaidījāt, ka tunelis pārnēsās.

Filtrēšana attiecas uz āķi, nevis uz maršrutu

Noteikums, kas atļauj VPN klausītāju, ir noteikums par trafiku, kas adresēts pašai vārtejai. Tas neko nepasaka par klientiem, kas sasniedz resursdatorus aiz šīs vārtejas, jo pārsūtītais trafiks iet pa citu ķēdi. Noteikumu kopas lasīšana kā viena plakana saraksta ir ierastais iemesls, kāpēc pareizi izskatāms noteikums nekad neiedarbojas.

Skaitītāji ātri izšķir jautājumu. Noteikums ar nulles pakešu skaitu nekad netika sasniegts, kas norāda uz nepareizu ķēdi, nepareizu saskarni vai agrāku nomešanu. Noteikums ar augošu skaitītāju nomešanas politikas ietvaros ir robeža, ko meklējāt, un pakete tiek izmesta, nevis maršrutēta nepareizi.

Nosūtiet zondi pa ceļu, ko izmanto klients

Testi, kas tiek izpildīti pašā vārtejā, iet cauri izejai un ieejai ar pašas vārtejas avota adresi. Tas ir cits ceļš nekā klienta pārsūtītais pieprasījums, tāpēc veiksmīgs vietējais curl pierāda mazāk, nekā šķiet. Pārbaudiet no mašīnas, kas neizdodas, vai skaidri piespraudiet saskarni un avotu.

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'

Uzņemšana abos galos atdala atlikušos gadījumus. SYN, kas atstāj klientu un nekad neierodas, nozīmē maršrutēšanu, šifrēšanu vai augšupēju piekļuves sarakstu. SYN, kas ierodas un nesaņem atbildi, nozīmē pakalpojumu vai tā resursdatora filtru, un tunelis nekad nav bijis problēma.

Atgaitas trafiks ir pelnījis savu skatienu. Asimetriska maršrutēšana un apgrieztā ceļa filtrēšana izmet atbildes, kas ierodas nepareizajā saskarnē, un tas izpaužas kā vienvirziena savienojums, nevis bloķēts ports. Pārbaudiet sysctl vērtību pirms ugunsmūra vainošanas par simptomu, ko tas neizraisīja.

Žurnālēšana darbojas kā otra viedoklis, nevis pirmais solis. Pagaidu žurnāla ieraksts pārsūtīšanas ķēdē nosauc saskarni un adreses, kas to skāra, un to ir viegli noņemt vēlāk. Atstājiet to pastāvīgi, un jūs esat uzbūvējis žurnāla apjoma problēmu, nevis atbildi.

Novietojiet katru izmaiņu tur, kur tā iztur atkārtotu savienojumu

Maršruts, kas pievienots ar ip route add, dzīvo, līdz saskarne nokrīt. Saglabājiet to savienojuma profilā: NetworkManager pieņem papildu maršrutus savienojumā, un netplan saglabā tos starp palaišanām. Tas pats noteikums attiecas uz klienta puses ugunsmūra izņēmumu, kas pazūd pēc nākamās pārlādes.

Servera puses noteikumi pieder konfigurācijas failam, ko pakalpojums ielādē startējot, nevis interaktīvai sesijai, kas beidzas, kad to aizverat. Ierakstiet noteikumu, pārlādējiet un apstipriniet, ka skaitītājs ir pārvietojies, jo pārlāde, kas noraidīja sintaksi, klusi atstāj veco noteikumu kopu vietā.

Pēc tam atkārtojiet sākotnējo lietojumprogrammas pieprasījumu no sākuma līdz beigām un pierakstiet, kurš slānis mainījās. Maršruta labojums, kuram vajadzēja arī filtra maiņu, joprojām neizdosies, un otro neveiksmi ir daudz vieglāk lasīt, kad zināt, ka pirmā ir pazudusi. Pierakstiet datumu un klienta versiju blakus rezultātam, jo maršrutēšanas un filtrēšanas noklusējumi abi mainās starp versijām. Turiet šo piezīmi biļetenā, lai nākamais cilvēks sāktu tur, kur jūs apstājāties, nevis atkārtotu divu posmu ceļu.