OpenVPN seit ferbûn en gjin ferkear beweecht, in sin dy't teminsten fiif net besibbe flaters dekt. Firewallregels bewurkje foardat jo witte hokker laach mislearret fermannichfâldiget it ûnbekende en lit de folgjende yngenieur in rommel. Wurkgje ynstee fan it proses nei bûten, want elke stap hjirûnder makket ien stadium skjin of ferneaut wêr't it pakket stjert. De oarder is hjir wichtich: in opname dy't nommen wurdt foardat jo witte hokker adres bûn is, bewiist wat, mar net wat jo nedich hawwe.

De socket is of bûn of net

In tsjinst dy't aktyf rapportearret kin noch altyd bûn wêze oan in adres of in ferfier dat jo nea bedoeld hawwe. Freegje de socket sels: ss -lunp listet UDP-lústerders en ss -ltnp listet TCP, en de kolom dy't it lêzen wurdich is, is it lokale adres, net de steat.

In leech antwurd betsjut meastentiids ien fan trije dingen: it proses is nei it starten ôfsletten, it hat in oar konfiguraasjebestân laden, of it lústert op in oar adres as dat dêr't nei belske wurdt.

ss -lunp | grep 1194
ss -ltnp | grep 1194

In local-rjochtlin stelt de lústerder fêst op ien adres, dus in klant dy't earne oars op deselde host rjochte is, wurdt wegere wylst de tsjinst fan bûten noch sûn liket. In eksimplaarnamme kin ek nei in bestân wize dat jo nea bewurke hawwe, wat bart op hosts dy't twa profilen njonken inoar draaie.

Fang it bûtenste pakket, net de tunnel

Filterje op de fysike ynterface en de echte poarte, mei jo eigen ynterface ferfongen: tcpdump -ni eth0 udp port 1194. Utgeande pakketten dêr't neat fan weromkomt wize op wat boppe sit: filtering fan de provider, in NAT-apparaat of in fiere adres dat net is wat jo tinke. Stilte yn beide rjochtingen wiist op klantrouting of in lokale firewall. Antwurden dy't oankomme sûnder foarútgong fan de tunnel wize op it kontrôlekanaal, dus in kaai- of syferferskil, net op filtering.

Fang beide rjochtingen en hâld it bestân koart. In lange opname begraaft de nijsgjirrige trije sekonden, en it antwurd sit hast altyd yn de earste útwikseling.

Eerst tellers, spoar allinne as se lige

Begjin mei de tellers, want se kostje neat. Of nft list ruleset of iptables -L -n -v beantwurdet de iennige fraach dy't hjir fan belang is: hat de regel passe? De oarder beslútet de útkomst, want de earste oerienkomst wint, dêrom lit in breed DROP foar in lettere ACCEPT dy ACCEPT dea en dêrom reparearret it tafoegjen fan in regel sa selden wat.

Eigendom stroffelet minsken ek. De kernel skriuwt lokaal generearre pakketten ta oan it proses dat de socket iepene hat, en OpenVPN draait normaal as root, dus in regel dy't op in gewoane brûkers-ID rjochte is, sjocht nea it ferkear fan de tunnel sels. Kontrolearje de eigendoms-UID foardat jo beslute dat de regel ferkeard is.

Allinne as de tellers dûbelsinnich bliuwe is in log it lûd wurdich, en dan noch allinne foar in smel stik: in iptables-regel dy't de snelheid beheint en syn logregels in foarheaksel jout, of in nftables-regel mei meta nftrace set 1 wylst nft monitor trace rint. In spoar neamt de keatling en de regel dy't it pakket akseptearre of wegere. Ferwiderje beide dêrnei en hâld payload-logging bûten.

Kontrolearje ek it ferfier. In firewallsjinst beheind ta TCP seit neat oer in UDP-lústerder op dat nûmer, dus in regel dy't goed lêzen wurdt, kin noch altyd elk pakket wegerje.

Routing en de wei werom

In akseptearre pakket dat noch altyd ferdwynt, hat ûndersyk fan syn bestimmingwei nedich. ip route get rapportearret de rûte dy't foar ien adres keazen is, en omkearde-paadfiltering kin in antwurd wegerje dat oer in ynterface oankomt dy't de haadtabel nea kieze soe. It symptoom liket krekt op in firewall-werjef, dêrom komt dizze kontrôle foar noch in NAT-regel.

Op in gateway ûndersykje jo trochstjoering en de forward-keatling ynstee fan de input-keatling. Befêstigje dan dat de fiere kant wit hoe't er it boarneadres berikt, want in wurkjende útgeande wei sûnder wat weromkomt is stilte yn beide gefallen.

Wat it ferslach sizze moat

Foar elke feroaring: notearje it stadium dat jo teste, it bewiis dat jo lies en de tellerwearde oan beide kanten dêrfan. Dat ferslach is wat "it wurket no" by de folgjende resinsje oerlibje lit.

Twa fluchwei hâlde it ferslach earlik. In pakket dat de host nea ferlitten hat, koe net troch in regel earne oars wegere wurde, hoe oertsjûgjend de konfiguraasje fan de fiere kant ek liket. In pakket dat fuortgie en weromkaam, ferpleatst de fraach boppe de netwurklaach, dêr't firewaltellers neat mear hawwe om jo te sizzen.

Relatearre artikelen