Dante SOCKS over VPN: fuld tunnel kontra kildebaseret routing

Du vil have SOCKS-proxyens trafik til at forlade gennem VPN’en, mens resten af værten beholder sin normale vej. To designs gør det, og de adskiller sig i, hvad der brækker, når noget går galt. Det ene skubber en standardrute ned i tunnelen og arbejder sig så udenom den; det andet lader hovedtabellen være og sender én kildeadresse til en anden tabel. Det andet er renere, og det har sine egne fælder.

To designs, to forskellige skadesradier

Designet med fuld tunnel er det, de fleste VPN-klienter gør som standard: erstat standardruten, så alt følger tunnelen, og udelukk så det, der ikke skal. Det er let at ræsonnere om og svært at holde snævert, fordi enhver lokal tjeneste, du tilføjer, arver tunnelen, indtil du udelukker den. Fejltilstanden er bred, fordi én forkert rute tager værtens egen forbindelse med sig.

Designet med kildeudvalg går den modsatte vej. Hovedtabellen forbliver som den var, og én politikregel sender pakker fra en bestemt lokal adresse til en tabel med en tunnelforbindelse som standard. Intet andet ændrer sig, hvilket betyder, at skadesradien er én adresse.

Den snæverhed er også begrænsningen: designet virker kun, hvis proxyens udgående pakker virkelig bærer den adresse.

Hvad Dantes external-indstilling gør

Indstillingen external vælger de adresser, som proxyen bruger til udgående forbindelser; den rører ikke kernens routingpolitik. Den adskillelse er det, der gør det andet design muligt, og det er også her, folk læser dokumentationen forkert. At pege external mod en tunneladresse får proxyen til at bruge den adresse som kilde for sine forbindelser, og routingtabellen afgør derefter, hvor de pakker havner.

Lytteren er en separat sag. Hold internal begrænset til de klienter, der bør bruge proxyen, kræv godkendelse, og firewall porten, fordi en åben lytter ikke er en egenskab ved VPN-udgang.

Bekræft, at den konfigurerede adresse faktisk tilhører tunnelen inde i proxyens netværksnavnerum.

Opbygning af tabellen med kildeudvalg

For en TUN-adresse på 10.90.0.2/24 med en nåbar peer på 10.90.0.1 og et tabelnummer, som intet andet bruger, ser opsætningen sådan ud:

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 uopnåelige rute er den del, folk springer over. Uden den falder en tabel, hvis tunnelrute forsvinder, tilbage til den almindelige standardrute, og proxyen forlader stille og roligt netværket via WAN’en. Med den fejler opslaget, hvilket er en synlig fejl i stedet for en lydløs lækage. Reglens prioritet skal også ligge foran alt andet, der matcher den kilde.

Disse værdier beskriver én topologi. Punkt-til-punkt-peers, net30-adressering og klienter, der uddeler et andet præfiks, har alle brug for deres egne ruter, så kopiér formen frem for adresserne.

Hvor kilde-reglen lækker

En regel, der matcher en kildeadresse, påvirker enhver proces, der bruger den, ikke kun proxyen. Hvis en anden dæmon binder den samme adresse, tager dens trafik også tunnelen, og fejlen vil se ud som et problem i en urelateret tjeneste. Giv proxyen en adresse, som intet andet bruger, eller accepter, at omfanget er adressen og ikke processen.

DNS er den anden lækage. En resolver-socket bruger ikke nødvendigvis proxyens external-kilde til dataforbindelser, så navneopslag kan stadig forlade via WAN’en. Test opløsning adskilt fra forbindelsesoprettelse, og beslut, om resultatet er acceptabelt.

IPv6 har brug for sine egne regler og ruter, fordi en IPv4-opsætning ikke beviser noget om det.

Vælg efter den fejl, du kan tåle

Vælg den fulde tunnel, når værten skal beskyttes som helhed, og du kan vedligeholde undtagelseslisten. Vælg kildebaseret routing, når værten skal beholde sin egen vej, og kun én tjeneste skal omdirigeres. Begge er legitime; fejlen er at vælge det ene og derefter teste det, som om det var det andet.

Uanset hvad du vælger, så verificér fra begge sider: en anmodning gennem proxyen og en direkte anmodning fra værten, med den observerede udgangsadresse registreret for hver.

Hvis tunnelen falder, så beslut på forhånd, om proxyen skal fejle eller falde tilbage, og lad routingtabellen udtrykke den beslutning.