Dante SOCKS VPN-i kaudu: täistunnel versus allikapõhine marsruutimine

Soovite, et SOCKS-puhverserveri liiklus väljuks VPN-i kaudu, samal ajal kui ülejäänud host säilitab oma tavapärase tee. Kaks lahendust teevad seda ja need erinevad selle poolest, mis katki läheb, kui midagi valesti läheb. Üks surub vaikimisi marsruudi tunnelisse ja seejärel läheb sellest mööda; teine jätab põhitabeli puutumata ja saadab ühe lähteaadressi teise tabelisse. Teine on puhtam ja sellel on omad lõksud.

Kaks lahendust, kaks erinevat kahjuraadiust

Täistunneli lahendus on see, mida enamik VPN-kliente vaikimisi teeb: asendab vaikimisi marsruudi, et kõik järgiks tunnelit, ja jätab seejärel välja selle, mis ei peaks järgima. Seda on lihtne mõista ja raske kitsana hoida, sest iga kohalik teenus, mille lisate, pärineb tunneli, kuni te selle välja jätate. Tõrkerežiim on lai, sest üks vale marsruut viib kaasa hosti enda ühenduvuse.

Allika järgi valitud lahendus läheb vastupidises suunas. Põhitabel jääb nii, nagu oli, ja üks reegel saadab paketid kindlalt kohalikult aadressilt tabelisse, millel on tunneli vaikimisi marsruut. Miski muu ei muutu, mis tähendab, et kahjuraadius on üks aadress.

See kitsus on ühtlasi piirang: lahendus töötab ainult siis, kui puhverserveri väljuvad paketid tõesti seda aadressi kannavad.

Mida teeb Dante external-seade

Seade external valib aadressid, mida puhverserver väljuvate ühenduste jaoks kasutab; see ei puuduta kerneli marsruutimispoliitikat. Just see eraldatus teeb teise lahenduse võimalikuks ja täpselt siin loevad inimesed dokumentatsiooni valesti. External-i suunamine tunneli aadressile paneb puhverserveri oma ühendusi sellelt aadressilt lähtestama, ja seejärel otsustab marsruutimistabel, kuhu need paketid lähevad.

Kuulaja on eraldi teema. Hoidke internal piiratud klientidega, kes peaksid puhverserverit kasutama, nõudke autentimist ja sulgege port tulemüüriga, sest avatud kuulaja ei ole VPN-i väljumise omadus.

Kinnitage, et seadistatud aadress kuulub tõesti tunnelile puhverserveri võrgu nimeruumis.

Allika järgi valitud tabeli ehitamine

TUN-aadressi 10.90.0.2/24 ja kättesaadava peer-i 10.90.0.1 korral ning tabelinumbri puhul, mida miski muu ei kasuta, näeb paigutus välja selline:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

Kättesaamatu marsruut on osa, mille inimesed vahele jätavad. Ilma selleta langeb tabel, mille tunnelimarsruut kaob, tavalisele vaikimisi marsruudile ja puhverserver väljub vaikselt WAN-i kaudu. Sellega ebaõnnestub otsing, mis on nähtav tõrge vaikse lekke asemel. Reegli prioriteet peab samuti olema kõige muu ees, mis selle allikaga sobib.

Need väärtused kirjeldavad üht topoloogiat. Punkt-punkti peer-id, net30 adresseerimine ja kliendid, kes jagavad teistsugust prefiksit, vajavad kõik oma marsruute, seega kopeerige kuju, mitte aadresse.

Kus allikareegel lekkib

Lähteaadressiga sobiv reegel mõjutab iga protsessi, mis seda kasutab, mitte ainult puhverserverit. Kui mõni teine deemon seob sama aadressi, võtab ka selle liiklus tunneli, ja tõrge näeb välja nagu seotamata teenuse probleem. Andke puhverserverile aadress, mida miski muu ei kasuta, või leppige sellega, et ulatus on aadress, mitte protsess.

DNS on teine leke. Resolveri socket ei pruugi kasutada puhverserveri external-andmeühenduse allikat, seega nimeotsingud võivad ikka WAN-i kaudu väljuda. Testige lahendamist ühenduse loomisest eraldi ja otsustage, kas see tulemus on vastuvõetav.

IPv6 vajab oma reegleid ja marsruute, sest IPv4 paigutus ei tõesta selle kohta midagi.

Valige selle järgi, millist tõrget talute

Valige täistunnel, kui hosti tuleb kaitsta tervikuna ja saate välistuste nimekirja pidada. Valige allikapõhine marsruutimine, kui host peab säilitama oma tee ja ümber tuleb suunata ainult üks teenus. Mõlemad on õiguspärased; viga on valida üks ja testida seda siis nii, nagu oleks see teine.

Ükskõik kumma valite, kontrollige mõlemalt poolt: päring puhverserveri kaudu ja otsene päring hostist, kummagi puhul vaadeldud väljumisaadress kirja pandud.

Kui tunnel kukub, otsustage ette, kas puhverserver peaks alt vedama või tagasi pöörduma, ja laske marsruutimistabelil see otsus väljendada.