Odpiranje vrat VPN ne omogoči odjemalcem dostopa do LAN

Predor se dvigne, odjemalec se overi, a LAN za prehodom ostane neviden. Pravilo, ki bi to moralo popraviti, prepusti vrata VPN in deluje točno tako, kot je napisano, ker to pravilo ureja pakete, naslovljene na prehod samo. Promet odjemalca do gostitelja za prehodom ima drug cilj in drugo verigo. Uspešna prijava ne spremeni, katero od obeh verig pregleda jedro.

Dve verigi, dva različna cilja

Usodo paketa določi, kam gre, ne pa, kako je prišel. Promet na naslov prehoda se dostavi lokalno in ovrednoti po vhodnih pravilih. Promet, ki ga prehod posreduje naprej, se ovrednoti po pravilih posredovanja. Isti vmesnik predora lahko ustvari obe vrsti paketov, zato eno pravilo ne more pokriti obeh nalog.

Cel mit v enem stavku: dovoljenje poslušalca ne pove nič o dovoljenju omrežja za njim. To sta dve ločeni odločitvi z ločenimi dokazi in ime vmesnika na obeh ju ne združi.

Kaj pravilo poslušalca dejansko prepusti

Paketi poslušalca se končajo v procesu VPN in prav to omogoči, da se predor sploh vzpostavi. Upravna stran prehoda in lokalni diagnostični odgovor uporabljata tudi lastno vhodno pot gostitelja, zato preizkus do prehoda uspe, medtem ko vse za njim odpove. Oba izida sta pravilna in noben ni o LAN.

Ko proces dekapsulira promet odjemalca za drug cilj, paket vstopi na pot posredovanja in tam potrebuje dovoljenje. Uspešna overitev odloči, kdo je odjemalec; ne odloči, kam sme iti. Vprašanji imata različne lastnike, različne dnevnike in različna sporočila o napaki.

Preizkušajte z odjemalca, nikoli s prehoda

Preizkus, narejen na prehodu, sledi lastni izhodni poti gostitelja in lahko uspe, medtem ko je posredovana pot zaprta. Začnite preizkus z odjemalca in opazujte oba konca toka.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Če se zahteva pojavi na tun0 in do cilja ne prispe nič, se paket po prihodu zavrže, kar kaže na pravila posredovanja ali na lastno filtriranje cilja. Če se na tun0 ne pojavi prav nič, odjemalec tega sploh ne pošlje v predor, in težava je v usmerjanju na odjemalcu, ne v politiki na prehodu. Primerjajte to z zahtevo, ki pravilno odide in ničesar ne vrne, kar je primer povratne poti.

Posredovanje potrebuje tri stvari, ne ene

Posredovanje v jedru mora biti vklopljeno, filtrirno pravilo mora sprejeti tok in cilj mora biti dosegljiv s potjo za vrnitev odgovora. Če manjka karkoli od treh, je tišina z vidika odjemalca enaka.

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

Berite tri izhode skupaj. Ničla v prvem naredi druga dva nepomembna, privzeta politika zavračanja v drugem pa zavrže pakete odjemalca, medtem ko lastni promet prehoda deluje naprej. Tretji izhod pokaže, zakaj pravilo poslušalca ni bilo nikoli težava.

Imejte oba nabora pravil v dokumentaciji ločena

Zapišite pravilo poslušalca in pravilo posredovane storitve v ločene vrstice, z ločenimi lastniki in razlogi. Ko se vrata VPN spremenijo ali se objavi nova storitev, ta ločitev prepreči, da bi ena sprememba tiho razširila drugo.

Namesto da bi vsakega overjenega partnerja obravnavali kot zaupanja vrednega člana LAN, uporabite ozka pravila za tiste razpone odjemalcev in storitve, ki jih potrebujejo. Opombe o posredovanju pri StrongSwan opisujejo stran povratne poti in prevajanja iste meje, kar je spet tretja odločitev.

Nazadnje, držite plasti naravnost, ko je uporabnik zavrnjen. Če zahteva prispe do gostitelja in aplikacija zavrne račun, popravite dovoljenje aplikacije na tej plasti; razširitev posredovanja ne more zagotoviti poverilnic za souporabo datotek in bo razširila dostop vsem drugim, ki se uspešno povežejo.