VPN-i väljumis-IP ei ole tunneli tõestus: mida serverid näevad

Keegi küsib teenust, kuhu pääsevad ainult VPN-i kasutajad, ja ilmne lahendus on lubada väljumisaadresside nimekiri. Nimekiri teeb midagi tõelist: see piirab, kes saab ühenduda. See ei tõesta, et tunnelit kasutati, sest aadress kuulub sellele, kes väljundit haldab, ja see operaator saab edasi suunata kõigi liiklust. Nende väidete vahe on kogu disainiprobleem.

Server näeb ühte aadressi ühenduse kohta

Ühendus saabub lähteaadressi ja sihtpordiga ning see on kõik, mida võrgukiht teatab. Kui klient kasutab tunnelit, tulevad sinu kuulajani jõudvad paketid väljundist või selle ees olevast tõlkest. Kliendi enda aadress, tavaliselt privaatne, ei ilmu kunagi. Seetõttu ei tee kliendi kohtvõrgu vahemikule kirjutatud tulemüürireegel üldse midagi.

Kõik pärast seda lähteaadressi on rakenduse andmed ja rakendus saab neid usaldada ainult niivõrd, kuivõrd ta neid autendib.

Testi, milline sinu väljund välja näeb

Vaata teed mõlemast otsast enne reegli kirjutamist. Kliendi vaade oma väljundile ja serveri vaade ühendusele on kaks fakti, mis loevad.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

Esimene käsk teatab avaliku aadressi, millega klient paistab, ja see on väärtus, mida peab sisaldama iga lubatud nimekiri. Teine näitab serveril loodud ühendusi koos nende partneraadressidega, ja just sellega reegel tegelikult sobib. Kui need kaks ei ühti sinu mõttemudeliga, paranda mudel enne poliitika muutmist. Pilveandmebaasi tulemüür, rakenduse lubatud nimekiri ja koormusjaotur võivad igaüks näha erinevat tõlkekihti.

Loetleda saab ainult ühte kahest väljundite hulgast

Üks juhtum on päringu hetkel kontrollitav ja teine mitte, mis annab väga erinevad tagatised.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

Avaldatud Tori väljumisnimekirja saab hankida ja võrrelda, sõltuvalt nimekirja vanusest ja iga väljundi enda poliitikast, seega on teadaolevate väljundite vastu kehtiv keeldumisreegel jõustatav ja ülevaatatav. Kommerts-VPN-ide jaoks samaväärset registrit ei ole. Aadressid pöörlevad, paljud pakkujad ei avalda midagi ja tunnel võib töötada renditud pilveaadressil, mis ei kuulunud kunagi VPN-ile. Nimekiri, mille koostad, on vaadeldud aadresside hetktõmmis, ja selle laiendamine hostimisvahemikele lisab seostamata töökoormusi ilma tõestust lisamata.

Kasuta aadresse poliitika sisendina, mitte tõestusena

Otsusta, mille jaoks reegel on. Võrgupiirang peaks jääma kitsaks, salvestama vaadeldud aadressi koos kuupäeva ja põhjusega ning andma seaduslikele kasutajatele taastetee, kui nende väljund muutub. Juurdepääsukontroll vajab autenditud kontot või allkirjastatud tokenit, sest ainult need seovad päringu identiteediga. Riskihinnang võib kasutada aadressi ühe ebausaldusväärse signaalina, aktsepteerides selle valepositiivseid ja pimedaid kohti. Reegli kirjutamine tooteotsusena on aus; selle kirjutamine tõendina, et tunnel on olemas, ei ole.

Peegelpildis päring, kasutaja tegeliku aadressi taastamine VPN-i taga, ebaõnnestub samal põhjusel: üks ühendus kannab ühte aadressi ja muutus seansside vahel on kooskõlas mitme seletusega. Käsitle varasemat väärtust ajaloona, mitte tõena.