VPN-rûte of firewallregel: hokker smitet it pakket fuort?

Twa ûnôfhinklike besluten barre mei itselde pakket, en elk fan beide kin it fersyk stil beëinigje. De rûtesyktocht kiest in ynterface en in folgjende hop, dêrnei beslút it pakketfilter oft dy kombinaasje tastien is. In timeout fertelt jo dat ien fan de beide wegere hat, net hokker. Wurkje de stadia yn folchoarder ôf en de reparaasje hâldt meastentiids op in gissing te wêzen.

Twa besluten, ien pakket, twa eigners

De rûtesyktocht rieplachtt earst de beliedsregels, dan de tabel wêr't dy nei wize, en kiest it meast spesifike foarheaksel dat by de bestimming past. In klant dy't in tunnelrûte ynstallearre hat, besit dat beslút, en neat yn in firewallregel kin it ferfange. As de syktocht nei in ûnferwachte plak wiist, wurket elk letter stadium op it ferkearde pakket.

Filterjen is apart. Op in Linux-host splitsje de netfilter-hooks ferkear nei wa't it pakket foar is: útgong ferlit de masine, yngong einiget dêrop, trochstjoering giet der trochhinne. In gateway dy't VPN-klanten akseptearret en se nei in LAN rûtet, hat it trochstjoerpaad nedich, en dat is krekt de keten dy't de measte standertkonfiguraasjes leech litte.

Boarnekar is diel fan itselde beslút, en dêr ferskûlje de measte mismatches har. De kernel kiest in boarneaadres fan 'e útgeande ynterface, útsein as de rûte ien neamt, dus in filterregel skreaun foar it LAN-subnet past nea by in pakket dat mei it tunneladres fuortgiet.

Lês wat de syktocht eins keas

Print it beslút ynstee fan it ôf te lieden. It kommando hjirûnder lost de rûte op dy't de kernel foar dy bestimming brûke soe, ynklusyf de ynterface en de boarne dy't er kieze soe:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-klanten ynstallearje faak beliedsregels by prioriteiten ûnder de haadtabel, dus in skjinne haadtabel bewiist op himsels neat. Fergelykje de regelprioriteiten mei de tabellen dy't se kieze, en kontrolearje oft de tunnelrûte in werferbining oerlibbet ynstee fan ien kear mei de hân tafoege te wurden.

Beliedsbasearre IPsec foeget in tredde oerienkomststadium ta dat routing net dekt, sa't de trochstjoernotysjes fan strongSwan beskriuwe foar tunnel- en ferfierynstellings. It feilichheidsbelied selektearret ferkear op foarheaksel en protokol, wylst de rûte allinnich beslút wêr't in ûnbeskerme pakket hinne gean soe. In subnet dat rûte wurdt mar gjin oerienkommend selektor hat, bliuwt óf ûnbeskerme óf wurdt fuortsmiten, ôfhinklik fan de konfiguraasje, en gjin fan beide útkomsten liket op in firewallprobleem. Print it belied en fergelykje syn selektors mei de foarheaksels dy't jo ferwachten dat de tunnel drage soe.

Filterjen jildt by in hook, net by in rûte

In regel dy't de VPN-listener tastiet is in regel oer ferkear rjochte op de gateway sels. Hy seit neat oer klanten dy't hosts efter dy gateway berikke, om't trochstjoerd ferkear in oare keten trochrint. It regelstelsel as ien flakke list lêze is de gewoane reden dat in korrekt lykjende regel nea ôfgiet.

Tellers beslisse de fraach gau. In regel mei in nul pakketteller waard nea berikt, wat op de ferkearde keten, de ferkearde ynterface of in eardere drop wiist. In regel mei in groeiende teller ûnder in droppbelied is de grins dy't jo sochten, en it pakket wurdt fuortsmiten ynstee fan ferkeard rûte.

Stjoer in probe troch it paad dat de klant brûkt

Tests útfierd op de gateway sels reizgje troch útgong en yngong, mei it eigen boarneaadres fan 'e gateway. Dat is in oar paad as it trochstjoerde fersyk fan in klant, dus in slagge lokale curl bewiist minder as it liket. Probe fan 'e masine dy't mislearret, of pin de ynterface en boarne eksplisyt.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

In opname oan beide einen skiedt de oerbleaune gefallen. In SYN dy't de klant ferlit en nea oankomt, betsjut routing, fersifering of in tagongslist streamop. In SYN dy't oankomt en gjin antwurd krijt, betsjut de tsjinst of syn hostfilter, en de tunnel wie nea it probleem.

Weromferkear fertsjinnet in eigen eachopslach. Asymmetryske routing plus filterjen fan 'e omkearde paad smyt antwurden fuort dy't op 'e ferkearde ynterface oankomme, wat as in ienrjochtingsferbining ferskynt ynstee fan in blokkearre poarte. Kontrolearje de sysctl-wearde foardat jo de firewall de skuld jouwe foar in symptoom dat er net feroarsake.

Logging wurket as in twadde miening, net as in earste stap. In tydlike logferklearring op 'e trochstjoerketen neamt de ynterface en de adressen dy't it rekken, en it is dêrnei maklik fuort te heljen. Lit it permanint stean en jo hawwe in logvolumeprobleem boud ynstee fan in antwurd.

Set elke feroaring dêr't it in werferbining oerlibbet

In rûte tafoege mei ip route add libbet oant de ynterface delgiet. Bewarje it ynstee yn it ferbiningsprofyl: NetworkManager akseptearret ekstra rûtes op 'e ferbining, en netplan hâldt se oer opstarts hinne. Deselde regel jildt foar in firewallútsûndering oan 'e klantkant, dy't nei de folgjende werlading fuort is.

Regels oan 'e tsjinnerskant hearre yn it konfiguraasjebestân dat de tsjinst by it starten laadt, net yn in ynteraktive sesje dy't einiget as jo it slute. Skriuw de regel, werlaad, en befêstigje dat de teller beweegde, want in werlading dy't de syntaks wegere hat, lit de âlde regelset stil stean.

Werhelje dan it oarspronklike applikaasjefersyk fan begjin oant ein en notearje hokker laach feroare. In rûtereparaasje dy't ek in filterferoaring nedich hie, sil noch mislearje, en de twadde mislearring lêst folle makliker as jo witte dat de earste fuort is. Notearje de datum en de klantferzje nêst it resultaat, om't standertwearden foar routing en filterjen beide tusken ferzjes bewege. Hâld dy notysje op 'e ticket sadat de folgjende persoan begjint wêr't jo opholden binne ynstee fan 'e twastapstocht te werheljen.