VPN porta atvēršana neļauj klientiem sasniegt LAN

Tunelis ceļas, klients autentificējas, bet LAN aiz vārtejas paliek neredzams. Noteikums, kam tas bija jāizlabo, atļauj VPN portu un darbojas tieši tā, kā rakstīts, jo tas regulē paketes, kas adresētas pašai vārtejai. Klienta plūsmai uz resursdatoru aiz vārtejas ir cits galamērķis un cita ķēde. Veiksmīga pieteikšanās nemaina to, kuru no abām ķēdēm kodols skata.

Divas ķēdes, divi atšķirīgi galamērķi

Paketes likteni nosaka tas, kurp tā iet, nevis kā tā atnāca. Plūsma uz vārtejas adresi tiek piegādāta lokāli un novērtēta pēc ievades noteikumiem. Plūsma, ko vārteja pārsūta tālāk, tiek novērtēta pēc pāradresācijas noteikumiem. Tā pati tuneļa saskarne var radīt abus paketes veidus, tāpēc viens noteikums nevar aptvert abus darbus.

Viss mīts vienā teikumā: klausītāja atļaušana neko nesaka par tīkla aiz tā atļaušanu. Tie ir divi atsevišķi lēmumi ar atsevišķiem pierādījumiem, un saskarnes nosaukums uz abiem tos nesavieno.

Ko klausītāja noteikums patiešām atļauj

Klausītāja paketes beidzas VPN procesā, un tieši tas ļauj vispār izveidot tuneli. Vārtejas administrēšanas lapa un lokāla diagnostikas atbilde arī izmanto paša resursdatora ievades ceļu, tāpēc pārbaude uz vārteju izdodas, kamēr viss aiz tās cieš neveiksmi. Abi rezultāti ir pareizi un neviens nav par LAN.

Kad process dekapsulē klienta plūsmu citam galamērķim, pakete nonāk pāradresācijas ceļā un tur vajag atļauju. Veiksmīga autentifikācija izlemj, kas ir klients; tā neizlemj, kurp klients drīkst iet. Abiem jautājumiem ir citi īpašnieki, citi žurnāli un citi kļūdas ziņojumi.

Pārbaudiet no klienta, nekad no vārtejas

Uz vārtejas veidots tests seko paša resursdatora izejas ceļam un var izdoties, kamēr pāradresācijas ceļš ir slēgts. Sāciet testu no klienta un vērojiet abus plūsmas galus.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Ja pieprasījums parādās uz tun0 un nekas nesasniedz galamērķi, pakete tiek izmesta pēc ierašanās, kas norāda uz pāradresācijas noteikumiem vai paša galamērķa filtrēšanu. Ja uz tun0 neparādās nekas, klients to pat nesūta tunelī, un problēma ir klienta maršrutēšanā, nevis vārtejas politikā. Salīdziniet ar pieprasījumu, kas iziet pareizi un neko neatgriež, kas ir atgriešanās ceļa gadījums.

Pāradresācijai vajag trīs lietas, nevis vienu

Kodola pāradresācijai jābūt ieslēgtai, filtra noteikumam jāpieņem plūsma, un galamērķim jābūt sasniedzamam ar ceļu atbildei atgriezties. Ja trūkst kaut viena, klienta skatījumā klusums ir tāds pats.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lasiet trīs izvades kopā. Nulle pirmajā padara pārējās divas nenozīmīgas, un otrajā esošā noklusējuma nomešanas politika met klienta paketes, kamēr pašas vārtejas plūsma turpina strādāt. Trešā izvade parāda, kāpēc klausītāja noteikums nekad nebija problēma.

Turiet abus noteikumu kopumus dokumentācijā atsevišķi

Rakstiet klausītāja noteikumu un pārsūtītā pakalpojuma noteikumu atsevišķās rindās, ar atsevišķiem īpašniekiem un iemesliem. Kad VPN ports mainās vai tiek publicēts jauns pakalpojums, šī atdalīšana neļauj vienai izmaiņai klusi paplašināt otru.

Tā vietā, lai uzskatītu katru autentificēto partneri par uzticamu LAN dalībnieku, izmantojiet šaurus noteikumus tiem klientu diapazoniem un pakalpojumiem, kuriem tie vajadzīgi. StrongSwan pāradresācijas piezīmes apraksta tās pašas robežas atgriešanās maršruta un tulkošanas pusi, kas atkal ir trešais lēmums.

Visbeidzot, turiet slāņus taisni, kad lietotājs tiek noraidīts. Ja pieprasījums sasniedz resursdatoru un lietotne noraida kontu, labojiet lietotnes atļauju tajā slānī; pāradresācijas paplašināšana nevar dot failu koplietošanas akreditācijas datus un paplašinās piekļuvi visiem pārējiem, kas veiksmīgi pieslēdzas.