VPN ir savienots, bet ugunsmūris joprojām bloķē: kā noteikt, kurš

Klients saka, ka ir savienots, resurss joprojām atsakās, un parastais nākamais solis ir kaut ko izslēgt. Abas kontroles šajā teikumā dara dažādu darbu: VPN būvē ceļu segtajai plūsmai, un ugunsmūris katram savienojumam izlemj, vai plūsma drīkst iet cauri. Strādājošs tunelis ar atteicošu politiku no lietotāja krēsla izskatās tieši kā salauzts tunelis, tāpēc uzdevums ir noskaidrot, kurš slānis atbild. Šeit ir secība, kurai es sekoju, kopā ar lasījumu, kas saka apstāties.

Atdaliet ceļu no politikas

Sāciet ar kļūmes formu, jo tā ir bezmaksas informācija. Pakešu nomešana rada taimautu: klients mēģina vēlreiz, nekas neatgriežas, un komanda karājas, līdz padodas. Noraidījums rada atteikumu vai atiestatīšanu: kaut kas atbildēja un teica nē. Pakalpojums, kas neklausās, atsaka pašā resursdatorā, bez jebkāda ugunsmūra.

Šie trīs iznākumi norāda uz dažādiem slāņiem. Taimauts nozīmē, ka kaut kur politika klusi atmet, vai arī ceļš nekad neiziet no mašīnas. Noraidīts nozīmē, ka jūs sasniedzāt resursdatoru un tā steks vai vietējais ugunsmūris atteica. Pilnīgs klusums, kad tuneļa saskarne ir augšā un nav ceļa uz galamērķi, nozīmē, ka ceļš ir nepareizs un neviens ugunsmūra noteikums to nelabos.

Izlasiet ceļu vienā piegājienā

Pirms skatāties uz kaut vienu noteikumu, pārliecinieties, ka tunelis nosedz galamērķi. Sadalīts tunelis, kas pārvadā tikai biroja apakštīklu, nevirzīs pieprasījumu uz citu diapazonu, un tad kļūme izskatās kā ugunsmūra bloķēšana, kas tā nav:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Ceļa izvade nosauc saskarni, pa kuru pakete izies, un avota adresi, ko tā nesīs. Ja šī saskarne ir jūsu fiziskā tīkla karte, nevis tunelis, problēma ir maršrutēšanā vai tuneļa atļautajos diapazonos, un tā pieder VPN konfigurācijai, nevis ugunsmūrim.

Viens VPN raksturīgs slazds ir pelnījis atsevišķu pārbaudi. WireGuard partnera AllowedIPs ir gan ceļš, gan kriptogrāfisks filtrs: pakete, kuras avota adrese neatbilst partnera atļautajai kopai, tiek nomesta pirms jebkura ugunsmūra noteikuma izskatīšanas. Tāpēc pilnīgi pareizs resursdatora ugunsmūris var stāvēt aiz klusa nometiena, kas izskatās kā politika, un labojums ir atslēgas konfigurācijas rinda, nevis noteikums.

Izlasiet politiku slānī, kas atbild

Kad ceļš ir pareizs, izejiet politiku no resursdatora uz āru un vērojiet to vienu slāni, kura skaitītāji kustas:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Klausošā ligzda atbild uz citu jautājumu nekā noteikumi. Ja portā nekas neklausās, kodols atsaka savienojumu un neviens ienākošais noteikums nav būtisks. Ja ligzda pastāv un savienojums no attāla klienta beidzas, kaut kur ceļā notiek nomešana, un noteikumu skaitītāji pasaka, vai tā notiek šeit.

Ieslēdziet žurnālēšanu profilam vai ķēdei, kuru turat aizdomās, nevis miniet no ārpuses. Viens reģistrēts nometiens, kas nosauc avotu, galamērķi un portu, identificē slāni un noteikumu, un arī pierāda, ka pakete ieradās, ko neviens klienta puses tests nevar konstatēt.

Izlasiet vārtejas lēmumu, kad tunelis tur beidzas

Vietnes-uz-vietni vai attālās piekļuves vārtejā VPN autentificē lietotāju un politika atļauj resursu, un tās ir atsevišķas atļaujas. Lietotājs, kas ielaists tunelī, nav automātiski ielaists katrā iekšējā resursdatorā, un atteikums bieži nāk no pārsūtīšanas noteikuma, kamēr pats tunelis ir vesels. Tāda pati atdalīšana ir IPsec, kur drošības politika, kas izvēlas plūsmu, atšķiras no filtra, kas to ielaiž, un tāpēc abi ir dokumentēti kā dažādi mehānismi RFC 4301.

Pārbaudiet atceļu tikpat rūpīgi kā aizejošo ceļu. Stāvokļa filtrēšanai ir jāredz atbilde, tāpēc asimetriska maršrutēšana caur tuneli vienā virzienā un ap to otrā rada nometienus, kas izskatās nejauši un atkārtojas tikai no dažiem klientiem. Ja plūsma sasniedz vārteju un apstājas, izlasiet pārsūtīšanas noteikumu un atceļu kopā, pirms kaut ko paplašināt.

Vārteja ir arī vieta, kur NAT vai maskēšanas noteikums var paslēpt īsto avotu. Ja iekšējie resursdatori redz vārtejas adresi, nevis klientu, viņu resursdatora ugunsmūra noteikumi, kuriem jāsakrīt ar klientu kopu, nekad nesakritīs, un labojums pieder vārtejai, nevis katram serverim.

Mainiet šaurāko slāni, tad pārbaudiet

Pretojieties plašam remontam. Resursdatora ugunsmūra izslēgšana, visu atļaujoša noteikuma pievienošana vai katras saskarnes iegrūšana uzticamā profilā katrā gadījumā noņem kontroli, kas darīja savu darbu, un izmaiņa pārdzīvo incidentu. Noteikums, kas ierobežots ar avota diapazonu un attiecīgo portu, ir vieglāk pārskatāms, vieglāk noņemams, un atstāj pārējo mašīnas politiku neskartu.

Pārbaudiet ar to pašu testu, kas neizdevās, no tā paša klienta, un pēc tam vēlreiz pēc atkārtotas savienošanas, jo noteikums, kas sakrita pirms tuneļa atkārtotas vienošanās, var pārstāt sakrist pēc tam:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Pirms to aizverat:

• Ceļš uz galamērķi iziet pa tuneļa saskarni, un avota adrese atbilst tam, ko gaida politika.
• Portā kaut kas klausās, un atteikums vai taimauts tiek attiecināts uz nosauktu noteikumu, nevis pieņemts.
• Vārteja pārsūta abos virzienos, un galamērķis redz avotu, kuram tika rakstīti jūsu noteikumi.
• Neviena kontrole netika izslēgta, lai tests izietu, un jūsu veiktā izmaiņa nosauc vienu avota diapazonu un vienu portu.