Dante SOCKS VPN-en át: teljes alagút vagy forrásalapú útválasztás

Szeretné, hogy a SOCKS proxy forgalma a VPN-en keresztül menjen ki, míg a gazdagép többi része megtartja a szokásos útvonalát. Két terv csinálja ezt, és abban különböznek, mi törik el, amikor valami rosszul sül el. Az egyik egy alapértelmezett útvonalat tol be az alagútba, majd megkerüli azt; a másik békén hagyja a fő táblát, és egyetlen forráscímet küld egy második táblába. A második tisztább, és megvannak a maga csapdái.

Két terv, két különböző kárrádiusz

A teljes alagút terve az, amit a legtöbb VPN-kliens alapértelmezésként tesz: lecseréli az alapértelmezett útvonalat, hogy minden az alagutat kövesse, majd kizárja azt, aminek nem kellene. Könnyű átgondolni és nehéz szűken tartani, mert minden hozzáadott helyi szolgáltatás örökli az alagutat, amíg ki nem zárja. A hiba módja széles, mert egyetlen rossz útvonal magával viszi a gazdagép saját kapcsolatát is.

A forrás szerinti kiválasztás terve az ellenkező irányba megy. A fő tábla úgy marad, ahogy volt, és egyetlen házirend-szabály egy adott helyi címről származó csomagokat küld egy alagút-alapértelmezést tartalmazó táblába. Semmi más nem változik, ami azt jelenti, hogy a kárrádiusz egyetlen cím.

Ez a szűkség egyben a korlát is: a terv csak akkor működik, ha a proxy kimenő csomagjai valóban hordozzák ezt a címet.

Mit tesz a Dante external beállítása

Az external beállítás azokat a címeket választja ki, amelyeket a proxy a kimenő kapcsolatokhoz használ; nem nyúl a kernel útválasztási házirendjéhez. Ez az elkülönítés teszi lehetővé a második tervet, és itt is értelmezik félre sokan a dokumentációt. Az external alagútcímre állítása azt eredményezi, hogy a proxy ebből a címből indítja kapcsolatait, és az útválasztási tábla dönti el, hová mennek ezek a csomagok.

A hallgató külön kérdés. Tartsa az internal-t azokra a kliensekre korlátozva, amelyeknek a proxyt használniuk kell, követeljen hitelesítést, és zárja le a portot tűzfallal, mert a nyitott hallgató nem a VPN-kimenet jellemzője.

Erősítse meg, hogy a beállított cím valóban az alagúthoz tartozik a proxy hálózati névterében.

A forrás szerint kiválasztott tábla felépítése

Egy 10.90.0.2/24 TUN-címhez, amelynek elérhető partnere 10.90.0.1, és egy olyan táblaszámhoz, amelyet semmi más nem használ, az elrendezés így néz ki:

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

Az elérhetetlen útvonal az a rész, amelyet az emberek kihagynak. Nélküle egy tábla, amelynek alagút-útvonala eltűnik, visszaesik a szokásos alapértelmezésre, és a proxy csendben a WAN felé távozik. Vele a keresés meghiúsul, ami látható hiba a csendes szivárgás helyett. A szabály prioritásának is minden más előtt kell állnia, ami erre a forrásra illeszkedik.

Ezek az értékek egyetlen topológiát írnak le. A pont-pont partnerek, a net30 címzés és a más előtagot kiosztó kliensek mind a saját útvonalaikat igénylik, ezért a formát másolja, ne a címeket.

Hol szivárog a forrásszabály

A forráscímre illeszkedő szabály minden folyamatra hat, amely használja, nem csak a proxyra. Ha egy másik démon ugyanazt a címet köti, a forgalma szintén az alagutat veszi, és a hiba egy nem kapcsolódó szolgáltatás problémájának tűnik. Adjon a proxynak olyan címet, amelyet semmi más nem használ, vagy fogadja el, hogy a hatókör a cím, nem a folyamat.

A DNS a másik szivárgás. A feloldó socket nem feltétlenül a proxy external adatkapcsolat-forrását használja, így a névkeresések még mindig kimehetnek a WAN felé. A feloldást a kapcsolat létrehozásától elkülönítve tesztelje, és döntse el, elfogadható-e ez az eredmény.

Az IPv6-nak saját szabályokra és útvonalakra van szüksége, mert az IPv4 elrendezése semmit nem bizonyít róla.

Az elviselhető hiba szerint válasszon

Akkor válassza a teljes alagutat, ha a gazdagépet egészében kell védeni, és fenn tudja tartani a kizárási listát. Akkor válassza a forrásalapú útválasztást, ha a gazdagépnek meg kell tartania a saját útvonalát, és csak egy szolgáltatást kell átirányítani. Mindkettő jogos; a hiba az, hogy az egyiket választja, majd úgy teszteli, mintha a másik lenne.

Bármelyiket választja, mindkét oldalról ellenőrizze: egy kérés a proxyn keresztül és egy közvetlen kérés a gazdagépről, mindegyiknél rögzítve a megfigyelt kilépési címet.

Ha az alagút elszakad, döntse el előre, hogy a proxynak hibáznia kell-e vagy vissza kell-e esnie, és hagyja, hogy az útválasztási tábla kifejezze ezt a döntést.