Dante SOCKS via VPN: volledige tunnel versus bronroutering

U wilt dat het verkeer van de SOCKS-proxy via de VPN naar buiten gaat terwijl de rest van de host zijn normale pad houdt. Twee ontwerpen doen dat, en ze verschillen in wat er breekt als er iets misgaat. Het ene duwt een standaardroute de tunnel in en gaat er dan omheen; het andere laat de hoofdtabel met rust en stuurt één bronadres naar een tweede tabel. Het tweede is schoner, en het heeft zijn eigen valkuilen.

Twee ontwerpen, twee verschillende schaderadii

Het volledige-tunnelontwerp is wat de meeste VPN-clients standaard doen: de standaardroute vervangen zodat alles de tunnel volgt, en dan uitsluiten wat niet mee mag. Het is makkelijk te beredeneren en moeilijk smal te houden, omdat elke lokale dienst die u toevoegt de tunnel erft tot u hem uitsluit. De faalmodus is breed, want één verkeerde route neemt de eigen connectiviteit van de host mee.

Het ontwerp met bronselectie gaat de andere kant op. De hoofdtabel blijft zoals hij was, en één beleidsregel stuurt pakketten van een bepaald lokaal adres naar een tabel met een tunnelstandaard. Niets anders verandert, wat betekent dat de schaderadius één adres is.

Die smalheid is ook de beperking: het ontwerp werkt alleen als de uitgaande pakketten van de proxy dat adres echt dragen.

Wat Dantes external-instelling doet

De external-instelling kiest de adressen die de proxy voor uitgaande verbindingen gebruikt; hij raakt het routeringsbeleid van de kernel niet aan. Die scheiding maakt het tweede ontwerp mogelijk, en dit is ook waar mensen de documentatie verkeerd lezen. external op een tunneladres richten zorgt dat de proxy zijn verbindingen vanaf dat adres opzet, en de routeringstabel bepaalt vervolgens waar die pakketten heen gaan.

De listener is een aparte zaak. Houd internal beperkt tot de clients die de proxy zouden moeten gebruiken, eis authenticatie en sluit de poort met een firewall, want een open listener is geen kenmerk van een VPN-uitgang.

Bevestig dat het geconfigureerde adres werkelijk bij de tunnel hoort binnen de netwerknaamruimte van de proxy.

De tabel met bronselectie opbouwen

Voor een TUN-adres van 10.90.0.2/24 met een bereikbare peer op 10.90.0.1, en een tabelnummer dat niets anders gebruikt, ziet de opzet er zo uit:

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 onbereikbare route is het deel dat mensen overslaan. Zonder die route valt een tabel waarvan de tunnelroute verdwijnt terug op de gewone standaard en verlaat de proxy stil het netwerk via de WAN. Met die route mislukt de opzoeking, wat een zichtbare fout is in plaats van een stille lekkage. De prioriteit van de regel moet ook vóór alles staan wat op die bron past.

Deze waarden beschrijven één topologie. Point-to-point-peers, net30-adressering en clients die een ander prefix uitdelen hebben allemaal hun eigen routes nodig, dus kopieer de vorm, niet de adressen.

Waar de bronregel lekt

Een regel die op een bronadres past, beïnvloedt elk proces dat het gebruikt, niet alleen de proxy. Als een andere daemon hetzelfde adres bindt, neemt zijn verkeer ook de tunnel, en de fout zal op een probleem van een ongerelateerde dienst lijken. Geef de proxy een adres dat niets anders gebruikt, of accepteer dat het bereik het adres is en niet het proces.

DNS is de andere lekkage. Een resolver-socket gebruikt niet noodzakelijk de external-databron van de proxy, dus naamopzoekingen kunnen nog steeds via de WAN naar buiten gaan. Test de resolutie apart van het opzetten van de verbinding, en beslis of die uitkomst aanvaardbaar is.

IPv6 heeft zijn eigen regels en routes nodig, want een IPv4-opzet bewijst er niets over.

Kies op basis van de fout die u kunt verdragen

Kies de volledige tunnel wanneer de host als geheel beschermd moet worden en u de uitsluitingslijst kunt onderhouden. Kies bronroutering wanneer de host zijn eigen pad moet houden en alleen één dienst omgeleid moet worden. Beide zijn legitiem; de fout is er één kiezen en het dan testen alsof het de ander is.

Welke u ook kiest, verifieer van beide kanten: een verzoek via de proxy en een rechtstreeks verzoek vanaf de host, met het waargenomen uitgangsadres voor elk genoteerd.

Als de tunnel wegvalt, beslis dan vooraf of de proxy moet falen of moet terugvallen, en laat de routeringstabel die beslissing uitdrukken.