VPN, kas pieslēdzas, bet neko nesasniedz, parasti tiek aprakstīts kā ugunsmūra problēma, un risinājums, pie kura ķeras cilvēki, ir tunela saskarnes ievietošana uzticamā zonā. Tas darbojas tādā nozīmē, ka trafiks sāk plūst, bet tas arī ielaiž daudz vairāk nekā paredzēto pakalpojumu. Abas iesaistītās politikas atšķiras: viena ielaiž ārējo transportu klausošā ligzdā, otra autorizē atšifrētu trafiku sasniegt konkrētu resursu. Tieši to uzskatīšana par vienu iestatījumu šauru atļauju pārvērš plašā. Abas tiek izlemtas dažādās vietās, tāpēc šo kļūdu ir tik viegli izdarīt.

Divas politikas, viens tunelis

Ārējā politika atbild uz vienkāršu jautājumu: vai pakete no šī avota var sasniegt UDP 1194 šajā resursdatorā? Iekšējā politika atbild uz citu: vai autentificētais klients aiz šī tuneļa var sasniegt šo galamērķi, ar šo protokolu, šajā portā? Pirmā ir par ligzdu, otrā par ceļu, un firewalld modelē tās ar dažādiem objektiem, jo tās tiek izlemtas dažādos punktos. Viena ir ligzdas īpašība šajā resursdatorā, otra – caur to ejoša ceļa.

Praktiskās sekas ir tādas, ka strādājošs tunelis neko nepasaka par otro politiku, un pareiza otrā politika nepadara pirmo lieku.

Ielaidiet faktisko ārējo klausītāju

Sāciet ar to, kas jau ir piešķirts, nevis ar pieņēmumiem. Izlasiet aktīvās zonas, uzskaitiet zonu, kas faktiski pārvadā ienākošo trafiku, un pārbaudiet instalēto pakalpojuma definīciju, jo pakalpojuma nosaukums apraksta portu kopumu un neko nepasaka par to, vai šī servera klausītājs tam atbilst.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Ja klausītājs patiešām ir UDP 1194 šajā zonā, atveriet tieši šo portu un transportu, pēc tam pēc pārbaudes padariet to pašu konkrēto noteikumu pastāvīgu. Pārbaudiet arī avota balstītus piešķīrumus, jo zona, kas saistīta ar avota diapazonu, var pārtvert trafiku, pirms saskarnes zona to vispār ierauga.

Autorizējiet atšifrēto galamērķi atsevišķi

Savienojums ar pakalpojumu, kas darbojas pašā VPN serverī, ir lokālā ievades politika. Savienojumam, kas tiek pārsūtīts uz citu LAN resursdatoru, nepieciešama pārsūtīšanas politika, kodolā iespējota pārsūtīšana un atbildes maršruts — trīs atsevišķas prasības, ko cilvēki bieži saplūdina vienā. Mūsdienu firewalld politikas objekti apraksta virzītu trafiku starp ieejas un izejas zonu, un tieši tur ir īstā vieta, kur izteikt, kuri VPN avoti drīkst sasniegt kurus privātos pakalpojumus.

Skaidri definējiet atļautos avotus un ļaujiet visam pārējam nonākt atteikumā. Atļauja ārējam pakalpojumam nav šī politika, lai kā arī izskatītos zonu izkārtojums.

Kāpēc uzticēšanās saskarnei ir nepareizais īsceļš

Tuneļa saskarnes ievietošana zonā, kuras mērķis pieņem visu, ielaiž visu atšifrēto trafiku uz katru pakalpojumu, ko resursdators pakļauj, tostarp tiem, kurus neesat pārskatījis. Uzticamās zonas pārkonfigurēšana uz ierobežojošu strādājošā mašīnā ir sliktāka, jo citas saskarnes un avotu diapazoni jau var būt atkarīgi no tās nozīmes un mainīs uzvedību, kad to rediģēsiet. Ja jums vajag šauru politiku, izveidojiet to; neizmantojiet koplietotu zonu no jauna.

Saglabājiet arī tuneļa zonas piešķīrumu stabilu caur jebkuru komponenti, kurai pieder šī konfigurācija. Piešķīruma zaudēšana restartā rada kļūmi, kas izskatās pēc ugunsmūra noteikuma problēmas un patiesībā ir noturības problēma.

Pārbaudiet trīs lietas, tostarp vienu atteikumu

Pārbaudiet ārējo savienojumu no ārpuses, pārbaudiet vienu autorizētu iekšējo pakalpojumu no pievienota klienta un pārbaudiet vienu pakalpojumu, kuram jāpaliek nesasniedzamam. Trešais tests ir tas, kas atšķir politiku no blakusparādības, un tieši to cilvēki izlaiž, jo šķiet, ka viss darbojas. Ja atteiktais pakalpojums atbild, jūs esat ielaidis zonu, nevis pakalpojumu.

Pierakstiet zonu, portu, transportu un politikas objektu servera piezīmēs. Citādi nākamā izmaiņa šajā resursdatorā sāksies no tā paša pieņēmuma.

Saistītie raksti