In app bûn oan it adres fan it VPN, en de ferbining giet dochs oer de gewoane standertrûte fuort. Der is neat yn de bining mislearre; it die krekt wat in bining docht. In socket oan in lokaal adres bine kiest it boarne-adres dat de kernel yn de kop set. It ynstallearret gjin rûte en it makket gjin beliedsregel dy't pakketten mei dy boarne yn in bepaald tunnel stjoert.

De rest fan dit hânboek is de kontrôlefolchoarder dy't ik brûk, tegearre mei it kommando dat elke observaasje leveret.

Wat in bining eins beslút

In bining jout in lokaal adres oan de socket. Dêrnei docht de kernel deselde rûtesyktocht dy't er oars dien hie, behalve as in beliedsregel feroaret hokker tabel dy syktocht lêst.

Dêrom kin in pakket mei in VPN-boarne-adres op in fysike ynterface fuortgean. Oan de oare kant komt it fan in privee berik dat it netwurk nea op dy wei ferwachte hie, it weromferkear hat gjin rûte werom, en de ferbining hinget of wurdt weromset.

De Linux IP-socketreferinsje dokumintearret de semantyk fan bining. De rûtingshelte wennet yn ip-rule en ip-route, en dat binne om in reden aparte hânboeken.

Befêstigje dat it adres by dit nammeromte heart

In adres dêr't jo oan bine kinne, moat bestean op in ynterface binnen it netwurknammeromte dêr't de app yn rint. In peer-adres, in gateway-adres of in adres dat allinnich yn in oar nammeromte bestiet, is net te binen, en de oprop mislearret mei EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Rin dy trije yn deselde kontekst as de app: itselde nammeromte, en deselde brûker as jo dy krije kinne. In âld net30-diagram is gjin bewiis fan hokker adres jo hjoeddeistige topology oan de klant tawiisd hat. Lês de ynterface dy't echt oan is.

Lês de syktocht foar dy boarne en bestimming

Ien kommando beantwurdet de fraach dy't de bining net beantwurde:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

De earste rigel prints de rûte dy't in pakket fan dy boarne nei dy bestimming nimme soe, ynklusyf de útgeande ynterface en de foarkarde boarne. As er de fysike ynterface neamt, binne de bining en de rûte it net iens, en it pakket giet fuort mei in boarne dêr't de wei net werom kin.

Dêrnei fertelt ip rule show jo oft in regel in oare tabel keazen hie. Prioriteiten telle hjir, want de earste passende regel wint, en in regel dy't alles boppe dyn regel fangt makket dyn regel ûnsichtber.

Ynstallearje in beliedsregel allinnich as dat it ûntwerp is

Boarne-basearre routing is in bewust ûntwerp, gjin repaaraasje foar ien app. As de beliedeigner wol dat ferkear fan it tunnelsubnet it tunnel brûkt, heart de regel yn syn konfiguraasje en net yn in ienmalige kommando op jo laptop.

In wurkbere foarm is in aparte tabel mei in standertrûte troch it tunnel, plus in regel dy't it VPN-boarneberik yn dy tabel stjoert. Foegje de útsûnderings ta dy't it ûntwerp nedich hat, want in tabel mei allinnich in tunnelstandert fangt bestimmingen dy't lokaal bliuwe moatte of oer it fysike paad berikber wêze moatte.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Draai werom mei ip rule del en ip route flush table 100. Alles wat sa tafoege is, ferdwynt by in werstart, útsein as in behearder it skriuwt, wat likegoed in feiligensskaaim is as in reden om net de iennige kopy yn jo shell-skiednis te hâlden.

Ferifiearje mei trije observaasjes

Skriuw de boarne op dy't de app frege, de rûte dy't de syktocht keas, en de boarne dy't de server echt seach.

Dy trije kinne ferskille, en elk ferskil wiist nei in oar plak. In opname op de tunnelinterfaces bewiist dat it pakket mei de goede boarne fuortgien is. In opname op de fysike ynterface bewiist dat it de ferkearde wei naam. It sicht fan de serverkant is it iennige dat it paad fan begjin oant ein bewiist.

As de app in opsje foar binen oan in apparaat of in routingmodus per app biedt, behannelje it as in oar meganisme mei oare beheiningen. Lykjende ynstellingen liede net allegear ta deselde kernelbeslissing.

Relatearre artikelen