VPN-klanten meitsje ferbining mar hawwe gjin ynternet: trije ûntbrekkende stikken

De klant krijt in adres, de tsjinner beantwurdet ping, en dochs ferfalt elke side. De measte minsken begjinne op dit punt it klantprofyl te bewurkjen, wat meast fergriemde muoite is: sadree’t de tunnel omheech is, moat de tsjinner him as in router gedrage. Trije betingsten moatte tagelyk jilde foardat in pakket út giet en in antwurd werom komt, en it symptoom is identyk hokker oft ek ûntbrekt.

Wêrom’t in wurkjende tunnel noch altyd gjin útgong hat

De kernel moat pakketten tusken ynterfaces trochstjoere, wat by de measte Linux-distribúsjes standert út is. It ferkear moat oerset wurde nei in adres dêr’t de bûtenwrâld op antwurdzje kin, útsein as elke boppestreams router de weromwei nei it tunnelsubnet al ken. It trochstjoerpaad fan ’e firewall moat it ferkear yn beide rjochtingen tastean, ynklusyf de antwurden.

Elk dêrfan kin apart reparearre wurde, en dat is de falstrik. Trochstjoering oansette sûnder oersettingsregel lit pakketten fuortgean mei in privee boarne en gjin weromwei. Oersetting tafoegje sûnder trochstjoerregel lit de kernel it pakket in stap letter falle.

Testje dêrom de trije lagen ynstee fan de klant, en feroarje ien tagelyk sadat it resultaat wat betsjut.

Trochstjoering is in kernelskeakel dy’t jo fêst hâlde moatte

Kontrolearje de hjoeddeiske wearde foardat jo dy feroarje, set dy dan en befêstigje dat de feroaring ynwurke hat.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

It earste kommando jout de hjoeddeiske wearde, it twadde set dy by runtime, en it tredde bewissiget dat it skriuwen wurke hat. De runtime-wearde ferdwynt by de folgjende werstart, en dêrom kin in wurkjende sesje nei ûnderhâld brekke sûnder hokker konfiguraasjeferoaring dan ek.

Meitsje it permanint yn in bestân ûnder /etc/sysctl.d/, en pas dat bestân dan ta ynstee fan te wersjen om it út te finen. Op FreeBSD is it ekwivalint net.inet.ip.forwarding, mei gateway_enable=YES yn rc.conf foar permaninsje. In apparaat dat trochstjoering útskeakele rapportearret, ferklearret in hiele klasse fan rapporten „pakketten komme oan en der komt neat werom”. Kontrolearje de ynstelling ek nei elke upgrade, want in werboudene kernel of in ferfongen apparaatbyld kin it weromsette sûnder it immen te fertellen.

Kies masquerade of ien fêste oersettingsadres

Mei in dynamysk bûtenadres is masquerading de ienfâldichste korrekte foarm. Neam it tunnelsubnet as boarne en de bûtenynterface as útgong.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Mei in statysk iepenbier adres is boarne-oersetting nei krekt dat adres foarsisberder en makliker te auditearjen.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

De twadde foarm hat in ûnderhâldsfalstrik: in hurd kodearre adres dat letter feroaret hâldt de tunnel oan ’e gong wylst internettagong stilwei stopt. Brûk of masquerade of fernij de regel sa faak as de provider jo ferpleatst. De ynterface is ek fan belang, want in router dy’t syn eigen boppestreams tunnel dielt moat troch dy tunnel oersette en net troch de fysike WAN.

De filtertabel is de tredde poarte

Trochstjoering en oersetting kinne beide korrekt wêze wylst it pakket dochs yn ’e filtertabel stjert. ufw is in faak foarkommende skuldige: syn trochstjoerbelied komt as DROP, en de rest fan ’e opset kin folslein korrekt lykje wylst dy iene ynstelling it ferkear deatet. It ferheegjen is in bewuste feiligensbeslissing en net in oanfinkfakje.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

De earste regel lit nij ferkear fan ’e tunnel nei bûten ta, en de twadde allinnich antwurden werom. Behein beide ta it tunnelsubnet en de bedoelde bestimming, want in algemiene tastimming op ’e tunnelinterface makket de VPN in iepen útgongspunt foar elkenien dy’t autentisearje kin.

In brêge tunnel freget in oar antwurd. It adres heart by de brêge, net by de fysike poarte, dus it ûnderhearrich meitsjen fan ’e ynterface fuortet it adres dat it earder hie en de host liket ûnberikber oant de brêge sels ien krijt, wat dhclient br0 leverje kin. Dy flater liket in VPN-probleem en is in probleem fan ’e twadde laach. Kontrolearje it eigen adres fan ’e brêge foardat jo de firewall oanreitsje, want in filterferoaring kin in host net reparearje dy’t gjin adres mear hat om fan te stjoeren.

Wêr’t jo sjen moatte as in side nea laden wurdt

Ping it tunneladres fan ’e tsjinner om te bewizen dat de tunnel bestiet. Rin dan in traceroute fan ’e klant nei in iepenbier adres en lês wêr’t it stopt: by de tsjinner komt it pakket oan mar wurdt it net trochstjoerd of oerset; foarby de tsjinner is it probleem boppestreams en bûten jo hannen.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

It earste kommando bewissiget dat de tunnel ferkear nei de tsjinner sels bringt, en it twadde lit sjen hoe fier in pakket nei bûten komt. In spoar dat by it tunneladres einiget wiist op trochstjoering of oersetting op ’e tsjinner, wylst in spoar dat in hop letter stopt wiist op ’e provider of de weromwei fan ’e boppestreams router.

Op ’e tsjinner, hâld de bûtenynterface yn ’e gaten wylst in klant in side laadt. Ferkear dat mei in privee boarneal-adres fuortgiet betsjut dat oersetting ûntbrekt, en hielendal gjin antwurd betsjut dat it trochstjoerpaad of de boppestreams weromwei it lit falle.

As fiere klanten ek hosts op ’e LAN fan ’e tsjinner berikke moatte, tink dan dat de LAN in weromwei nei it tunnelsubnet nedich hat. Dat is routing en net oersetting, en it is de stap dy’t it meast fergetten wurdt neidat it internetpaad einlings wurket.