Dante SOCKS oor 'n VPN: volle tonnel teenoor bronroetering

Jy wil hê die SOCKS-proxy se verkeer moet deur die VPN verlaat terwyl die res van die gasheer sy normale pad behou. Twee ontwerpe doen dit, en hulle verskil in wat breek wanneer iets verkeerd loop. Een druk 'n verstekroete in die tonnel in en werk dan daaromheen; die ander laat die hoofraat alleen en stuur 'n enkele bronadres na 'n tweede tabel. Die tweede is skoner, en dit het sy eie strikke.

Twee ontwerpe, twee verskillende omvange van skade

Die volle-tonnel-ontwerp is wat die meeste VPN-kliënte by verstek doen: vervang die verstekroete sodat alles die tonnel volg, en sluit dan uit wat nie moet nie. Dit is maklik om te beredeneer en moeilik om smal te hou, want elke plaaslike diens wat jy byvoeg, erf die tonnel totdat jy dit uitsluit. Die foutmodus is breed, want een verkeerde roete neem die gasheer se eie verbinding saam.

Die bron-gekose ontwerp gaan die ander kant toe. Die hoofraat bly soos dit was, en een beleidsreël stuur pakkette vanaf 'n spesifieke plaaslike adres na 'n tabel met 'n tonnel-verstek. Niks anders verander nie, wat beteken die skadeomvang is een adres.

Daardie smalheid is ook die beperking: die ontwerp werk net as die proxy se uitgaande pakkette werklik daardie adres dra.

Wat Dante se external-instelling doen

Die external-instelling kies die adresse wat die proxy vir uitgaande verbindings gebruik; dit raak nie die kern se roeteringsbeleid nie. Daardie skeiding is wat die tweede ontwerp moontlik maak, en dit is ook waar mense die dokumentasie verkeerd lees. Om external na 'n tonneladres te wys, maak dat die proxy sy verbindings vanaf daardie adres bron, en die roetertabel besluit dan waar daardie pakkette heen gaan.

Die luisteraar is 'n aparte saak. Hou internal beperk tot die kliënte wat die proxy moet gebruik, vereis verifikasie, en firewall die poort, want 'n oop luisteraar is nie 'n kenmerk van VPN-uitgang nie.

Bevestig dat die gekonfigureerde adres werklik aan die tonnel behoort binne die proxy se netwerknaamruimte.

Bou die bron-gekose tabel

Vir 'n TUN-adres van 10.90.0.2/24 met 'n bereikbare eweknie by 10.90.0.1, en 'n tabelnommer wat niks anders gebruik nie, lyk die reëling so:

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

Die onbereikbare roete is die deel wat mense oorslaan. Sonder dit val 'n tabel wie se tonnelroete verdwyn terug na die gewone verstek, en die proxy verlaat stilweg via die WAN. Met dit misluk die opsoek, wat 'n sigbare fout is eerder as 'n stil lekkasie. Die reël se prioriteit moet ook voor enigiets anders staan wat daardie bron pas.

Hierdie waardes beskryf een topologie. Punt-tot-punt-eweknieë, net30-adressering en kliënte wat 'n ander voorvoegsel uitdeel, het elkeen hul eie roetes nodig, so kopieer die vorm eerder as die adresse.

Waar die bronreël lek

'n Reël wat 'n bronadres pas, raak elke proses wat dit gebruik, nie net die proxy nie. As 'n ander daemon dieselfde adres bind, neem sy verkeer ook die tonnel, en die fout sal soos 'n onverwante diensprobleem lyk. Gee die proxy 'n adres wat niks anders gebruik nie, of aanvaar dat die omvang die adres is eerder as die proses.

DNS is die ander lekkasie. 'n Resolver-sokkie gebruik nie noodwendig die proxy se external-bron vir dataverbindings nie, so naamopsoeke kan steeds via die WAN uitgaan. Toets oplossing apart van verbindingstigting, en besluit of daardie uitkoms aanvaarbaar is.

IPv6 het sy eie reëls en roetes nodig, want 'n IPv4-reëling bewys niks daaroor nie.

Kies volgens die fout wat jy kan verdra

Kies die volle tonnel wanneer die gasheer as geheel beskerm moet word en jy die uitsluitingslys kan onderhou. Kies bron-gebaseerde roetering wanneer die gasheer sy eie pad moet behou en net een diens herlei moet word. Beide is geldig; die fout is om een te kies en dit dan te toets asof dit die ander een is.

Watter een jy ook kies, verifieer van beide kante: 'n versoek deur die proxy en 'n direkte versoek vanaf die gasheer, met die waargenome uitgangsadres vir elkeen aangeteken.

As die tonnel val, besluit vooraf of die proxy moet faal of terugval, en laat die roetertabel daardie besluit uitdruk.