VPN-pordi avamine ei anna klientidele juurdepääsu LAN-ile

Tunnel tõuseb, klient autendib end, aga lüüsi taga olev LAN jääb nähtamatuks. Reegel, mis pidi selle parandama, lubab VPN-porti ja töötab täpselt nii, nagu kirjutatud, sest see reegel reguleerib pakette, mis on adresseeritud lüüsile endale. Kliendi liiklus lüüsi taga oleva hosti juurde on teise sihtkohaga ja teise ahelaga. Edukas sisselogimine ei muuda seda, millist kahest ahelast tuum kontrollib.

Kaks ahelat, kaks erinevat sihtkohta

Paketi saatuse otsustab see, kuhu ta läheb, mitte see, kuidas ta saabus. Lüüsi aadressile suunatud liiklus toimetatakse kohale ja hinnatakse sisendreeglite järgi. Liiklus, mille lüüs edasi edastab, hinnatakse edastusreeglite järgi. Sama tunneli liides võib toota mõlemat tüüpi pakette, seetõttu ei saa üks reegel mõlemat tööd katta.

Kogu müüt ühes lauses: kuulaja lubamine ei ütle midagi selle taga oleva võrgu lubamise kohta. Need on kaks eraldi otsust eraldi tõenditega ja liidese nimi mõlemal ei ühenda neid.

Mida kuulaja reegel tegelikult lubab

Kuulaja paketid lõpevad VPN-protsessis ja just see võimaldab tunnelit üldse püsti panna. Lüüsi haldusleht ja kohalik diagnostiline vastus kasutavad samuti hosti enda sisendteed, seetõttu õnnestub lüüsile suunatud test, samal ajal kui kõik selle taga ebaõnnestub. Mõlemad tulemused on õiged ja kumbki ei puuduta LAN-i.

Kui protsess dekapsuleerib kliendi liikluse teise sihtkoha jaoks, siseneb pakett edastusteele ja vajab seal luba. Edukas autentimine otsustab, kes on klient; see ei otsusta, kuhu klient minna tohib. Kahel küsimusel on erinevad omanikud, erinevad logid ja erinevad veateated.

Testige kliendi poolt, mitte kunagi lüüsi poolt

Lüüsil genereeritud test järgib hosti enda väljundteed ja võib õnnestuda, kui edastustee on suletud. Alustage testi kliendilt ja jälgige voo mõlemat otsa.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Kui päring ilmub tun0-le ja sihtkohta ei jõua midagi, visatakse pakett pärast saabumist ära, mis viitab edastusreeglitele või sihtkoha enda filtreerimisele. Kui tun0-l ei ilmu üldse midagi, ei saada klient seda isegi tunnelisse ja probleem on kliendi marsruutimises, mitte lüüsi poliitikas. Võrrelge seda päringuga, mis väljub korrektselt ja ei tagasta midagi, mis on tagasitee juhtum.

Edastamine vajab kolme asja, mitte ühte

Tuuma edastamine peab olema lubatud, filtrireegel peab voo vastu võtma ja sihtkoht peab olema kättesaadav koos teega vastuse tagasitulekuks. Kui üks kolmest puudub, on vaikus kliendi vaatepunktist sama.

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

Lugege kolme väljundit koos. Null esimeses teeb teised kaks tähtsusetuks ja teises olev vaikimisi tõrjumise poliitika viskab kliendi paketid ära, samal ajal kui lüüsi enda liiklus töötab edasi. Kolmas väljund näitab, miks kuulaja reegel ei olnud kunagi probleem.

Hoidke kaks reeglistikku dokumentatsioonis eraldi

Kirjutage kuulaja reegel ja edastatava teenuse reegel eraldi ridadele, eraldi omanike ja põhjustega. Kui VPN-port muutub või avaldatakse uus teenus, takistab see eraldamine ühel muudatusel teist vaikselt laiendada.

Selle asemel et pidada iga autenditud partnerit usaldusväärseks LAN-i liikmeks, kasutage kitsaid reegleid nende kliendivahemike ja teenuste jaoks, mis neid vajavad. StrongSwan’i edastamise märkmed kirjeldavad sama piiri tagasitee ja tõlkimise poolt, mis on jälle kolmas otsus.

Lõpuks hoidke kihid sirged, kui kasutaja lükatakse tagasi. Kui päring jõuab hostini ja rakendus lükkab konto tagasi, parandage rakenduse luba sellel kihil; edastamise laiendamine ei saa anda failijagamise mandaati ja laiendab juurdepääsu kõigile teistele, kes edukalt ühenduvad.