Ødelægger en VPN-klient på din webserver dens svar?

Webstedet indlæses fra en bærbar computer på samme netværk og får timeout fra alle andre steder, og værten kører også en VPN-klient til sin egen udgående trafik. Den kombination giver en bestemt fejl: den indgående forbindelse ankommer, svaret forlader ad den forkerte vej, og klienten udenfor ser aldrig et svar. Begge halvdele ses i samme pakkeoptagelse, så rækkefølgen af begivenheder er den del, der er værd at læse.

En kildestyret ruterregel løser ofte symptomet. Den undtager også som regel mere trafik end det websted, der motiverede den, og det er den del, der er værd at forstå, før du gemmer reglen.

Symptomet: den svarer lokalt og ikke udefra

Inde på netværket behøver svaret ikke at krydse tunnelen, så siden indlæses, og tjenesten ser sund ud. Udefra når anmodningen værten, og svaret rutes ind i VPN'en, hvor den fjerne ende ikke har nogen grund til at acceptere det. Browseren ser en timeout i stedet for en afvisning, hvilket er kendetegnet på en ensrettet vej frem for en lukket port.

Bekræft formen, før du ændrer rutning: lytteren er oppe, den lokale anmodning lykkes, og den eksterne anmodning giver slet intet svar. De tre observationer peger tilsammen på returvejen og ikke på webserverens konfiguration. En så ren asymmetri er mere nyttig end nogen loglinje, fordi den udelukker lytteren, før du læser én eneste fejlmeddelelse.

Hold en uafhængig administrationsvej åben, mens du arbejder. En regel, der ødelægger din egen SSH-session, forvandler en ti minutters rettelse til et fysisk besøg.

Hvad en kildeselektor faktisk matcher

I Linux-policyrutning matcher en regel som from 192.168.50.2 pakker, hvis kilde er den adresse. Den koder ikke, at pakken fortsætter en samtale, der kom ind gennem hjemmerouteren, og den ved ikke, hvilken proces der skabte den. Adressen i det eksempel er illustrativ; indsæt den adresse, din vært faktisk bruger. Behandl linjen som en udtalelse om adresser og intet mere.

Hvis den valgte tabel leverer en almindelig standardrute, kan hver pakke med den kilde tage den samme undtagelse. En anden tjeneste bundet til samme adresse arver den, og et program, der bevidst binder til den adresse, arver den også. Referencen for policyregler opregner kilde, destination, protokol, port, mark og prioritet som separate selektorer, hvilket er en påmindelse om, at kilden alene er den groveste tilgængelige.

Prioritet afgør resultatet. Opslag kører i rækkefølge, og den første tabel, der giver et resultat, kan afslutte søgningen, så en regel placeret for tidligt kan skjule en mere specifik rute, som en senere tabel ville have leveret. Læs hele den ordnede liste i stedet for den ene linje, du tilføjede. En regel, der aldrig matcher, koster intet, mens en, der matcher for tidligt, stille ændrer alt bag den.

Kontroller returvejen og den trafik, du ikke havde tænkt på

Læs reglerne og tabellerne, og spørg derefter kernen, hvilken rute et bestemt kilde- og destinationspar ville tage. At teste fra værten selv er ikke det samme som at teste udefra, så gør begge dele.

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

Accepter derefter en ny ekstern forbindelse og, separat, en anmodning, der stadig skal gå ud gennem VPN'en. Hvis den anden nu går direkte ud, er undtagelsen bredere end det problem, du løste, og den test, der betyder noget, er den, du ikke havde tænkt dig at ændre.

En offentlig adressekontrol i en browser rapporterer kun de anmodninger, den browser har foretaget. Den siger intet om webserverens svar, om en anden lokal applikations kildevalg eller om, hvad der sker med administrationstrafik efter den næste VPN-genopkobling.

Beslut, hvor snæver undtagelsen kan være

To designs er forsvarlige, og de bør vælges bevidst. Hvis værten findes for at offentliggøre denne tjeneste, og dens udgående trafik er uvigtig, er en dedikeret lokal adresse med en politik kun for WAN et rimeligt arrangement, forudsat at du accepterer hele omfanget. Hvis kun bestemte indgående forbindelser skal kvalificere, er adressevalget for groft, og et forbindelsesbevidst design hører foran det.

Noter den kontrakt, du stoler på: den offentlige mapping, den værtadresse, anmodningen leveres til, og den vej, svaret forventes at tage. En indgående tjeneste offentliggjort gennem en VPN-udbyder er en anden kontrakt end en, der offentliggøres gennem en hjemmerouter, og en undtagelse kopieret fra ét eksempel er ofte forkert for det andet.

Vedligehold politikken i den komponent, der ejer rutning, i stedet for at indsætte en kommando i en opstartsfil. Regelrækkefølge, oprydning efter en netværksændring og genafspilning efter en genstart skal alle overleve, og en uafprøvet opstartsfil fejler normalt i det øjeblik, du ikke kigger. Slut af med det acceptresultat, du kan forsvare: ét offentliggjort websted gendannet og én urelateret strøm uændret.