Side-nei-side tsjin fjirde tagong fia VPN: wat de twa ferbynt
Ien ferbynt gateways, de oare ferbynt apparaten. Fergelykje ferkiersselekteurs mei rûtes, plan de adressering en test dan trochstjoering en belied fanôf in echte host.
Beide ûntwerpen hjitte in VPN en se lossen ferskillende problemen op. In side-nei-side-tunnel ferbynt twa gateways, sadat elke host dêr’t efter sit tagong krijt ta tastiene adressen oan ’e oare kant sûnder eat te ynstallearjen. In fjirde-tagong-tunnel ferbynt yndividuele apparaten oan in netwurk, ien kliïnt tagelyk. De fergeliking is wichtich, want de measte útrôlfouten komme derfan dat men it iene ûntwerp konfigurearret wylst men it gedrach fan it oare ferwachtet, en it symptoom is meastentiids in tiidferrin op in tsjinst dy’t de tunnel wol berikt hat.
Twa ûntwerpen, twa grinzen
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Gjin fan beide ûntwerpen wreidet in LAN-útstjoerdomein út. Apparaten oan ’e oare kant ferskine net yn in pleatslike ûntdekkingslist, en ferwachtsje dat se dat wol dogge is de earste oanname dy’t men loslitte moat. Partikuliere DNS-nammen dy’t jo bewust publisearje binne better te foarsizzen as hokker ûntdekkingsprotokol dan ek, en se oerlibje in feroaring fan leveransier.
Nim 10.10.0.0/24 op it iene plak en 10.20.0.0/24 op it oare. Gateway A hat in rûte of in ferkiersselekteur nedich dy’t it foarheaksel 10.20.0.0/24 de tunnel yn stjoert, en gateway B hat it spegelbyld dêrfan nedich. Hosts oan beide kanten brûke dan gewoane IP-ferbining en leare nea dat der in tunnel bestiet. Dy ûnsichtberens is de funksje, en dêrom lykje flaters as gewoane netwurkflaters ynstee fan tunnelflaters.
Beliedsbasearre en rûtebasearre binne net deselde tunnel
Yn in beliedsbasearre IPsec-útrôl definiearje de ûnderhannele ferkiersselekteurs krekt hokker boarne- en bestimmingspearen beskerme wurde. As der efter ien gateway in nij subnet ferskynt en gjin selekteur it beslacht, bliuwt de tunnel oan en it nije subnet wurdt gewoan net droegen. Yn in rûtebasearre ûntwerp ûntfangt in ynterface it ferkier en beslút de rûtetabel, wat it tafoegjen fan in foarheaksel in rûteferoaring makket ynstee fan in nije tunnelûnderhanneling.
StrongSwan lit beide sichten direkt sjen, en se tegearre lêze is de manier om te achterheljen hokker model jo eins útrôle hawwe.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'In selekteurslist dy’t it foarheaksel dat jo nedich hawwe weilitten hat, ferklearret de flater sûnder hokker pakketfangst dan ek, en in rûte dy’t nei de ferkearde ynterface wiist ferklearret de spegelbyldflater op ’e weromweis. Lês beide foardat jo eat op ’e nij ûnderhannelje, want in kaaifernijing foeget gjin selekteur ta dy’t jo nea konfigurearre hawwe.
Plan de adressering foar de tunnel
Oerlaapjende berikken binne de ûntwerpfout dy’t net mei konfiguraasje reparearre wurde kin. As beide plakken 192.168.1.0/24 brûke, hat in host dy’t 192.168.1.50 nedich hat twa kandidaten en gjin manier om te kiezen. De tunnel sil autentisearje, de befeiligingsassosjaasjes sille ta stân komme, en de rûtebeslissing sil likegoed ferkeard of dûbelsinnich wêze.
Kies ien fan trije earlike opsjes: nûmerje ien plak op ’e nij, fertaal it oerlaapjende berik by de gateway sadat elke kant in apart foarheaksel sjocht, of jou it direkt rûtsjen foar dy hosts op en publisearje de tsjinst op in oare manier. Elk hat in priis, en de earste is meastentiids de goedkeapste oer in twajierrich horizon. Beslis foardat de tunnel bestiet, want efterôf rekket de feroaring elk apparaat dat it âlde adres hat.
Los ek de MTU-kwestje betiid op. In tunnel ferminderet de brûkbere lading, en in ûntwerp dat op fragmintaasje fertrout, docht him oars as ien dat de MSS by de gateways fêstset.
Trochstjoering en belied sitte bûten de tunnel
De gateway moat ree wêze om pakketten tusken de tunnel-ynterface en de LAN-ynterface troch te stjoeren, en beide rjochtingen hawwe belied nedich dat de tsjinst tastiet. Op Linux binne dat twa aparte ynstellings, plus de firewallregels dy’t beslute oft de trochstjoerde stream oait tastien is.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTDe ûntfangende host foeget in tredde laach ta: syn eigen firewall moat noch altyd in kliïnt fan it fjirde subnet akseptearje. In bestânssever dat allinnich syn pleatslike /24 tastiet, sil trochstjoerd ferkier fan 10.20.0.7 wegerje, hoe sûn de tunnel ek liket, en dy wegering wurdt maklik as in rûteflater lêzen.
Test fanôf in host, net fanôf de gateway
In ping dy’t troch de gateway sels stjoerd wurdt, kin in oar boarneadres en in oar belied folgje as trochstjoerd brûkersferkier. Dat makket it in swakke test en soms in misliedende: hy slagget wylst de applikaasje mislearret, of mislearret wylst de applikaasje wurket.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullBrûk in echte host, in echt boarneadres en it echte protokol dat de applikaasje brûkt. Lês dan de weromwei apart, want in wurkjende foarútweis sûnder weromrûte jout in tiidferrin dat der identyk útsjocht as in blokkearre tsjinst.
Kies it ûntwerp by de fraach dy’t jo beantwurdzje: ferbine jo netwurken of litte jo apparaten ta? Al it oare, ek hokker leveransier jo konfigurearje, folget út dat antwurd.