Tunnel oan, gjin internet: wêr't de trochstjoering ophâldt

De klient ferbynt, de tunnel draacht pings nei de gateway, en neat efter dy antwurdet. Dy steat is normaal foar in gateway dy't altyd allinnich bedoeld wie om tagong ta beskerme netwurken te jaan, en it is in flater foar ien dy't as útgong fan in folsleine tunnel oankundige wurdt. Befêstigje foardat jo regels feroarje hokker tsjinst tasein wie. Folgje dêrnei ien iepenbier fersyk troch de fjouwer plakken dêr't it stopje kin. Ien fersyk en ien pakketopname besljochtsje mear as in side fol fermoedens.

Befêstigje oft de internetútgong ea it ûntwerp wie

In split-tunnelprofyl rjochtet allinnich de beskerme subnetten yn 'e VPN, dus iepenbier browsen giet troch oer de lokale keppeling en rekket de gateway nea. In folslein tunnelprofyl ynstallearret in standertrûte yn 'e tunnel, wat de gateway ferantwurdlik makket foar it hiele paad. Beide binne legitime ûntwerpen, en se trochinoar helje bringt in flaterrapport fuort dêr't gjinien is. Lês de oankundige rûtes fan 'e klient foardat jo wat oars testet, want de rûteskema beantwurdet de fraach dy't it ticket meastentiids ferkeard stelt.

Wat de klient ynstallearret is net altyd wat it profyl bedoelt. In triuwde rûte kin oerskreaun wurde troch in lokale rûte mei in legere metrik, en in klient dy't syn LAN-rûte hâldt wylst er in standertrûte tafoeget, hâldt him foar dat subnet as in split tunnel.

Folgje ien iepenbier fersyk

Kies ien bestimming en folgje dy fan 'e klient nei bûten. Kontrolearje op 'e klient oft it pakket wier de tunnel kiest en hokker lokaal adres it as boarne brûkt. Kontrolearje dêrnei de gateway: komt it pakket oan, en ferlit it de iepenbiere interface. Elk fan dy antwurden hellet in hiele kategory oarsaak fuort.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

As de gateway it pakket nea sjocht, is de klientrûte of de tunnelkar ferkeard. As it oankomt en net fuortgiet, leit it probleem op 'e gateway, en jilde de oerbliuwende trije kontrôles.

Kontrolearje trochstjoering, rûte en oersetting

De trochstjoeringshantlieding dy't mei strongSwan komt jildt foar in gateway fan elk tunneltype: de kernel moat tastien wurde pakketten tusken interfaces te ferpleatsen, en in brûkbere rûte moat nei it internet wize. It firewallbelied moat dan it ferkear tastean, en it boarne-adres moat ien wêze dêr't de iepenbiere kant antwurd op jaan kin. In privaat klientadres dat ûnferoare nei it internet trochstjoerd wurdt, krijt nea in antwurd.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Boarne-oersetting is it gewoane ûntbrekkende stik. Dêrmei skriuwt de gateway de klientboarne oer nei syn iepenbiere adres en folget de stream; sûnder dat hat it antwurd nearne hinne. Cloudplatfoarms foegje in twadde grins ta, dêr't de rûteskema of befeiligingsgroep fan 'e ynstânsje ferkear ôfsmite kin dat de firewall fan 'e gast tastiet. Dy grins is maklik te missen, want it gastsysteem liket fan binnen goed konfigurearre.

Filtering fan 'e omkearde paad yn in asymmetryske opset kin ek jildige pakketten ôfsmite. Lês de teller fan dy regel ynstee fan oan te nimmen dat it goed is, want in strange ynstelling op 'e iepenbiere interface wiist ferkear ôf dat oer in oare wei komt as it rûteskema foarsiset.

Antwurdskaad en resolver binne twa ferskillende antwurden

Let ek op it antwurd, net allinnich op it fersyk. As it fersyk oerset fuortgiet en it antwurd weromkomt yn 'e oersette stream, wurket trochstjoering sels as de applikaasje noch altyd mist, en it folgjende ûndersyk heart by de applikaasje of by DNS.

In side dy't in HTTP-flater weromjout is bewiis dat trochstjoering nei it internet wurket. In namme dy't net oplost wylst tagong fia adres wurket, is in resolverprobleem, gjin NAT-probleem.

Test nei in smelle korreksje de klient op 'e nij, tegearre mei elk bewust beheind privaat boarne. It jaan fan internettagong mei de tagong net stil ferskowen nei elk netwurk dat oan 'e gateway hinget.