Ødelegger en VPN-klient på webserveren din svarene dens?

Nettstedet lastes fra en bærbar PC på samme nettverk og går i tidsavbrudd fra alle andre steder, og verten kjører også en VPN-klient for sin egen utgående trafikk. Den kombinasjonen gir en bestemt feil: den innkommende forbindelsen kommer inn, svaret går ut via feil vei, og klienten utenfor ser aldri et svar. Begge halvdelene vises i samme pakkefangst, så rekkefølgen av hendelser er den delen som er verdt å lese.

En kildebasert ruterregel retter ofte symptomet. Den unntar også vanligvis mer trafikk enn nettstedet som motiverte den, og det er den delen som er verdt å forstå før du lagrer regelen.

Symptomet: den svarer lokalt og ikke utenfra

Inne på nettverket trenger ikke svaret å krysse tunnelen, så siden lastes og tjenesten ser sunn ut. Utenfra når forespørselen verten, og svaret rutes inn i VPN-en, der den fjerne enden ikke har noen grunn til å godta det. Nettleseren ser en tidsavbrudd i stedet for en avvisning, som er kjennetegnet på en enveis vei og ikke på en lukket port.

Bekreft formen før du endrer rutingen: lytteren er oppe, den lokale forespørselen lykkes, og den eksterne forespørselen gir ingen svar i det hele tatt. De tre observasjonene peker sammen mot returveien og ikke mot webserverens konfigurasjon. En så ren asymmetri er mer nyttig enn noen logglinje, fordi den utelukker lytteren før du leser én eneste feilmelding.

Hold en uavhengig administrasjonsvei åpen mens du arbeider. En regel som ødelegger din egen SSH-økt gjør en timinutters rettelse om til et fysisk besøk.

Hva en kildevelger faktisk matcher

I Linux-policyruting matcher en regel som from 192.168.50.2 pakker hvis kilde er den adressen. Den koder ikke at pakken fortsetter en samtale som kom inn gjennom hjemmeruteren, og den vet ikke hvilken prosess som lagde den. Adressen i det eksemplet er illustrativ; bytt den ut med adressen verten din faktisk bruker. Behandle linjen som en påstand om adresser og ikke noe mer.

Hvis den valgte tabellen leverer en vanlig standardrute, kan hver pakke med den kilden ta det samme unntaket. En annen tjeneste bundet til samme adresse arver det, og et program som bevisst binder seg til den adressen arver det også. Referansen for policyregler lister kilde, destinasjon, protokoll, port, merke og prioritet som separate velgere, noe som minner om at kilden alene er den groveste som finnes.

Prioriteten avgjør resultatet. Oppslag kjøres i rekkefølge, og den første tabellen som gir et resultat kan avslutte søket, så en regel som er plassert for tidlig kan skjule en mer spesifikk rute som en senere tabell ville ha levert. Les hele den ordnede listen i stedet for den ene linjen du la til. En regel som aldri matcher koster ingenting, mens en som matcher for tidlig stille endrer alt bak seg.

Kontroller returveien og trafikken du ikke mente å unnta

Les reglene og tabellene, og spør deretter kjernen hvilken rute et bestemt kilde- og destinasjonspar ville ta. Å teste fra verten selv er ikke det samme som å teste utenfra, så gjør begge deler.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Godta deretter en ny ekstern forbindelse og, separat, en forespørsel som fortsatt må gå ut gjennom VPN-en. Hvis den andre nå går direkte ut, er unntaket bredere enn problemet du løste, og testen som betyr noe, er den du ikke mente å endre.

En sjekk av offentlig adresse i en nettleser rapporterer bare forespørslene den nettleseren gjorde. Den sier ingenting om webserverens svar, om en annen lokal applikasjons kildevalg, eller om hva som skjer med administrasjonstrafikk etter neste VPN-gjenoppkobling.

Bestem hvor smalt unntaket kan være

To design er forsvarlige, og de bør velges bevisst. Hvis verten finnes for å publisere denne tjenesten og den utgående trafikken er uviktig, er en dedikert lokal adresse med en politikk kun for WAN et rimelig arrangement forutsatt at du godtar hele omfanget. Hvis bare bestemte innkommende forbindelser skal kvalifisere, er adressevalget for grovt, og et forbindelsesbevisst design hører hjemme foran det.

Noter kontrakten du støtter deg på: den offentlige mappingen, vertsadressen forespørselen leveres til, og veien svaret forventes å ta. En innkommende tjeneste publisert gjennom en VPN-leverandør er en annen kontrakt enn en som publiseres gjennom en hjemmeruter, og et unntak kopiert fra ett eksempel er ofte feil for det andre.

Vedlikehold politikken i komponenten som eier rutingen i stedet for å lime inn en kommando i en oppstartsfil. Regelrekkefølge, opprydding etter en nettverksendring og gjenoppspilling etter en omstart må alle overleve, og en uopptestet oppstartsfil feiler vanligvis i det øyeblikket du ikke ser på. Avslutt med akseptresultatet du kan forsvare: ett publisert nettsted gjenopprettet og én urelatert strøm uendret.