Dante SOCKS over VPN: full tunnel kontra kjeldebasert ruting
To måtar å senda berre SOCKS-proxyen gjennom ein tunnel: byta ut standardruta, eller knyta éin kjeldeadresse til si eiga tabell. Dei feilar på ulike måtar.
Du vil at trafikken til SOCKS-proxyen skal gå ut gjennom VPN-en medan resten av verten held fram på sin vanlege veg. To design gjer det, og dei skil seg i kva som brest når noko går gale. Det eine skyt ei standardrute inn i tunnelen og går så utanom henne; det andre lèt hovudtabellen vera og sender éi kjeldeadresse til ein andre tabell. Det andre er reinare, og det har sine eigne feller.
To design, to ulike skaderadiar
Designet med full tunnel er det dei fleste VPN-klientar gjer som standard: bytar ut standardruta slik at alt følgjer tunnelen, og stenger så ute det som ikkje skal følgja. Det er lett å tenkja gjennom og vanskeleg å halda trongt, fordi kvar lokal teneste du legg til arvar tunnelen til du stenger henne ute. Feilmodusen er brei, fordi éi feil rute tek med seg den eigne tilkoplinga til verten.
Designet med kjeldeval går den motsette vegen. Hovudtabellen blir ståande som han var, og éi politikkgrunnregel sender pakkar frå ei bestemd lokal adresse til ein tabell med ein tunnelstandard. Ingenting anna endrar seg, noko som tyder at skaderadien er éi adresse.
Denne trongda er òg avgrensinga: designet verkar berre dersom dei utgåande pakkane til proxyen verkeleg ber den adressa.
Kva Dantes external-innstilling gjer
External-innstillinga vel adressene som proxyen brukar for utgåande samband; ho rører ikkje rutingspolitikken til kjernen. Nettopp denne skilnaden gjer det andre designet mogleg, og her les folk dokumentasjonen feil. Å retta external mot ei tunneladresse gjer at proxyen startar sambanda sine frå den adressa, og rutetabellen avgjer så kvar pakkane går.
Lyttaren er ei eiga sak. Hald internal avgrensa til klientane som skal bruka proxyen, krev autentisering og steng porten med ein brannmur, fordi ein open lyttar ikkje er eit kjenneteikn ved VPN-utgang.
Stadfest at den konfigurerte adressa verkeleg høyrer til tunnelen inne i nettverksnamnerommet til proxyen.
Byggja tabellen med kjeldeval
For ei TUN-adresse på 10.90.0.2/24 med ein nåbar peer på 10.90.0.1, og eit tabellnummer som ingenting anna brukar, ser oppsettet slik ut:
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 100Den unåelege ruta er den delen folk hoppar over. Utan henne fell ein tabell der tunnelruta forsvinn tilbake til den vanlege standardruta, og proxyen går stille ut gjennom WAN-en. Med henne mislukkast oppslaget, noko som er ein synleg feil i staden for ein stille lekkasje. Prioritetet til regelen må òg stå framfor alt anna som passar med den kjelda.
Desse verdiane skildrar éin topologi. Punkt-til-punkt-peerar, net30-adressering og klientar som deler ut eit anna prefiks treng alle sine eigne ruter, så kopier forma, ikkje adressene.
Kvar kjeldegrunnregelen lek
Ein regel som passar med ei kjeldeadresse påverkar kvar prosess som brukar henne, ikkje berre proxyen. Viss ein annan daemon bind den same adressa, tek trafikken hans òg tunnelen, og feilen vil sjå ut som eit problem i ei teneste utan samanheng. Gje proxyen ei adresse som ingenting anna brukar, eller godta at omfanget er adressa og ikkje prosessen.
DNS er den andre lekkasjen. Ein resolver-sokkel brukar ikkje nødvendigvis external-datakjelda til proxyen, så namneoppslag kan framleis gå ut gjennom WAN-en. Test oppløysinga skilt frå opprettinga av sambandet, og avgjer om det resultatet er akseptabelt.
IPv6 treng sine eigne reglar og ruter, fordi eit IPv4-oppsett ikkje provar noko om det.
Vel etter feilen du kan tola
Vel den fulle tunnelen når verten skal vernast som heilskap og du kan halda ved like unntakslista. Vel kjeldebasert ruting når verten må halda sin eigen veg og berre éi teneste skal leidast om. Begge er legitime; feilen er å velja éin og så testa han som om han var den andre.
Kva du enn vel, stadfest frå båe sider: ein førespurnad gjennom proxyen og ein direkte førespurnad frå verten, med den observerte utgangsadressa registrert for kvar.
Viss tunnelen fell, avgjer på førehand om proxyen skal feila eller falla tilbake, og lat rutetabellen uttrykkja den avgjerda.