Dante SOCKS oer in VPN: folsleine tunnel fersus boarne-routing

Jo wolle dat it ferkear fan de SOCKS-proxy troch it VPN giet, wylst de rest fan 'e host syn normale paad hâldt. Twa ûntwerpen dogge dat, en se ferskille yn wat der brekt as der wat misgiet. Ien skoot in standertrûte yn 'e tunnel en giet der dan omhinne; de oare lit de haadtabel gewurde en stjoert ien boarnegadres nei in twadde tabel. De twadde is skjinner, en hy hat syn eigen fallen.

Twa ûntwerpen, twa ferskillende skeaderadia

It ûntwerp fan 'e folsleine tunnel is wat de measte VPN-klanten standert dogge: de standertrûte ferfange sadat alles de tunnel folget, en dan útslute wat dat net moat. It is maklik om oer te riddenearjen en dreech om smel te hâlden, want elke lokale tsjinst dy't jo tafoegje erft de tunnel oant jo dy útslute. De flatermodus is breed, want ien ferkearde rûte nimt de eigen ferbining fan 'e host mei.

It ûntwerp mei boarnekarre giet de oare kant út. De haadtabel bliuwt sa't er wie, en ien beliedsregel stjoert pakketten fan in bepaald lokaal adres nei in tabel mei in tunnelstandert. Neat oars feroaret, wat betsjut dat it skeaderadius ien adres is.

Dy smelte is ek de beheining: it ûntwerp wurket allinnich as de útgeande pakketten fan 'e proxy echt dat adres drage.

Wat de external-ynstelling fan Dante docht

De external-ynstelling kiest de adressen dy't de proxy brûkt foar útgeande ferbiningen; hy rekket it routingbelied fan 'e kearn net oan. Krekt dy skieding makket it twadde ûntwerp mooglik, en dêr lêze minsken de dokumintaasje ferkeard. External nei in tunneladres rjochtsje lit de proxy syn ferbiningen fan dat adres ôf komme, en de routingtabel beslút dan wêr't dy pakketten hinne geane.

De listener is in aparte saak. Hâld internal beheind ta de klanten dy't de proxy brûke moatte, freegje om autentikaasje en smyt de poarte ticht mei in firewall, want in iepen listener is gjin eigenskip fan VPN-útgong.

Befêstigje dat it konfigurearre adres echt by de tunnel heart yn 'e netwurknammeromte fan 'e proxy.

De tabel mei boarnekarre bouwe

Foar in TUN-adres fan 10.90.0.2/24 mei in berikbere peer op 10.90.0.1, en in tabelnûmer dat neat oars brûkt, sjocht de opstelling der sa út:

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

De ûnberikbere rûte is it part dat minsken oerslaan. Sûnder dy falt in tabel waans tunnelrûte ferdwynt werom op 'e gewoane standert en giet de proxy stilwei fuort troch it WAN. Mei dy mislearret it sykjen, wat in sichtbere flater is ynstee fan in stille lek. De prioriteit fan 'e regel moat ek foar alles stean wat by dy boarne past.

Dizze wearden beskriuwe ien topology. Punt-nei-punt-peers, net30-adressaasje en klanten dy't in oar prefiks jouwe, hawwe allegear har eigen rûtes nedich, dus kopiearje de foarm, net de adressen.

Wêr't de boarneregel lekt

In regel dy't by in boarnegadres past, rekket elk proses dat it brûkt, net allinnich de proxy. As in oare daemon itselde adres bûn hat, nimt syn ferkear ek de tunnel, en de flater sil der as in net besibbe tsjinstprobleem útsjen. Jou de proxy in adres dat neat oars brûkt, of akseptearje dat it berik it adres is en net it proses.

DNS is de oare lek. In resolver-socket brûkt net needsaaklikerwize de external-databoarne fan 'e proxy, dus nammsykjen kin noch altyd troch it WAN fuortgean. Test de oplossing apart fan it opbouwen fan 'e ferbining, en beslút oft dat resultaat akseptabel is.

IPv6 hat syn eigen regels en rûtes nedich, want in IPv4-opstelling bewiist neat oer it.

Kies by de flater dy't jo ferneare kinne

Kies de folsleine tunnel as de host as gehiel beskerme wurde moat en jo de útslutingslist byhâlde kinne. Kies boarne-basearre routing as de host syn eigen paad hâlde moat en allinnich ien tsjinst omlein wurde moat. Beide binne legitime; de flater is ien kieze en dy dan testen as wie it de oare.

Hokker jo ek kieze, ferifiearje fan beide kanten: in fersyk troch de proxy en in direkt fersyk fan 'e host, mei it waarnommen útgeande adres foar elk fêstlein.

As de tunnel falt, beslút dan foarôf oft de proxy mislearje moat of weromfalle, en lit de routingtabel dat beslút útdrukke.