Dante SOCKS over VPN: full tunnel kontra kildebasert ruting

Du vil at trafikken til SOCKS-proxyen skal gå ut gjennom VPN-en mens resten av verten beholder sin vanlige vei. To design gjør det, og de skiller seg i hva som bryter sammen når noe går galt. Det ene skyver en standardrute inn i tunnelen og går så utenom den; det andre lar hovedtabellen være og sender én kildeadresse til en andre tabell. Det andre er renere, og det har sine egne feller.

To design, to ulike skaderadier

Designet med full tunnel er det de fleste VPN-klienter gjør som standard: erstatter standardruten slik at alt følger tunnelen, og stenger så ute det som ikke skal følge. Det er lett å tenke gjennom og vanskelig å holde smalt, fordi hver lokale tjeneste du legger til arver tunnelen til du stenger den ute. Feilmodusen er bred, fordi én feil rute tar med seg vertens egen tilkobling.

Designet med kildevalg går motsatt vei. Hovedtabellen blir stående som den var, og én policyregel sender pakker fra en bestemt lokal adresse til en tabell med en tunnelstandard. Ingenting annet endres, noe som betyr at skaderadien er én adresse.

Denne smalheten er også begrensningen: designet virker bare dersom de utgående pakkene til proxyen virkelig bærer den adressen.

Hva Dantes external-innstilling gjør

External-innstillingen velger adressene som proxyen bruker for utgående forbindelser; den rører ikke rutingspolitikken til kjernen. Nettopp denne delingen gjør det andre designet mulig, og her leser folk dokumentasjonen feil. Å rette external mot en tunneladresse gjør at proxyen starter forbindelsene sine fra den adressen, og rutetabellen avgjør så hvor pakkene går.

Lytteren er en egen sak. Hold internal begrenset til klientene som skal bruke proxyen, krev autentisering og steng porten med en brannmur, fordi en åpen lytter ikke er et kjennetegn ved VPN-utgang.

Bekreft at den konfigurerte adressen virkelig hører til tunnelen inne i nettverksnavnerommet til proxyen.

Bygge tabellen med kildevalg

For en TUN-adresse på 10.90.0.2/24 med en nåbar peer på 10.90.0.1, og et tabellnummer som ingenting annet bruker, 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 100

Den unåelige ruten er den delen folk hopper over. Uten den faller en tabell der tunnelruten forsvinner tilbake til den vanlige standardruten, og proxyen går stille ut gjennom WAN-en. Med den mislykkes oppslaget, noe som er en synlig feil i stedet for en stille lekkasje. Prioriteten til regelen må også stå foran alt annet som passer med den kilden.

Disse verdiene beskriver én topologi. Punkt-til-punkt-peere, net30-adressering og klienter som deler ut et annet prefiks trenger alle sine egne ruter, så kopier formen, ikke adressene.

Hvor kilderegelen lekker

En regel som passer med en kildeadresse påvirker hver prosess som bruker den, ikke bare proxyen. Hvis en annen daemon binder den samme adressen, tar trafikken dens også tunnelen, og feilen vil se ut som et problem i en urelatert tjeneste. Gi proxyen en adresse som ingenting annet bruker, eller godta at omfanget er adressen og ikke prosessen.

DNS er den andre lekkasjen. En resolver-sokkel bruker ikke nødvendigvis external-datakilden til proxyen, så navneoppslag kan fortsatt gå ut gjennom WAN-en. Test oppslaget atskilt fra opprettelsen av forbindelsen, og avgjør om det resultatet er akseptabelt.

IPv6 trenger sine egne regler og ruter, fordi et IPv4-oppsett ikke beviser noe om det.

Velg etter feilen du kan tåle

Velg den fulle tunnelen når verten skal beskyttes som helhet og du kan vedlikeholde unntakslisten. Velg kildebasert ruting når verten må beholde sin egen vei og bare én tjeneste skal omdirigeres. Begge er legitime; feilen er å velge én og så teste den som om den var den andre.

Uansett hva du velger, verifiser fra begge sider: en forespørsel gjennom proxyen og en direkte forespørsel fra verten, med den observerte utgangsadressen registrert for hver.

Hvis tunnelen faller, avgjør på forhånd om proxyen skal feile eller falle tilbake, og la rutetabellen uttrykke den avgjørelsen.