ufw allow 443 nepalīdzēja pakalpojumam aiz VPN

Ping izdodas no VPN klienta, TCP pakalpojums nokļūst taimautā, un ufw allow 443/tcp nemaina pilnīgi neko. Kad lietojumprogramma darbojas resursdatorā aiz vārtejas, nevis pašā vārtejā, šī atļauja tika rakstīta nepareizajam trafika ceļam. Pakete nav adresēta ugunsmūrim un netiek piegādāta vietējam procesam, tāpēc ievades noteikumi to nekad neredz. Labojums ir maršruta noteikums, kas vērsts uz pārsūtīto plūsmu, un tā pierādījums jau ir žurnālā.

Izlemiet, vai galamērķis ir vietējs vai pārsūtīts

Lasiet paketi tā, kā to redz kodols. Trafiks, kas piegādāts pakalpojumam uz vārtejas, ir vietēja ievade. Trafiks, ko vārteja pārsūta uz citu resursdatoru, ir pārsūtīts, un UFW uztur atsevišķus noteikumu kopumus abiem ceļiem. Atšķirību nosaka galamērķa adrese un maršruta meklēšana, nevis saskarne, pa kuru pakete ieradās.

Žurnāla rinda, kas rāda vienu un to pašu saskarni gan IN, gan OUT laukā, joprojām var aprakstīt maršrutētu paketi, jo tunelis, kas pārvieto klientus iekšā un ārā no vienas ierīces, izskatās tieši tā. Galamērķa adrese šo jautājumu atrisina ātrāk nekā saskarņu nosaukumi. Viena un tā paša nosaukuma redzēšana divreiz nepierāda vietēju piegādi, un tuneļa saskarnes, ko izvietojums nekad nav izveidojis, izdomāšana arī nepalīdz.

Izlasiet bloku pirms jebkura noteikuma pievienošanas

Atkārtojiet vienu atļautu savienojuma mēģinājumu un fiksējiet tā avotu, galamērķi, protokolu un galamērķa portu tā, kā tos fiksēja vārteja. Salīdziniet šīs četras vērtības ar žurnāla ierakstu un ar pakalpojuma faktisko atrašanās vietu. Iepriekšējs veiksmīgs ping pierāda tikai to, ka tā paša apmaiņa bija atļauta, un ugunsmūris var apstrādāt TCP SYN uz lietojumprogrammu pavisam citādi.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Pirmā komanda atgriež spriedumu kopā ar tā laukiem, bet otrā parāda, kas jau ir ielādēts un kādā secībā. Izlasiet abas pirms kaut ko rediģējat, jo iepriekšējs aizliegums virs jūsu noteikuma izskaidro tos pašus simptomus bez neviena trūkstoša noteikuma.

Ierakstiet šaurāko atbilstošo maršruta noteikumu

Šajā piemērā klienti ierodas uz tun0 no 172.20.8.0/24, pakalpojums klausās 10.30.0.15 uz porta 8443, un vārteja iziet caur ens5. Šīs vērtības tika izvēlētas, lai tās nemaz nelīdzinātos mākoņa VPC noklusējumam 10.0.0.0/16 vai mājas tīklam 192.168.0.0/16, un 8443 tur piemēru tālu no pašas vārtejas 443 klausītāja.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Sausā palaide izdrukā noteikumu kopumu, kas rastos, un tas ir lētākais veids, kā redzēt, vai jūsu noteikums nonāk pirms esoša aizlieguma vai pēc tā. Pārbaudiet saskarņu nosaukumus un iekšējās adreses pret izvietojumu, nevis pret piemēru, un atcerieties, ka tad, kad galamērķa NAT darbojas pirmais, filtrs redz jau pārtulkoto galamērķi.

Saglabājiet atgriešanās ceļu stāvokļa

UFW izseko atļautos savienojumus, tāpēc atbildes uz atļautu pārsūtīto plūsmu tiek ielaistas bez skaidra pretēja noteikuma. Neierobežota noteikuma pievienošana pretējā virzienā, lai viss darbotos, paplašina politiku daudz tālāk par vienu pakalpojumu un nav nepieciešama parastai pieprasījuma un atbildes apmaiņai. Saglabājiet atgriešanās ceļu netiešu un noteikumu kopumu lasāmu.

Piemērojiet noteikumu tikai pēc tam, kad sausā palaide atbilst jūsu nodomam, pēc tam pārliecinieties, ka sakārtotais saraksts rāda to gaidītajā vietā. Saglabājiet VPN klausītāju un pārvaldības noteikumus kā atsevišķus jautājumus, jo to maiņa ir cits lēmums nekā vienas lietojumprogrammas ielaide. Pierakstiet izmaiņas tur, kur pierakstīta topoloģija, lai nākamajam inženierim tās nav no jauna jāatklāj no pakešu ieraksta.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Pārbaudiet, ko UFW nevar nodrošināt jūsu vietā

Pareizam noteikumam joprojām vajag kodola pārsūtīšanu un maršrutu, kas sasniedz pakalpojumu. Apstipriniet abus pirms ugunsmūra vainošanas otro reizi.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Pēc tam paskatieties ārpus resursdatora. Mākoņa instancē viešņas UFW politika neaizstāj drošības grupas, apakštīkla ACL vai paša pakalpojumu sniedzēja pārsūtīšanas konfigurāciju, tāpēc vietējs bloķējums ir pierādījums par vienu slāni, nevis pierādījums, ka visi pārējie slāņi pieļauj pakalpojumu.

Pabeidziet, pārbaudot jaunu savienojumu ar ieslēgtu ugunsmūri, no atļauta avota un no nesaistīta avota. UFW izslēgšana novērš simptomu un iznīcina pierādījumus tajā pašā komandā, tāpēc tam vajadzētu būt pēdējam eksperimentam, nevis pirmajam.