Netteneren forsvinn når VPN-klienten koplar til

Ei teneste som forsvinn i det augneblunken ein VPN-klient koplar til, er vanlegvis ikkje blokkert, ho svarar gjennom feil grensesnitt. Førespurnaden kjem inn på det fysiske nettverkskortet, daemonen skriv eit svar, og rutetabellen gjev svaret til tunnelen, sidan tunnelen har teke over standardruta. Den eksterne klienten ser aldri eit svar på ei tilkopling han opna, så han ventar og rapporterer deretter tidsavbrot. Ingen brannmurregel er involvert nokon stad i den sekvensen.

Symptomet: førespurnader inn, svar ut gjennom feil dør

Teiknet er ei innkomande tilkopling som feilar medan alt anna på verten verkar. Eit anna teikn er ein vert som er nåbar frå LAN, men ikkje frå internett, eller ein som verkar til tunnelen koplar til på nytt og deretter stoppar. I kvart tilfelle oppførte retninga utover seg pent, og returretninga ikkje, noko som peikar på ruteasymmetri og ikkje på policy.

Stadfest det ved å sjå kvar svaret går, ikkje ved å sjå korleis førespurnaden kjem inn.

Fang samtidig på det fysiske grensesnittet og på tunneleininga. Viss førespurnaden viser seg på det fysiske grensesnittet og svaret på tunnelen, er diagnosen ferdig. Eit svar som ikkje viser seg nokon stad, betyr at tenesta aldri godtok tilkoplinga, noko som er ei eiga undersøking med eigen årsak.

To standardruter og éi ruteavgjerd

Ein klient som installerer ei standardrute, legg til ein annan oppføring med betre metrikk enn LAN-gatewayen. Nokre klientar installerer i staden to halvområderuter, som dekkjer same rom meir spesifikt og vinn oppslaget på same måte. Begge teknikkane lèt vanlege utgåande pakkar velje tunnegrensesnittet.

Det valet blir teke berre etter destinasjon. Kjernen spør ikkje kvar ein pakke kom frå med mindre ein policy-regel ber han om det. Så svaret til ei offentleg klientadresse blir gjeve til tunnelen, der den fjerne enden mottek ein pakke med ei kjeldeadresse han ikkje eig og kastar han eller sender han vidare ein ubrukeleg stad. På Linux kan streng reverse-path-filtrering også droppe den opphavlege førespurnaden før tenesta di i det heile ser han, noko som ser identisk ut utanfrå. Begge symptoma kjem frå den same manglande koplinga mellom ein innkomande straum og svaret hans.

Tunnelen oppfører seg rett heile vegen. Han fekk beskjed om å bere standardruta, og det gjer han nøyaktig.

Reparer returvegen utan å øydeleggje tunnelen

Det finst tre varige former for reparasjon, og valet avheng av kor mykje av verten sin eigen trafikk som skal bli inne i tunnelen. Å utelate destinasjonen eller porten til tenesta er den minste endringa. Policy-ruting etter kjelde eller merke er den mest presise. Kjeldeomsetjing er den grovaste og den lettaste å forklare to år seinare.

Vel etter kva verten må gjere, ikkje etter kva snutt du fann først.

Å utelate ein destinasjon passar for ei teneste med stabil offentleg adresse, og å binde daemonen til den fysiske adressa i staden for til alle adresser gjer den utelatinga tryggare. Ein policy-regel som vel ein tabell etter kjelde, held verten sine eigne tilkoplingar inne i tunnelen medan han sender svara til tenesta tilbake gjennom WAN-gatewayen. Maskering av svar til WAN-grensesnittet når same veg på kostnad av å skjule adressa til klienten frå loggane til tenesta. Ei ad hoc-endring av standardruta er ein diagnose og ikkje ein konfigurasjon, fordi klienten skriv om rutene ved kvar gjenoppkopling.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Når verten også rutar for eit LAN bak seg

Eitt hopp lenger ute kjem den same asymmetrien tilbake med fleire bevegelege delar. Trafikk når rutaren frå internett, blir send vidare til ei intern eining, og den einaste vegen tilbake for den eininga er tunnelen, så svaret når den opphavlege klienten frå adressa til leverandøren sjølv. Deretter møter tilkoplingssporing eit svar for ein straum han ikkje har sett starte, og kastar det. Klienten ser i mellomtida ingenting i det heile.

To endringar reparerer det: destinasjonsomsetjing slik at den innkomande tilkoplinga når den interne eininga, og kjeldeomsetjing slik at svaret til den eininga ser ut til å kome frå rutaren sjølv.

På rutar-fastvare er det vanlege uttrykket ein policy-regel som festar portvideresendinga til WAN-sida medan rutaren sin eigen trafikk går gjennom tunnelen. Utan kjeldeomsetjing er det svaret adressert til den eksterne klienten, og den interne eininga har rett og slett inga rute til det. Test tre ting kvar for seg, fordi dei feilar av ulike grunnar: ei tilkopling som kjem utanfrå, ei som verten sjølv startar, og eit namneoppslag.