Dante SOCKS över VPN: full tunnel kontra källbaserad routning

Du vill att SOCKS-proxyns trafik ska gå ut genom VPN:en medan resten av värden behåller sin vanliga väg. Två konstruktioner gör det, och de skiljer sig i vad som går sönder när något går fel. Den ena trycker in en standardrutt i tunneln och går sedan runt den; den andra lämnar huvudtabellen ifred och skickar en enda källadress till en andra tabell. Den andra är renare, och den har sina egna fällor.

Två konstruktioner, två olika skaderadier

Konstruktionen med full tunnel är vad de flesta VPN-klienter gör som standard: ersätter standardrutten så att allt följer tunneln och utesluter sedan det som inte ska följa med. Det är lätt att resonera kring och svårt att hålla smalt, eftersom varje lokal tjänst du lägger till ärver tunneln tills du utesluter den. Felläget är brett, eftersom en enda felaktig rutt tar med sig värdens egen anslutning.

Konstruktionen med källval går åt andra hållet. Huvudtabellen förblir som den var, och en enda policyregel skickar paket från en bestämd lokal adress till en tabell med en tunnelstandard. Inget annat ändras, vilket betyder att skaderadien är en adress.

Den smalheten är också begränsningen: konstruktionen fungerar bara om proxyns utgående paket verkligen bär den adressen.

Vad Dantes external-inställning gör

External-inställningen väljer de adresser som proxyn använder för utgående anslutningar; den rör inte kernens routningspolicy. Just den separationen gör den andra konstruktionen möjlig, och det är här folk läser dokumentationen fel. Att peka external mot en tunneladress får proxyn att utgå från den adressen i sina anslutningar, och routningstabellen avgör sedan vart paketen tar vägen.

Lyssnaren är en separat fråga. Håll internal begränsad till de klienter som ska använda proxyn, kräv autentisering och stäng porten med en brandvägg, eftersom en öppen lyssnare inte är en egenskap hos en VPN-utgång.

Bekräfta att den konfigurerade adressen verkligen tillhör tunneln i proxyns nätverksnamnrymd.

Bygga tabellen med källval

För en TUN-adress på 10.90.0.2/24 med en nåbar peer på 10.90.0.1, och ett tabellnummer som inget annat använder, ser upplägget ut så här:

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 oåtkomliga rutten är den del folk hoppar över. Utan den faller en tabell vars tunnelrutt försvinner tillbaka på den vanliga standardrutten och proxyn lämnar nätet tyst via WAN. Med den misslyckas uppslaget, vilket är ett synligt fel i stället för ett tyst läckage. Regelns prioritet måste också ligga före allt annat som matchar den källan.

Dessa värden beskriver en topologi. Punkt-till-punkt-peers, net30-adressering och klienter som delar ut ett annat prefix behöver alla egna rutter, så kopiera formen, inte adresserna.

Var källregeln läcker

En regel som matchar en källadress påverkar varje process som använder den, inte bara proxyn. Om en annan daemon binder samma adress tar även dess trafik tunneln, och felet kommer att se ut som ett problem i en orelaterad tjänst. Ge proxyn en adress som inget annat använder, eller acceptera att omfånget är adressen och inte processen.

DNS är det andra läckaget. En resolver-socket använder inte nödvändigtvis proxyns external-datakälla, så namnuppslag kan fortfarande gå ut via WAN. Testa uppslagningen separat från anslutningsuppbyggnaden och avgör om resultatet är acceptabelt.

IPv6 behöver egna regler och rutter, eftersom ett IPv4-upplägg inte bevisar något om det.

Välj efter det fel du kan tolerera

Välj den fulla tunneln när värden ska skyddas som helhet och du kan underhålla undantagslistan. Välj källbaserad routning när värden måste behålla sin egen väg och bara en tjänst ska omdirigeras. Båda är legitima; felet är att välja den ena och sedan testa den som om den vore den andra.

Vilket du än väljer, verifiera från båda hållen: en begäran genom proxyn och en direkt begäran från värden, med den observerade utgående adressen registrerad för varje.

Om tunneln faller, avgör i förväg om proxyn ska misslyckas eller falla tillbaka, och låt routningstabellen uttrycka det beslutet.