Miks kodune NAT ei kaitse sinu VPN-liidest

Koduse ruuteri taga ilma pordiedastuseta sülearvutid võtavad endiselt vastu SSH-ühendusi, mis saabuvad VPN-i kaudu. See pole vastuolu, sest kaks erinevat seadet hindavad kahte erinevat paketti. Ruuter edastab krüpteeritud transpordi ja host otsustab, mida teha dekrüpteeritud paketiga, mis jõuab tema tunneliliidesele. Nende kahe otsuse lahus hoidmine ongi kogu harjutus.

Ruuter edastab tunnelit, host hindab paketti

Visanda tee kaugest allikast teenuseni enne, kui vaatad ühtki reeglit. Välimine osa on VPN-transport, mida käsitlevad ruuter ja lüüs. Sisemine osa algab siis, kui lõpp-punkt eemaldab tunnelikihi ja host saab paketi, mis on adresseeritud tema VPN-aadressile.

Ühenda need kaks osa ja ruuter saab au otsuse eest, mille teeb host. Pordiedastuse leht või ruuteri logi kirjeldavad ainult väliseid vestlusi ja kumbki ei ütle, millist dekrüpteeritud liiklust host vastu võtab. Host rakendab sisemisele paketile oma sisendpoliitikat, samamoodi nagu igale liidesele saabuvale paketile. Just selles poliitikas otsustatakse kokkupuute küsimus tegelikult.

Metamärgiga kuulaja pole avalik teenus

Linuxis tähendab sidumine aadressiga INADDR_ANY iga kohalikku aadressi, nii et teenus võib vastata tunneliliidesel, mida ta kunagi ei nimetanud. IP-sokli viide kirjeldab seda sidumist ja seda tasub lugeda enne, kui teed kuulajate nimekirjast järeldusi. Metamärgiga kirje on fakt sokli kohta, mitte väide kättesaadavuse kohta.

Kaks rida allpool on sama teenus kahes erinevas sidumises ja erinevus on kogu vastus küsimusele, kas liidesel on tähtsust. Loe kõigepealt, millisel aadressil socket asub.

ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))

Nimeta paigutus, mis võiks pordini jõuda

Kolm paigutust panevad paketi sellele liidesele ja neil on erinevad omanikud. Õige nimetamine otsustab, kes peab poliitikat muutma.

Brauseri tulemus, mis näitab avalikku väljumisaadressi, ei ütle nende kolme kohta midagi, sest see kirjeldab, kuidas väljuv liiklus lahkub, mitte mida on sisenevale liiklusele lubatud. Tööta hoopis tagurpidi kuulajast ja teenuse logis olevast lähteaadressist. Kui allikas on teine tunneli peer, on huvitav dokument lüüsi poliitika. Kui see on tõlgitud aadress, leia tõlge enne reegli muutmist.

Piira teenus ettenähtud teega

Kui SSH-d on vaja ainult haldustee kaudu, kirjuta see tee üles lähtevahemiku ja liidesena. Seejärel piira hosti sisendreegleid liidese, sihtkoha ja allika järgi, mitte võrgunime järgi, sest privaatne näiv nimi võib tähistada ükskõik millist aadressi. Jäta marsruut inimesele, kes lahendab järgmise probleemi.

nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input

Reegel, mis nimetab tunneliliidese ja haldusvahemiku, väljendab kavatsust ühes kohas. Võrdle seda Wi-Fi-võrgu jaoks kirjutatud reegliga, mis ei ütle dekrüpteeritud tunneliliikluse kohta midagi. Kui kaks kihti ei nõustu, on hosti poliitika see, millega pakett kokku puutub.

Jäta sisselogimised ja paigad täpselt sinna, kus need on; pordini jõudmine ei olnud kunagi sama, mis selle kasutamise luba. Märgi iga tundmatu allika aadressiperekond ja aeg ning uuri enne, kui süüdistad funktsiooni või haavatavust. Reegel, mis lubab iga tunneli peeri, on teistsugune disain kui see, mis lubab haldusalavõrku, ja ükski logirida ei ütle, mida silmas peeti.

Võta parandus vastu ühe õnnestumise ja ühe keeldumisega

Tõesta mõlemad pooled: üks kinnitatud ühendus õnnestub ja üks välistatud tee lükatakse tagasi. Keeldumine on pool, mille inimesed vahele jätavad, ja just see näitab, et reegel teeb tööd, mitte ei seisa lubava vaikeväärtuse kõrval. Testi välistatud poolelt, mitte ei mõtle selle üle.

Korda paari pärast taasühendamist, sest erineva liidesenimega naasev tunnel võib vaikselt mööda minna vanale seatud reeglist. Piir, millel on tähtsust, on see, mida host rakendab pakettidele, mida ta tegelikult vastu võtab.